Now with browsers and JavaScript performance being better than ever, preserving state seems possible so a more "original" MVC implementation can (possibly, ever

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?