
JavaScript MVC - naish
http://www.alistapart.com/articles/javascript-mvc/
======
jerf
Pure MVC isn't possible for most Javascript apps, because the Model lives on
the server. Now we're talking something like MMVC (Model-server, model-client,
view, controller). Oh, and the controller isn't just controlling the view, it
eventually has to feedback to the actual server model, so it's more like
MMVCC. Oh, and if you want the page to load concrete HTML for the initial view
of the data (for speed, since dynamically constructing it client side may be
slow), then we've got MMVVCC.

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.

~~~
mjw
Genuinely interested here in what you'd propose as an alternative.

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.

~~~
jerf
"Genuinely interested here in what you'd propose as an alternative."

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.

~~~
mjw
You appeared to be making a hard assertion that

"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.

~~~
jerf
"(I'm not using the conventional variant, after all)"

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.

~~~
mjw
Just noticed this. Agreed, although I think we may be working from different
definitions of MVC.

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!

------
olegp
Also worth taking a look at json-template: <http://code.google.com/p/json-
template/>

~~~
mnemonik
Allow me to take this opportunity to shamelessly plug my jQuery templating
plugin: <http://plugins.jquery.com/project/tempest>

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.

------
mgreenbe
MVC never made a great deal of sense to me, in that I've never really seen a
system that entirely embodies what's described. Nevertheless, programming
Javascript is tough because it's easy to confuse the DOM---the view---with the
client-side model. When updates can come from the server or the view,
maintaining the client side model is quite difficult.

Plug: Flapjax <[http://flapjax-lang.org/>](http://flapjax-lang.org/>); helps
with this a bit. My own thesis work used Flapjax to prototype an even more
robust system.

------
hendler
Many design patterns work perfectly well in Javascript.

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).

