> When I first saw React.js, I had a quick glance and thought that it was cool, they finally figured out how to do a Cocoa-like MVC UI framework in JavaScript.
> Overall, though, the use of a true MVC UI framework seemed like a great step forward
The author keeps saying 'MVC' as if it ever made any sense in the context of React. The old react docs used to quip that react was the v of mvc, until this notion was scraped entirely; and although one might perhaps suggest that props and templating is a v, and state is conceivably an m, there has never been anything concrete one could point out and argue that it is a c.
DanielHB•1h ago
It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
When bending it to apply to React + JSON-apis it kinda applies, but it is such a different approach that conceptually it is not relevant in the presence of a lot of client state.
phil-martin•1h ago
It started waaaaay before backend server-rendered pages
"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."
lelanthran•58m ago
> It is funny that MVC as a concept started as a backend server-rendered pages where the V was what rendered the HTML, C was the business logic which pulled data from the M which was the database + adapters.
I've got a CD from 1995 for Watcom C/C++. I purchased this compiler and IDE for a large (for me) sum of money and used it to create many Win32 applications.
I recall that that the help pages (which were extensive) came along with some non-reference documentation, which gave a quick overview of MVC for writing Win3.1 and Win95 applications, so MVC was already well-known in GUI systems even back then.
dsego•41m ago
The server-based MVC pattern adopted in Rails is not the original one described for use in interfaces, it could be considered a misinterpretation.
A model is supposed to be a domain model, the business logic of the app, not simply a database access layer. Your logic should reside in the model layer, sort of like building a library of classes and functions that you can reuse. That's why in the server-side world people use the term "fat models" to describe this type of use.
> When bending it to apply to React + JSON-apis it kinda applies
There is no bending, the original MVC applied to separating the business logic from rendering views and capturing input events, because this separation promotes code reuse. You can write many different views and controllers in your UI that show and react to user's input but still talk to the same underlying logical model.
I like this github repo to understand how MVC applies to programs with graphical interfaces. It's JS and HTML, so it's easy to follow.
React is not pure at all, and has a few gotchas related to updates. That being said, the JSX and composability of it is unmatched and I think the main reason React "won".
I think a logical continuation of this model is something like Solid.js, where there is no concept of re-rendering, just atomic DOM updates when observables change their values, but somehow this approach didn't get critical traction.
greener_grass•55m ago
It exists, but as a Haskell library called Reflex. This is why it didn't gain traction ;)
bsaul•28m ago
Is there a trend of new web framework that try to go back to actually using classes / objects instead of functions to build UI components ?
boxed•26m ago
In Elm the UI is 100% pure, and they are super adamant that local state is evil and a mistake. They sort of get away with it because there is already hidden state like input focus/selection, or scroll positions. But it's pretty clear that it's not practical to do full purity without local state in reality.
azangru•3h ago
> Overall, though, the use of a true MVC UI framework seemed like a great step forward
The author keeps saying 'MVC' as if it ever made any sense in the context of React. The old react docs used to quip that react was the v of mvc, until this notion was scraped entirely; and although one might perhaps suggest that props and templating is a v, and state is conceivably an m, there has never been anything concrete one could point out and argue that it is a c.
DanielHB•1h ago
When bending it to apply to React + JSON-apis it kinda applies, but it is such a different approach that conceptually it is not relevant in the presence of a lot of client state.
phil-martin•1h ago
https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...
"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."
lelanthran•58m ago
I've got a CD from 1995 for Watcom C/C++. I purchased this compiler and IDE for a large (for me) sum of money and used it to create many Win32 applications.
I recall that that the help pages (which were extensive) came along with some non-reference documentation, which gave a quick overview of MVC for writing Win3.1 and Win95 applications, so MVC was already well-known in GUI systems even back then.
dsego•41m ago
https://andrzejonsoftware.blogspot.com/2011/09/rails-is-not-...
https://news.ycombinator.com/item?id=3035549
A model is supposed to be a domain model, the business logic of the app, not simply a database access layer. Your logic should reside in the model layer, sort of like building a library of classes and functions that you can reuse. That's why in the server-side world people use the term "fat models" to describe this type of use.
> When bending it to apply to React + JSON-apis it kinda applies
There is no bending, the original MVC applied to separating the business logic from rendering views and capturing input events, because this separation promotes code reuse. You can write many different views and controllers in your UI that show and react to user's input but still talk to the same underlying logical model.
I like this github repo to understand how MVC applies to programs with graphical interfaces. It's JS and HTML, so it's easy to follow.
https://github.com/madhadron/mvc_for_the_web/tree/master