3 ms·

The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is

The original MVC was invented in the context of a fat client which were desktop-esque applications back in the day. In the context of the Web and HTTP (which is a stateless protocol) MVC had to be adapted to fit this context which is what Rails and many other frameworks have done. Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. Rails and the other MVC frameworks don't just focus on the client-side, however. They are also deeply involved with the database and everything in between so a pure implementation of MVC is out of their reach. On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. Once we break those apart you can have a Smalltalk style MVC implementation on the client-side and organize your "back-end" code to your hearts desire or use a back-end specifc framework to guide you there.

Chris_Newton 13y ago
Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. There is little need to debate that point. Doing MVC-style architecture on the browser side works just fine. One of my long-term projects is a relatively large web application that uses something very close to the original MVC idea, with a central model that holds all the state and then a few dozen view-controller pairs that handle all the ways of interacting with it. This architecture has served me well for several years now, and the design has proven to be very easy to maintain and adapt to changing requirements. (In practice I add a fourth type of component in the web context, a “store” that is responsible for communicating with the server, and I define a small number of additional relationships to go with it because it doesn’t fit into any of the other three categories. Even then, the store acts somewhat like a view-controller pair for most purposes, and the cases where it doesn’t are mostly things I might do differently with the wisdom of hindsight.) On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. I’m not sure why we need any distinction between them. Ultimately, we’re just writing a distributed application, which happens to run using something like HTTP as a communications protocol in this case. All the usual concepts about maintaining state and actions that have side effects apply, and all the usual arguments about separating such concerns apply. What makes you think we can’t use these ideas already today?

Chris_Newton 13y ago

Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, everyone is still debating this these days) work on the client side. There is little need to debate that point. Doing MVC-style architecture on the browser side works just fine. One of my long-term projects is a relatively large web application that uses something very close to the original MVC idea, with a central model that holds all the state and then a few dozen view-controller pairs that handle all the ways of interacting with it. This architecture has served me well for several years now, and the design has proven to be very easy to maintain and adapt to changing requirements. (In practice I add a fourth type of component in the web context, a “store” that is responsible for communicating with the server, and I define a small number of additional relationships to go with it because it doesn’t fit into any of the other three categories. Even then, the store acts somewhat like a view-controller pair for most purposes, and the cases where it doesn’t are mostly things I might do differently with the wisdom of hindsight.) On the Web in the next 5-10 years maybe we will see more frameworks separating the concerns of the Web server/database and the client-side. I’m not sure why we need any distinction between them. Ultimately, we’re just writing a distributed application, which happens to run using something like HTTP as a communications protocol in this case. All the usual concepts about maintaining state and actions that have side effects apply, and all the usual arguments about separating such concerns apply. What makes you think we can’t use these ideas already today?