Journey Through The JavaScript MVC Jungle
coding.smashingmagazine.com
coding.smashingmagazine.com
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.
Is it like drag & drop web controls to generate html & javascript?
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.
The lightweight libraries have their place in weekend-long hack projects. The larger frameworks lend themselves to multi-view, complex applications.