The Rails-style MVC is very very similar to the WebObjects MVC, which came from NeXT then was at Apple (and may still be used internally). Wikipedia says the fi

The Rails-style MVC is very very similar to the WebObjects MVC, which came from NeXT then was at Apple (and may still be used internally). Wikipedia says the first public demo of WebObjects was 1995. Original WebObjects tried to ignore the web's statelessness by keeping state on the server, and encoding state in a path param in every URL. It was not exactly designed to fit a stateless environment as designed to let the developer ignore the fact that the environment was stateless, put an abstraction on top that made it appear stateful. But maybe that's semantics. But later WebObjects, towards the end of when it stopped being a commercial product, grew out of this -- it was in fact a very bad fit for the web. Encoding an opaque identifier in every URL to connect to back-end state is bad for cache-ability, idempotency, persistent URLs, etc., it's not what Tim BL or Roy Fielding wanted from URLs at all. BUT, despite all that (differences in "routing", URL-to-app mapping), as far as the MVC break-down, the original WebObjects was still very much like the architecture of Rails, to the extent that I've often wondered if the Rails originator(s) were exposed to WebObjects. But, then, I'm not sure that this architecture, actually was motivated by, as OP says: "but in a way that makes sense for the web. The components don't have references to each other, because and nothing is alive. Each object is only around long enough for the page to be rendered" -- because the earlier WebObjects, as far as MVC split very much like Rails, in fact did it's best to keep the objects alive after all on the back-end, and provide abstractions that hid the statelessness of the web from the developer, connecting each HTTP request to the kept-alive-in-back-end objects, where things did have references to each other, or appeared to, that ought to have not been possible. But still had the same MVC breakdown that could be diagrammed the same way. Actually here's a 2001 version of the WebObjects manual, note they are pointing this out as different than classic MVC, but it is very much like Rails too. > Note: WebObjects uses the term “model” differently from MVC. In WebObjects, a model establishes and maintains a correspondence between an enterprise object class and data stored in a relational database. In MVC, model objects represent the special knowledge of the application. — https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/WebObjectsOverview/WebObjectsOverview.pdf https://developer.apple.com/library/archive/documentation/Le... page 28 More on MVC in WebObjects there too > Acting as a mediator between Model objects and View objects in an application is a Controller object… Because of the Controller's central mediating role, Model objects need not know about the state and events of the user interface, and View objects need not know about the programmatic interfaces of the Model objects. Familiar, right? And different from what the OP is saying was original MVC; maybe consistent with both what OP calls Apple-style as well as Rails-style MVC? I haven't found an earlier dated WebObjects manual online (such as actually from NeXT days!), but they definitely existed, would be interesting to see how they referred to MVC. You can see a little bit about the weird ways original WebObject tried to encode state in URLs, mapping to persistent back-end state, in this other legacy WebObjects doc I found on the web, see "Component Action URLs" on page 12, and following through page 17. https://wiki.wocommunity.org/download/attachments/1049043/Web_Applications.pdf https://wiki.wocommunity.org/download/attachments/1049043/We...