JavaScript MVC
alistapart.com
alistapart.com
Now, I know some sites don't have that last one, but MMVCC is pretty common.
Now that following MMVVCC has mucked up your code beyond belief, maybe you should reconsider whether it actually bought you anything.
Upshot: The MVC abstraction just doesn't make sense in this context. It cuts the wrong way for a client-server application, and if you're just forcing your code into MVC's structure because there's this dogma floating around that it's a good idea... don't do that! There are far better ways to structure your JS. In fact, almost anything is a better way to structure your JS.
The big mistake that folks make is not that they use MVC on the client but that they use MVC on the server side in this scenario. You'd get better bang for your buck if you used MVC on the client and accessed RESTful resources via a model class, and treated the server like a filesystem for loading controller and view classes that were handled exclusively by the client.
Separating model logic from presentational logic helps me a lot in client side code.
Then the 'two models' problem seems inescapable if you want to divide the load of model-level computation between client and server.
Sure, if you do all the non-trivial computation server-side, then the client-side model becomes less important. But sometimes you need to do more complex computation in the client, whether for UI latency or scalability reasons. If you didn't, you'd just be writing a traditional server-side web app (which of course is fine, but not what we're talking about).
On the other hand, if you do most of the computation client-side, the server-side can be a relatively trivial persistence layer, and sometimes that works out really well. But even if all you're doing is calling on a persistence layer, it can still require a fair bit of bookkeeping logic in your client-side model code. versioning, caching and cache expiry, object identity, managing consistency of local copies of denormalised data etc.
As for 'two controllers', I'm not sure I get what you mean there. In most verisons of MVC I've seen, the controller talks to both model and view, not just the view. But it is a poorly-defined term.
Personally I prefer an approach something like "M + Tree(V + C)". That is, a model layer, and then a tree of 'widgets' or user-interface components, each of which has its own controller and view logic. Widgets may create and manage child widgets. etc. Finding this works quite well, especially when you throw data-binding into the mix too.
Agree that the 'VV' approach you describe sounds quite a crazy optimisation, depending on how far you take it. Although might make more sense if you have more of a unified development environment between client and server eg GWT or a javascript-based server framework.
Honestly? Read the motivations for MVC. Read carefully about the reason why some people think it's a good idea, because I think the ideas are valuable.
Then... just write your code, and focus on keeping it well-factored, not MVC. MVC is really about keeping your code well-factored, but it only applies literally in a handful of circumstances. The ideas apply everywhere, but you're better off understanding how to keep things well-factored than how to jam things into MVC.
MVC is giving a man a fish, understanding factoring is teaching them how to fish, but the metaphor breaks down here in that it's actually easier to learn how to fish here.
Replying to this with an elaborate explanation of when MVC applies would be missing the point. If it is the best-factored organization, then go for it. But it is the best solution fairly rarely, where the best may be MMVC, or MVCC, or MVC+tree, or, frankly, endless variations on the theme. There's so many valid variations of such diversity that viewing everything through the lens of MVC just isn't that helpful.
"The MVC abstraction ... cuts the wrong way for a client-server application"
Implying that there's something fundamental about MVC-like patterns which makes them unsuitable for client-server apps. As someone using an MVC-like pattern for a client-server app, I was interested in what you think that might be.
Seems I misunderstood and you were just making a point about your dislike of the term MVC and the way people are dogmatic about it. Which I broadly agree with (I'm not using the conventional variant, after all), but don't think was stated very clearly.
Re 'well-factored': of course, people should learn to factor code well before trying to shoe-horn it into a Pattern. But in my experience a simple iterative process of keeping things well-factored will only get you so far - it's quite a fine-grained process that doesn't always help with the bigger architectural decisions. So ultimately architecture needs ideas, and it does help to talk about those ideas and give them names, much as this can lead to abuse by the lazy.
(depending on what you mean by 'well-factored' anyway - it can be used as something of a broad, catch-all bit of terminology for 'well-structured code', but as I understand it, refers merely to code which has had duplicated pieces of logic factored out).
There's also the fact that application frameworks are often tied to architectural styles, and application frameworks have a lot of value to people, such that oftentimes it's a worthwhile tradeoff to use one even when the architectural style isn't a perfect fit. You just have to be aware of the trade-off.
Well, that's the thing, isn't it? It's always some variant. It's never "pure" MVC, where of course by "never" I don't mean literally "never" but close enough. So I get to asking myself what's the point of the MVC purists pushing the model when "nobody" actually uses it?
What really prompted this was the continual torrent of "Is X Actually MVC?" essays, which inevitably turn out to be "No, X is not MVC." You name it, it's not MVC. Just about the only other technology that has the same suite of essays is "Is X Truly REST?", which, again, is always a "no", because you can't actually stay absolutely pure.
If you're using MVC in a client-server app, I give 95% probability that you have done one of the following: Got at least one of the MVC split between server and client, not have the "pure" MVC separation that would satisfy an MVC dogmatist (V and C are really easy to mix, personally I'm somewhat less convinced they are cleanly separable even in theory in most cases, as unless your views are all virtually identical the control ends up reasonably tightly coupled to your view by sheer logical necessity), or horribly contorted the code to fit into MVC. Roughly in order of probability.
Also: Well-factored code that is poorly factored at the architectural level is an oxymoron. I mean well-factored at all levels. MVC ideas can help, but jamming an architecture into that template is no better than jamming it into any other pattern; that's always a mistake and MVC is no exception.
I read it as a broad (but still useful) term describing a class of related architectural patterns designed to decouple presentational logic from domain logic.
While I've heard different people describe different (related) kinds of architectures as MVC, I've not actually encountered that much religious debate about which is the "one true" definition. So I'm not sure exactly which MVC variant is the one that you're reacting against as the dogmatic "pure" one.
You're more-or-less right about my client-server architecture - I have a split model, and my V and C are somewhat mixed. As the unit of reuse (outside the model) is the Widget, there's quite a fluid spectrum between "view-y" widgets and "controller-y" widgets, meaning you can make a decision based on the individual merits of the situation on how far to split the two. But still have a useful framework in which to do so. It's my favourite kind of MVC, but perhaps need a more specific name for it!
Pure MVC isn't possible for most Javascript apps,
because the Model lives on the server.
It is designed to do a lot less than other JS templating engines. The goal is to force the separation of programming logic and HTML markup.
Plug: Flapjax <http://flapjax-lang.org/>; helps with this a bit. My own thesis work used Flapjax to prototype an even more robust system.
In web architectures, there is a practical problem with where logic lives, where the data lives, and what generates the "view". It's a non trivial architectural problem, but it's not impossible by any means. The computer science and software is completely capable.
I guess this is tangential to the debate about if Javascript is _good_ for MVC. If code is executed on both the server and the browser there probably needs to be a clean separation of responsibility or code generation. Otherwise - Google gears and chrome OS can certainly make the entire app live completely client side (and in MVC/ JS).