I've been doing client side development for a while, and I do not think MVC applies cleanly to the browser as it does to a web server. In the terms of the 1970

I've been doing client side development for a while, and I do not think MVC applies cleanly to the browser as it does to a web server. In the terms of the 1970s breakdown presented in this article, a DOM node is both a view (presenting information to the user) and a controller (collecting and forwarding UI events). MVC is a fine pattern, but underwhelming when taken as an architecture. It doesn't tell you how state will be managed and reasoned about, which along with asyncronous sequencing is the main challenge of browser development. Server side MVC doesn't really have this problem because at the end of they day the lifecycle of a HTTP request is relatively limited. Most JavaScript MVC libraries have their own answers for how state should change, but just being answers does not necessarily make them complete, good, or right for your application. My general strategy these days is to avoid parts of my code having to know that other units are "a Backbone collection" or "a React view", and instead to have those as implementation details that I wrap in a smaller, more limited API. Instead of a framework I just use an event bus with a catalog of events that are very specific to my application. In a way this creates a "data" or "service" layer that has to fulfill event contracts, which are basically abstractions over HTTP, websockets, local storage, etc, and a "statically allocated" view layer that only knows how to respond and trigger a few events on the bus. You might call that MV and say that the C is somewhere, but to me that's more confusing than helpful.