3 ms·

It looks to me this article is mostly about client side development. As an all round developer, I usually think about MVC in the backend (server side). Now that

It looks to me this article is mostly about client side development. As an all round developer, I usually think about MVC in the backend (server side). Now that I recently got more into bigger client side applications it does surprise me there aren't any good MVC kind of libraries/frameworks. To my taste there isn't any good satisfying way to efficiently manage a lot of data on the client side. I'm talking about doing complex querys on your data done through a sophisticated ORM like that of Django for example. Having relations in your data instead of having to loop trough all your arrays or doing REST calls all the time. In that aspect I think there's still a lot of nice steps to be made in client side development.

zachrose 11y ago
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.
- ciscoheat 11y ago
  Very insightful comment, zachrose. At the end of the article I've linked to DCI, which is the perfect complement to MVC - DCI is an architectural pattern that separates what the system is (data) from what it does (function), and mapping the user's mental model directly to code. When you grasp how it works, things fall into place very well, with no abstractions, polymorphism or similar things that makes the code divided and very hard to reason about.

zachrose 11y ago

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.

ciscoheat 11y ago
Very insightful comment, zachrose. At the end of the article I've linked to DCI, which is the perfect complement to MVC - DCI is an architectural pattern that separates what the system is (data) from what it does (function), and mapping the user's mental model directly to code. When you grasp how it works, things fall into place very well, with no abstractions, polymorphism or similar things that makes the code divided and very hard to reason about.