
Journey Through The JavaScript MVC Jungle - rileyt
http://coding.smashingmagazine.com/2012/07/27/journey-through-the-javascript-mvc-jungle/
======
danenania
I have to say, the more javascript (these days coffeescript) I write, the more
I think an mvc structure on the client is usually a big mistake. Mvc means
shared global state and putting your data behind an inflexible facade, neither
of which is necessary or a good idea in ui programming.

What's the alternative? Components. Encapsulation. Modularity. It's nothing
fancy. Just build small, composable functions and objects that manage their
own data and subcomponents, and don't reach outside themselves. In this way
you end up building up lots of mini mvcs, one on top of the other, to manage
requirements with the approach and data structures most appropriate to each,
rather than constantly trying to bend a monolithic global model and api into
doing exactly what's needed.

You don't need a complex hierarchy of model classes for your data. Just use
json. When you need to process or manipulate it, write a function. When you
need to send or receive data from the server, $.ajax and handle the result on
whichever tier needs it. Send and receive just the data you need in just the
structure you need. No syncing or rails-like magic required.

~~~
anton-107
Well, after all when you get your modular components you still need some piece
of code to make them work together. It's not like you throw them into your
project and they magically become an application.

------
bceagle
> If you’re writing an application that will likely only be communicating with
> an API or back-end data service, where much of the heavy lifting for viewing
> or manipulating that data will be occurring in the browser, you may find a
> JavaScript MV* framework useful.

This, in my opinion is the most critical point when thinking about which
framework you want. Once you know that, for example, you are going to do a lot
of heavy UI manipulation and you do want an MV* framework, I think you end up
splitting hairs about the differences between the frameworks. Spine or
Backbone or Ember or whatever. At the end of the day, those frameworks are
just the starting point and with any application of significance, the custom
standards you put in place will have a much bigger impact than the framework
you start off with.

------
mutewinter
The suggested criteria for selecting a framework fails to ask the most
important question, what are you building?

The lightweight libraries have their place in weekend-long hack projects. The
larger frameworks lend themselves to multi-view, complex applications.

------
ch0wn
Brilliant article. Please note that this was written by Addy Osmani, best
known for TodoMVC.

------
smegel
Great article! I was just planning on starting a fairly complex Web app with
jquery, now i'm thinking I should give one of these js mvc frameworks a shot.

