5 ms·
Journey Through The JavaScript MVC Jungle
- ch0wn 14y agoBrilliant article. Please note that this was written by Addy Osmani, best known for TodoMVC.
- smegel 14y agoGreat 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.
- danenania 14y agoI 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 14y agoWell, 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.
- deleted 14y ago[deleted]
- est 14y ago> Components. Encapsulation. Modularity. Is it like drag & drop web controls to generate html & javascript?
- rsanchez1 14y agoI say Enyo JS fits this description pretty well. http://www.enyojs.com http://www.enyojs.com
- mutewinter 14y agoThe 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.
- arcos 14y agoMy big issue with all these frameworks is their near-ubiquitous use of classical OOP. I wish more would take advantage of JS's functional nature.
- bceagle 14y ago> 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.