Review of JS FrameworksJourney Through The JavaScript MVC Jungle

Advertisement

When writing a Web application from scratch, it’s easy to feel like we can get by simply by relying on a DOM1 manipulation library (like jQuery412) and a handful of utility plugins. The problem with this is that it doesn’t take long to get lost in a nested pile of jQuery callbacks and DOM elements without any real structure in place for our applications.

In short, we’re stuck with spaghetti code3. Fortunately there are modern JavaScript frameworks that can assist with bringing structure and organization to our projects, improving how easily maintainable they are in the long-run.

What Is MVC, Or Rather MV*?

These modern frameworks provide developers an easy path to organizing their code using variations of a pattern known as MVC4 (Model-View-Controller). MVC separates the concerns in an application down into three parts:

  • Models represent the domain-specific knowledge and data in an application. Think of this as being a ‘type’ of data you can model — like a User, Photo or Note. Models should notify anyone observing them about their current state (e.g Views).
  • Views are typically considered the User-interface in an application (e.g your markup and templates), but don’t have to be. They should know about the existence of Models in order to observe them, but don’t directly communicate with them.
  • Controllers handle the input (e.g clicks, user actions) in an application and Views can be considered as handling the output. When a Controller updates the state of a model (such as editing the caption on a Photo), it doesn’t directly tell the View. This is what the observing nature of the View and Model relationship is for.

JavaScript ‘MVC’ frameworks that can help us structure our code don’t always strictly follow the above pattern. Some frameworks will include the responsibility of the Controller in the View (e.g Backbone.js105) whilst others add their own opinionated components into the mix as they feel this is more effective.

For this reason we refer to such frameworks as following the MV* pattern, that is, you’re likely to have a View and a Model, but more likely to have something else also included.

Note: There also exist variations of MVC known as MVP (Model-View-Presenter) and MVVM (Model-View ViewModel). If you’re new to this and feel it’s a lot to take in, don’t worry. It can take a little while to get your head around patterns, but I’ve written more about the above patterns in my online book Learning JavaScript Design Patterns6 in case you need further help.

When Do You Need A JavaScript MV* Framework?

When building a single-page application using JavaScript, whether it involves a complex user interface or is simply trying to reduce the number of HTTP requests required for new Views, you will likely find yourself inventing many of the pieces that make up an MV* framework like Backbone or Ember.

At the outset, it isn’t terribly difficult to write an application framework that offers some opinionated way to avoid spaghetti code, however to say that it is equally as trivial to write something of the standard of Backbone would be a grossly incorrect assumption.

There’s a lot more that goes into structuring an application than tying together a DOM manipulation library, templating and routing. Mature MV* frameworks typically not only include many of the pieces you would find yourself writing, but also include solutions to problems you’ll find yourself running into later on down the road. This is a time-saver that you shouldn’t underestimate the value of.

So, where will you likely need an MV* framework and where won’t you?

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.

Good examples of applications that fall into this category are GMail7 and Google Docs8. These applications typically download a single payload containing all the scripts, stylesheets and markup users need for common tasks and then perform a lot of additional behavior in the background. It’s trivial to switch between reading an email or document to writing one and you don’t need to ask the application to render the whole page again at all.

If, however, you’re building an application that still relies on the server for most of the heavy-lifting of Views/pages and you’re just using a little JavaScript or jQuery to make things a little more interactive, an MV framework may be overkill. There certainly are complex Web applications where the partial rendering of views can* be coupled with a single-page application effectively, but for everything else, you may find yourself better sticking to a simpler setup.

The Challenge Of Choice: Too Many Options?

The JavaScript community has been going through something of a renaissance over the last few years, with developers building even larger and more complex applications with it as time goes by. The language still greatly differs from those more classic Software engineers are used to using (C++, Java) as well as languages used by Web developers (PHP, Python, .Net etc). This means that in many cases we are borrowing concepts of how to structure applications from what we have seen done in the past in these other languages.

In my talk “Digesting JavaScript MVC: Pattern Abuse or Evolution9”, I brought up the point that there’s currently too much choice when it comes to what to use for structuring your JavaScript application. Part of this problem is fueled by how different JavaScript developers interpret how a scalable JavaScript application should be organized — MVC? MVP? MVVM? Something else? This leads to more frameworks being created with a different take on MV* each week and ultimately more noise because we’re still trying to establish the “right way” to do things, if that exists at all. Many developers believe it doesn’t.

We refer to the current state of new frameworks frequently popping up as ‘Yet Another Framework Syndrome’ (or YAFS). Whilst innovation is of course something we should welcome, YAFS can lead to a great deal of confusion and frustration when developers just want to start writing an app but don’t want to manually evaluate 30 different options in order to select something maintainable. In many cases, the differences between some of these frameworks can be very subtle if not difficult to distinguish.

TodoMVC: A Common Application For Learning And Comparison

There’s been a huge boom in the number of such MV* frameworks being released over the past few years.

Backbone.js105, Ember.js342211, AngularJS12, Spine13, CanJS3614 … The list of new and stable solutions continues to grow each week and developers can quickly find themselves lost in a sea of options. From minds who have had to work on complex applications that inspired these solutions (such as Yehuda Katz15 and Jeremy Ashkenas16), there are many strong contenders for what developers should consider using. The question is, what to use and how do you choose?

We understood this frustration and wanted to help developers simplify their selection process as much as possible. To help solve this problem, we created TodoMVC17 — a project which offers the same Todo application implemented in most of the popular JavaScript MV* frameworks of today — think of it as speed dating for frameworks. Solutions look and feel the same, have a common feature set, and make it easy for us to compare the syntax and structure of different frameworks, so we can select the one we feel the most comfortable with or at least, narrow down our choices.

This week we’re releasing a brand new version of TodoMVC18, which you can find more details about lower down in the apps section.

In the near future we want to take this work even further, providing guides on how frameworks differ and recommendations for which options to consider for particular types of applications you may wish to build.

Our Suggested Criteria For Selecting A Framework

Selecting a framework is of course about more than simply comparing the Todo app implementations. This is why, once we’ve filtered down our selection of potential frameworks to just a few, it’s recommend to spend some time doing a little due diligence. The framework we opt for may need to support building non-trivial features and could end up being used to maintain the app for years to come.

  • What is the framework really capable of?
    Spend time reviewing both the source code of the framework and official list of features to see how well they fit with your requirements. There will be projects that may require modifying or extending the underlying source and thus make sure that if this might be the case, you’ve performed due diligence on the code.
  • Has the framework been proved in production?
    i.e Have developers actually built and deployed large applications with it that are publicly accessible? Backbone has a strong portfolio of these (SoundCloud, LinkedIn) but not all frameworks do. Ember is used in number of large apps, including the user tools in Square. JavaScriptMVC has been used to power applications at IBM amongst other places. It’s not only important to know that a framework works in production, but also being able to look at real world code and be inspired by what can be built with it.
  • Is the framework mature?
    We generally recommend developers don’t simply “pick one and go with it”. New projects often come with a lot of buzz surrounding their releases but remember to take care when selecting them for use on a production-level app. You don’t want to risk the project being canned, going through major periods of refactoring or other breaking changes that tend to be more carefully planned out when a framework is mature. Mature projects also tend to have more detailed documentation available, either as a part of their official or community-driven docs.
  • Is the framework flexible or opinionated?
    Know what flavor you’re after as there are plenty of frameworks available which provide one or the other. Opinionated frameworks lock (or suggest) you to do things in a specific way (theirs). By design they are limiting, but place less emphasis on the developer having to figure out how things should work on their own.
  • Have you really played with the framework?
    Write a small application without using frameworks and then attempt to refactor your code with a framework to confirm whether it’s easy to work with or not. As much as researching and reading up on code will influence your decision, it’s equally as important to write actual code using the framework to make sure you’re comfortable with the concepts it enforces.
  • Does the framework have a comprehensive set of documentation?
    Although demo applications can be useful for reference, you’ll almost always find yourself consulting the official framework docs to find out what its API supports, how common tasks or components can be created with it and what the gotchas worth noting are. Any framework worth it’s salt should have a detailed set of documentation which will help guide developers using it. Without this, you can find yourself heavily relying on IRC channels, groups and self-discovery, which can be fine, but are often overly time-consuming when compared to a great set of docs provided upfront.
  • What is the total size of the framework, factoring in minification, gzipping and any modular building that it supports?
    What dependencies does the framework have? Frameworks tend to only list the total filesize of the base library itself, but don’t list the sizes of the librarys dependencies. This can mean the difference between opting for a library that initially looks quite small, but could be relatively large if it say, depends on jQuery and other libraries.
  • Have you reviewed the community around the framework?
    Is there an active community of project contributors and users who would be able to assist if you run into issues? Have enough developers been using the framework that there are existing reference applications, tutorials and maybe even screencasts that you can use to learn more about it?

Dojo And Rise Of The JavaScript Frameworks

As many of us know, the Dojo toolkit19 was one of the first efforts to provide developers a means to developing more complex applications and some might say it in-part inspired us to think more about the needs of non-trivial applications. I sat down to ask Dojos Dylan Schiemann20, Kitson Kelly, and James Thomas what their thoughts were on the rise of JavaScript MV* frameworks.

Q: Didn’t Dojo already solve all of this? Why hasn’t it been the dominent solution for developers wishing to build more structured (and more non-trivial) applications?

Years ago, while the JavaScript landscape evolved from adding simple Ajax and chrome to a page, Dojo was evangelizing a “toolkit” approach to building complex Web applications.

Many of those features were way ahead of most developers needs. With the emergence of the browser as the dominant application platform, many of the innovations pioneered in The Dojo Toolkit now appear in newer toolkits. MVC was just another package that Dojo has provided for quite some time, along with modular code packages, OO in JS, UI widgets, cross-browser graphics, templating, internationalization, accessibility, data stores, testing frameworks, a build system and much, much more.

JavaScript libraries shouldn’t end at “query”, which is why Dojo, early on, focussed on completing the picture for enterprise grade application development. This is the same focus that is has today with MVC, it’s just another “tool in the arsenal”.

Why is Dojo not the dominant toolkit? Its goal was never to be the only choice. The goal was to provide an open collection of tools that could be used with anything else, within projects, and liberally copied into other work as well. Dojo was criticized for being slow and even after that was addressed, it was criticized for being slow. Trying to shake that perception is challenging. It is very hard to document a feature-rich toolkit. There are 175 sub-packages in Dojo 1.8 and over 1,400 modules.

That is not only a challenge from a documentation purpose, it also means that there isn’t one thing that Dojo does. Which is good if you are building software, but very difficult when you are starting out trying to figure out where to start. These are all things we have been trying to work on for Dojo 1.8, in the form of tutorials and significantly improved documentation.

Q: Why should developers still consider Dojo and what ideas do you have lined up for the future of the project? I hear 1.8 will be another major milestone.

In Dojo 1.8, dojox/mvc takes another step towards full maturity. There has been a lot of investment in time, effort, testing and community awareness into the package. It focuses on providing an MVC model that leverages the rest of Dojo. Coupled with dojox/app, an application framework that is designed to make it easier to build rich applications across desktop and mobile, it makes a holistic framework for creating a
client side application.

In the typical Dojo way, this is just one of many viable ways in which to build applications with Dojo.

In 1.8, not only does the MVC sub-module become more mature, it is built upon a robust framework. It doesn’t just give you markup language to create your views, express your models or develop a controller. It is far more then just wiring up some controls to a data source. Because it is leveraging the rest of Dojo, you can draw in anything else you might need.

In Dojo 2.0 we will be looking to take modularity to a new level, so that it becomes even easier to take a bit of this and a bit of that and string it all together. We are also exploring the concepts of isomorphism, where it should be transparent to the end-user where your code is being executed, be it client side or server side and that ultimately it should be transparent to the developer.

The TodoMVC Collection

In our brand new release, Todo implementations now exist for the most popular frameworks with a large number of other commonly used frameworks being worked on in Labs. These implementations have gone through a lot of revision, often taking on board best practice tips and suggestions from framework authors, contributors and users from within the community.

Following on from comments previously made by Backbone.js author Jeremey Ashkenas and Yehuda Katz, TodoMVC now also offers consistent implementations based on an official application specification as well as routing (or state management).

We don’t pretend that more complex learning applications aren’t possible (they certainly are), but the simplicity of a Todo app allows developers to review areas such as code structure, component syntax and flow, which we feel are enough to enable a comparison between frameworks and prompt further exploration with a particular solution or set of solutions.

Our applications include:

For those interested in AMD versions:

And our Labs include:

Note: We’ve implemented a version of our Todo application using just JavaScript60 and another using primarily jQuery conventions61. As you can see, whilst these applications are functionally equivalent to something you might write with an MVC framework, there’s no separation of concerns and the code becomes harder to read and maintain as the codebase grows.

We feel honored that over the past year, some framework authors have involved us in discussions about how to improve their solutions, helping bring our experience with a multitude of solutions to the table. We’ve also slowly moved towards TodoMVC being almost a defacto app that new frameworks implement and this means it’s become easier to make initial comparisons when you’re reviewing choices.

Frameworks: When To Use What?

To help you get started with narrowing down frameworks to explore, we would like to offer the below high-level framework summaries which we hope will help steer you towards a few specific options to try out.

I want something flexible which offers a minimalist solution to separating concerns in my application. It should support a persistence layer and RESTful sync, models, views (with controllers), event-driven communication, templating and routing. It should be imperative, allowing one to update the View when a model changes. I’d like some decisions about the architecture left up to me. Ideally, many large companies have used the solution to build non-trivial applications. As I may be building something complex, I’d like there to be an active extension community around the framework that have already tried addressing larger problems (Marionette62, Chaplin63, Aura64, Thorax65). Ideally, there are also scaffolding tools (grunt-bbb66, brunch67) available for the solution. Use Backbone.js.

I want something that tries to tackle desktop-level application development for the web. It should be opinionated, modular, support a variation of MVC, avoid the need to wire everything in my application together manually, support persistence, computed properties and have auto-updating (live) templates. It should support proper state management rather than the manual routing solution many other frameworks advocate being used. It should also come with extensive docs and of course, templating. It should also have scaffolding tools available (ember.gem, ember for brunch). Use Ember.js.

I want something more lightweight which supports live-binding templates, routing, integration with major libraries (like jQuery and Dojo) and is optimized for performance. It should also support a way to implement models, views and controllers. It may not be used on as many large public applications just yet, but has potential. Ideally, the solution should be built by people who have previous experience creating many complex applications. Use CanJS.

I want something declarative that uses the View to derive behavior. It focuses on achieving this through custom HTML tags and components that specify your application intentions. It should support being easily testable, URL management (routing) and a separation of concerns through a variation of MVC. It takes a different approach to most frameworks, providing a HTML compiler for creating your own DSL in HTML. It may be inspired by upcoming Web platform features such as Web Components and also has its own scaffolding tools available (angular-seed). Use AngularJS.

I want something that offers me an excellent base for building large scale applications. It should support a mature widget infrastructure, modules which support lazy-loading and can be asynchronous, simple integration with CDNs, a wide array of widget modules (graphics, charting, grids, etc) and strong support for internationalization (i18n, l10n). It should have support for OOP, MVC and the building blocks to create more complex architectures. Use Dojo.

I want something which benefits from the YUI extension infrastructure. It should support models, views and routers and make it simple to write multi-view applications supporting routing, View transitions and more. Whilst larger, it is a complete solution that includes widgets/components as well as the tools needed to create an organized application architecture. It may have scaffolding tools (yuiproject), but these need to be updated. Use YUI.

I want something simple that values asynchronous interfaces and lack any dependencies. It should be opinionated but flexible on how to build applications. The framework should provide bare-bones essentials like model, view, controller, events, and routing, while still being tiny. It should be optimized for use with CoffeeScript and come with comprehensive documentation. Use Spine.

I want something that will make it easy to build complex dynamic UIs with a clean underlying data model and declarative bindings. It should automatically update my UI on model changes using two-way bindings and support dependency tracking of model data. I should be able to use it with whatever framework I prefer, or even an existing app. It should also come with templating built-in and be easily extensible. Use KnockoutJS.

I want something that will help me build simple Web applications and websites. I don’t expect there to be a great deal of code involved and so code organisation won’t be much of a concern. The solution should abstract away browser differences so I can focus on the fun stuff. It should let me easily bind events, interact with remote services, be extensible and have a huge plugin community. Use jQuery.

 

What Do Developers Think About The Most Popular Frameworks?

As part of our research into MV* frameworks for TodoMVC and this article, we decided to conduct a survey to bring together the experiences of those using these solutions. We asked developers what framework they find themselves using the most often and more importantly, why they would recommend them to others. We also asked what they felt was still missing in their project of choice.

We’ve grouped some of the most interesting responses below, by framework.

Ember.js

Pros: The combination of live templates and observable objects has changed the way I write JavaScript. It can be a bit much to wrap your head around at first, but you end up with a nice separation of responsibility. I found that once I have everything set up, adding fairly complex features only takes a couple lines of code. Without Ember, these same features would’ve been hellish to implement.

Cons: Ember has yet to reach 1.0. Many things are still in flux, such as the router and Ember data. The new website is very helpful, but there’s still not as much documentation for Ember as there is for other frameworks, specifically Backbone. Also, with so much magic in the framework, it can be a little scary. There’s the fear that if something breaks you won’t be able to figure out exactly why. Oh, and the error messages that ember gives you often suck.

Pros:
The key factors:

a) Features that let me avoid a lot of boilerplate (bindings, computer properties, view layer with the cool handlebars).

b) the core team: I’m a Rails developer and know the work of Yehuda Katz. I trust the guy =)

Cons: Documentation. It’s really sad that Ember doesn’t have good documentation, tutorials, screencast like Backbone, Angular or other frameworks. Right now, we browse the code looking for docs which isn’t ideal.

Pros: Convention over configuration. Ember makes so many small decisions for you it’s by far the easiest way to build a client-side application these days.

Cons: The learning curve. It is missing the mass of getting started guides that exist for other frameworks like Backbone, this is partly because of the small community, but I think more because of the state of flux the codebase is in pre-1.0.

Pros: Simplicity, bindings, tight integration with Handlebars, ease of enabling modularity in my own code.

Cons: I’d like to have a stable integration with ember-data, and integrated localStorage support synced with a REST API, but hey that’s fantasy that one day will surely come true ;-)

Backbone.js

Pros: Simplicity — only 4 core components (Collection, Model, View, Router). Huge community (ecosystem) and lots of solutions on StackOverflow. Higher order frameworks like Marionette or Vertebrae with lots of clever code inside. Somebody might like “low-levelness” — need to write lots of boilerplate code, but get customized application architecture.

Cons: I don’t like how extend method works — it copies content of parent objects into new one. Prototypal inheritance FTW. Sometime I miss real world scenarios in docs examples. Also there is a lot of research needed to figure out how to build a bigger app after reading the TODO tutorial.

I’m missing official AMD support in projects from DocumentCloud (BB, _). [Note: this shouldn’t be an issue with the new RequireJS shim() method in RequireJS 2.0].

Pros: After the initial brain-warp of understanding how Backbone rolls, it is incredibly useful. Useful as in, well supported, lightweight, and constantly updated in a valid scope. Ties in with natural friends Underscore, jQuery/Zepto, tools that most of my studio’s projects would work with.

Cons: The amount of tutorials on how to do things with Backbone is inconsistent and at different periods of Backbones lifespan. I’ve asked other devs to have a look at Backbone, and they would be writing code for v0.3. Un-aware. Whilst not a problem Backbone can fix itself, it is certainly a major dislike associated with the framework.

I suppose in theory, you could apply this to anything else, but, Backbone is a recurrent one in my eyes. Hell, I’ve even seen month old articles using ancient Backbone methods and patterns.

Whatever dislikes I would have on the framework strictly itself, has been rectified by the community through sensible hacks and approaches. For me, that is why Backbone is great, the community backing it up.

Pros: Provides just enough abstraction without unreasonable opinions — enabling you to tailor it to the needs of the project.

Cons: I would re-write (or possibly remove) Backbone.sync. It has baked in assumptions of typical client-initiated HTTP communications, and doesn’t adapt well to the push nature of WebSockets.

Pros: It’s extremely easy to get into, offering a nice gateway to MV* based frameworks. It’s relatively customizable and there are also tons of other people using it, making finding help or support easy.

Cons: The fact that there’s no view bindings by default (although you can fix this). Re-rendering the whole view when a single property changes is wasteful.

The RESTful API has a lot of positives, but the lack of bulk-saving (admittedly a problem with REST itself, but still) and the difficulty in getting different URI schemes to work on different types of operations sucks.

AngularJS

Pros:

a) 2-way data binding is incredibly powerful. You tend to think more about your model and the state that it is in instead of a series of events that need to happen. The model is the single source of truth.

b) Performance. AngularJS is a small download. It’s templating uses DOM nodes instead of converting strings into DOM nodes and should perform better.

c) If you are targeting modern browsers and/or are a little careful, you can drop jQuery from your dependencies too.

Cons: I’d like to be able to specify transitions for UI state changes that propgate from a model change. Specifically for elements that use ng-show or ng-hide I’d like to use a fade or slide in in an easy declarative way.

Pros: It’s very intuitive, has excellent documentation. I love their data binding approach, HTML based views, nested scopes. I switched from Backbone/Thorax to Angular and never looked back. A new Chrome extension Batarang integrates with Chrome Developer’s Tools and provides live access the Angular data structures.

Cons: I’d like to have a built-in support to such functions as drag’n’drop, however this can be added using external components available on GitHub. I’d also like to see more 3rd party components available for reuse. I think it’s just a matter of time for the ecosystem around AngularJS to get more mature and then these will be available just like they are in communities like jQuery.

Pros: It minimizes drastically the boilerplate code, allows for nice code reuse through components, extends the HTML syntax so that many complex features end up being as simple as applying a directive (attribute) in the HTML, and is super-easily testable thanks to a full commitment to dependency injection.
You can write a non-trivial app without jQuery or without directly manipulating the DOM. That’s quite a feat.

Cons: Its learning curve is somewhat steeper than Backbone (which is quite easy to master), but the gain is appreciative. Documentation could be better.

KnockoutJS

Pros: I don’t necessarily use it all the time, but KnockoutJS is just fantastic for single page applications. Extremely easy subscribing to live sorting; much better API for so called “collection views” in Backbone using observable arrays. And custom event on observables for effects, etc.

Cons: Feel like the API is quite hard to scale, and would probably prefer to wrangle Backbone on the bigger applications. (But that’s also partially due to community support).

Pros: I like the data binding mechanism and feel very comfortable using it. In particular I like how they have replaced templates with control flow binding.

Cons: I don’t like that there is no guidance or best practice in terms of application structure. Aside from having a view model, the framework doesn’t help you in defining a well structured view model. It’s very easy to end up with a large unmaintainable function.

Dojo

Pros: Syntactically, Dojo is very simple. It allows for dynamic and robust builds, with the initial loader file being as low as 6k in some cases. It is AMD compatible, making it extremely portable, and comes out-of-the-box with a ton of features ranging from basic dom interactions to complex SVG, VML, and canvas functionality. The widget system, Dijit, is unmatched in it’s ease-of-use and ability to be extended. It’s a very well-rounded and complete toolkit.
Cons: The dojo/_base/declare functionality is not 100% strict mode compliant and there is currently some overhead due to backwards compatibility, though this will mostly go away in the Dojo 2.0 release.

Pros: Good components : tabs, datagrid, formManager… Renders the same cross browser. AMD compliant. Easy to test with mocks.Integrates well with other frameworks thks to amd (I ll integrate with JMVC)
Cons: Default design for components out of fashion. Not fully html5. So-so documentation
Poor templating system (no auto binding).

YUI

Pros: YUI3 is a modular and use-at-will type of component library which includes all of the goodies of Backbone and more. It even (in my opinion) improves upon some of the concepts in Backbone by de-coupling some things (i.e. attribute is a separate module that can be mixed into any object – the event module can be mixed in similarly).

Cons: I’d love to see YUI3 support some of the auto-wiring (optional) of Ember. I think that is really the big win for Ember; otherwise, I see YUI3 as a superior component library where I can cherry-pick what I need. I’d also like to see a more AMD-compatible module loader. The loader today works very well; however, it would be nicer if I could start a new projects based on AMD modules and pull in certain YUI3 components and other things from other places that are also using AMD.

JavascriptMVC

Pros: Has all tools included, just need to run commands and start building. I have used for the last 6 months and it’s been really good.

Cons: The only thing I would do is to speed up development of the next version. Developers are aware of problems and fixing issues but its going to be another ¾ months before some issues I want fixed are addressed, but then I could probably patch and do a pull request.

Maria

Pros: Because Maria is a pure MVC framework that is focused on being just an MVC framework. No more and no less. Its clean and simple.

Cons: A little more usage documentation outside of the source code, plus a few more test cases. A tutorial that drives home the real use of MVC with Maria would be good too.

Cujo.js

Pros: Real apps almost never fit perfectly into an MV* box, and the most important stuff is often outside the box. With cujo.js, you define the box.

Yes, cujo.js has high-level MV*-like features for creating views, models, controllers, etc., but every app is different, and no framework can ever be a 100% solution. Rather than try to be all things, cujo.js also provides lower level tools, architectural plumbling, and a rich plugin system that can even be used to integrate and extend other MV* frameworks.

Create the architecture that best suits your application, rather than constraining your app to fit inside someone else’s predefined architecture.

Cons: The broader JavaScript community is totally unprepared and untrained to take on large-scale applications. Most of us don’t even know that design patterns and architectural patterns exist.

Since cujo.js is so different from other frameworks, it needs more than a simple API reference and code snippets. Without tutorials, educational materials, and step-by-step examples, cujo.js might look strange and overwhelming to the untrained eye but documentation is supposed to be coming soon.

ExtJS

Pros: I think ExtJS works best in combination with Ext Designer. It gives it an edge beyond the other GUI frameworks by letting non-programmers mock up the UI so programmers can fill in the blanks. I think comparing it to MVC frameworks like Backbone doesn’t do it justice – its strength lies in creating rich GUIs, not lean Web apps.

For rich, commercial back-office applications I think ExtJS remains the best choice when it comes to JavaScript solutions (i.e. not GWT etc). For public-facing Web apps I’d rather have something that gives me more control over the markup (and ideally something that degrades gracefully).

Cons: It has a steeper learning curve than many of the other modern structural frameworks. One can argue that if you’re investing in ExtJS for the long-term this time spent learning will pay off, however I think solutions like it should aim to better minimize the time it takes to train teams up in using it.

Pros: I think a big feature of ExtJS 4 is that it throws you into the MVC mindset and the preferred filesystem structure right from the bat. With Dojo the initial tutorials seem to be mostly about augmenting existing websites whereas ExtJS assumes you’re starting from scratch.

Using ExtJS doesn’t really “feel” like you’re dealing with HTML at all. The component library is rich enough to let you go a long way without touching more HTML than what is needed to bootstrap your app.

It’d be interesting to see how both compare when Web components become more widely supported. This would finally allow manipulating the DOM without being afraid of breaking any widgets or causing your app’s internal state to become inconsistent.

Cons: The licensing is considered restrictive and difficult to understand by some. More people would be investing in ExtJS if it was clearer what the upfront and long-term costs of using it are. This isn’t a concern with some other structural solutions but probably isn’t as much a worry for larger businesses.

Pros: ExtJS is a fantastic package for rapidly building out RIAs for internal use. I for one, love to build with HTML and JavaScript, and for me there’s great satisfaction in mucking around at that level. Even though ExtJS makes it feel like you’re not really working with HTML it still offers a great deal of power, especially if you’re using it to create a complex UI.

Cons: That said…I absolutely agree that it’s very heavy and I don’t think I’d recommend it for an external facing Web application. My biggest beef with the package overall is actually that it’s more of a PITA to test with than I’d would like. Our tester actually ended up switching to Sikuli because it was becoming too much of a battle trying to work with it in Selenium.

Batman

Pros: It has a great and easy to use view bindings system. Plays with Rails very nicely and is all about convention over configuration.

Cons: The documentation could be a lot better and I feel Shopify won’t be adding the features that they say that they will.

Don’t Be Afraid To Experiment

Whilst it’s unlikely for a developer to need to learn how to use more than a handfull of these frameworks, I do encourage exploration of those you’re unfamiliar with. There’s more than mountain of interesting facts and techniques that can be learned in this process.

In my case: I discovered that Batman.js required the least hand-written lines of code for an implementation. I’m neither a frequent CoffeeScript nor Batman.js user but that in itself gave me some food for thought. Perhaps I could take some of what made this possible and bring it over to the frameworks I do use. Or, maybe I’d simply use Batman.js in a future project if I found the community and support around it improved over time.

Regardless of whether you end up using a different solution, at the end of the day all you have to gain from exploration is more knowledge about what’s out there.

Going Beyond MV* Frameworks

Whilst the MV* family of patterns are quite popular for structuring applications, they’re limited in that they don’t address any kind of application layer, communication between Views, services that perform work or anything else. Developers may thus find that they sometimes need to explore beyond just MVC — there are times when you absolutely need to take what they have to offer further.

We reached out to developers that have been taking MVC further with their own patterns or extensions for existing frameworks to get some insights on where you need something more.

“In my case, I needed something Composite. I noticed that there were patterns in Backbone apps where developers realized there was a need for an object that coordinated various parts of an application. Most of the time, I’ve seen developers try to solve this using a Backbone construct (e.g a View), even when there isn’t really a need for it. This is why I instead explored the need for an Application Initializer68.

I also found that MVC didn’t really describe a way to handle regions of a page or application. The gist of region management69 is that you could define a visible area of the screen and build out the most basic layout for it without knowing what content was going to be displayed in it at runtime.

I created solutions for region management, application initialization and more in my extension project Marionette. It’s one of a number of solutions that extend upon a framework (or architecture pattern) that developers end up needing when they’re building single-page applications that are relatively complex.

There’s even a TodoMVC Marionette app70 available for anyone wishing to compare the standard Backbone application with one that goes beyond just MV*.

Derick Bailey — Author of Marionette

“While a good portion of problems can be decomposed into JavaScript MVC, there are some which simply cannot. For example, an application consumes a third party API at runtime, but is not given any information as to how the data will be structured.

I spent almost a year trying to solve that very problem, but eventually I came to the realization that shoehorning it into MV* was not a viable solution. I was dealing with an “amorphous model” and that’s where it all fell apart. In other words, if you don’t have a well-defined model, most modern JavaScript frameworks can’t help you.

That’s where Core J2EE Pat­terns71 come in. I got turned on to them while read­ing PHP Objects, Pat­terns, and Prac­tice72 by Matt Zand­stra, and I’m glad I did! The J2EE Patterns basically outline a request-driven process, where the URL drives the behavior of the application. In a nutshell, a request is created, modified, and then used to determine the view to render.

I’ve expanded on my experiences with request driven Javascript applications and J2EE patterns73 for anyone who would like to learn more. ”

Dustin Boston — co-author, Aura

Conclusions

While there are several choices for what to use for structuring your JavaScript Web applications these days, it’s important to be diligent in the selection process – spend time thoroughly evaluating your options in order to make a decision which results in sustainable, maintainable code. Framework diversity fosters innovation, while too much similarity just creates noise.

Projects like TodoMVC can help narrow down your selections to those you feel might be the most interesting or most comfortable for a particular project. Remember to take your time choosing, don’t feel too constrained by using a specific pattern and keep in mind that it’s completely acceptable to build on the solution you select to best fit the needs of your application.

Experimenting with different frameworks will also give you different views on how to solve common problems which will in turn make you a better programmer.

Thanks to my fellow TodoMVC team-member Sindre Sorhus74 for his help with tweaks and a technical review of this article. 

↑ Back to topShare on Twitter

Addy Osmani is a Developer Programs Engineer on the Chrome team at Google. A passionate JavaScript developer, he has written open-source books like 'Learning JavaScript Design Patterns' and 'Developing Backbone Applications', having also contributed to open-source projects like Modernizr and jQuery. He is currently working on 'Yeoman' - an opinionated workflow for building beautiful applications.

  1. 1

    Looks very interesting. This will be a good read for the weekend. Thanks Addy ;)

    0
  2. 3

    Remo Brunschwiler

    July 27, 2012 3:27 am

    Thanks Addy! Great article! It gives a very good overview about the existing MV* frameworks. And I really like your «What Is MVC, Or Rather MV*?» intro, as it makes clear, that the purpose is mainly for single-page applications with the need for client-side models and would be overkill for most «traditional» – eg. CMS related – stuff. Btw: there are other frameworks – eg. TerrificJS – that are built especially for the latter case.

    0
    • 4

      Not at all. You mentioned TerrificJS – one of our goals for the next version of TodoMVC will be tackling frameworks that go a little futher. There are quite a few now tackling real-time development or full end to end stacks (SocketStream, Meteor etc) and more looking at complex modular architectures (TerrificJS, Chaplin, Aura). We want to try helping developers compare these solutions as easily as possible too, so watch this space!.

      0
  3. 5

    Thanks for the round up, Addy. Do you have any recommendation for a book or tutorial that explains how to go from jQuery to Backbone using what you feel are Backbone’s best practices? When I look at the Backbone examples there are lots of different implementations but I want to know what costly architecture mistakes to avoid at the beginning for a large web app.

    0
  4. 11

    Fabricio Martínez Tamayo

    July 27, 2012 4:07 am

    From an architectural point of view, inst it a bit too much to move MVC from say the server platform (PHP, .NET, JSP) to the client in JavaScript? I’m sure you can do crazy things in JavaScript but was it meant to? Also how about the implications of the added download file sizes, etc.

    0
    • 12

      What we’re finding these days is that there are a growing number of developers creating complex web applications that are primarily based in the browser (i.e you have a JavaScript client communicating with a server-side API just for data). These applications are non-trivial enough (GMail is always a great example) that separating out their concerns almost always helps improve maintainability. In this light, I don’t think that architectural patterns like MVC are overkill, but we do have to be careful how and where we use them.

      The implications on download file size are that developers have to make decisions about when their users will have to download the ‘payload’ of scripts. Some applications (like Google Docs) take a dynamic approach to this, only making users download the bare minimum set of scripts for common functionality initially, but then pulling in other scripts (for things like the formula editor) when you select that option from the menu. Other applications just ask users to download most of the scripts when you first fire them up and you do have to keep performance and speed in mind.

      No one wants to be downloading 2MB of JavaScript unnecessarily.

      0
    • 13

      I have the same question come up from devs of whom I support. I totally agree. MVC needs to be handled by the server-side folks. My problem with most javascript people on the web is that they don’t really know how to code, and rely solely on JQuery and other libraries to do it. The article above makes matters worse by adding a layer of MVC to the mix. This becomes a problem when you have enterprise logic laced with 3rd party proprietary code where its founders clearly have their own agenda.

      0
      • 14

        Prejudice much? Just because most of the “Javascript people” that you don’t know how to code (according to you, at least), doesn’t mean the there is great coders out there who knows how to write great code. I guess you just need to get out a bit, get some fresh air and meet more interesting people, you know – those who can write great codes doesn’t matter what the language they use. Those people do exist, I can attest to that.

        > “This becomes a problem when you have enterprise logic laced with 3rd party proprietary code where its founders clearly have their own agenda.”

        Seriously man, whats up with that? Does that even mean something? These libraries are open source, and quite a number of them are just libraries, its up to you to dictate your own architecture and layers. Yes, layers, we do know how layer our apps as needed. Shocking, I know.

        0
  5. 15

    Soooooo. We had a hard time deciding which back-end framework to use, now we have to worry about the front-end too :-(

    0
    • 16

      I feel you. There’s a challenge of choice, I agree, but thinking more about the architecture needed for JavaScript-heavy apps. is a necessary part of the evolution of how we write web applications these days – perhaps this is easier for teams where there are specific developers working on the frontend and backend?.

      Users prefer speed and snappiness over complete page reloads and bringing more of the UI logic to the browser means these speed improvements are more easily possible – these frameworks just help ensure the architecture of these UIs remains maintainable. If you also consider more advanced needs, like offline-support and more specifically, offline-sync, backend only code is only able to go so far with the needs of todays UIs.

      0
    • 17

      My advice to start with is not to mull over it too much and pick a library with good documentation and start a project with it. After that, if you find yourself craving the features of another MV library you will find it is not hard to jump over and learn it for your next project.

      0
  6. 18

    Dom Barker (@MostlyHarmlessD)

    July 27, 2012 7:46 am

    I’ve used JMVC and Knockoutjs quite a bit. Of the two I have preferred JMVC. I love the event based architecture, generators (rails devs will be right at home) and the funcunit testing framework that’s bundled along with it.

    Slightly perturbed about the emergence of CanJS though. I still can’t work out if it’s supposed to be an alternative or sucessor to JMVC.

    0
    • 19

      I remember speaking to Justin Meyer (one of the core developers behind CanJS and JavaScriptMVC) sometime ago and my understanding was that CanJS was meant to be a leaner version of JMVC that could be considered an alternative to lighter MV* frameworks such as Backbone.js. A newer project, Done.js would ultimately replace JMVC (but offer most/all of it’s capabilities) but that’s probably still a short while away. Jupiter/Bitovi have always tried doing well by their users and if you enjoy JMVC, I would ask them about Done.js and how soon that might be available.

      0
  7. 22

    It was really difficult for me to get into backbone.js and I would probably had gave it up if I wasn’t forced to but it’s really paying off and I trully reccomend it for every front end developer. There is a free ebook available if you search google that helped me a lot. Ember.js seems cool and I might give it a try.
    Thanks for the great article.

    0
  8. 23

    Thanks for this eye-opening and very informative roundup. I am just worried that by the time I understand all this, half a dozen new frameworks will have popped up…

    0
  9. 24

    Under “Frameworks: When To Use What?” is the description for angular mixed up? Looks like the framework before ang has the ang description.

    0
  10. 25

    J Cole Morrison

    July 27, 2012 5:32 pm

    This is incredibly helpful and useful. Thanks so much for your input and especially the ebook on Javascript design patterns! You’re the type of person that helps push Javascript towards a better maturity that’s not just copying other languages.

    0
  11. 27

    Addy, Thanks for a great summary of MV* frameworks.
    Have a question, on the “Frameworks: When To Use What?” section, did you get backbone and ember mixed up?

    0
    • 28

      Hi. There wasn’t a mix up but I think the positioning of the recommendation text below the framework summaries may have given this impression. I updated the article to make this more clear.

      0
  12. 29

    I agree with the con for knockout in that the viewmodel begins to feel like a large function but i found with the combination of requirejs and being able to bind multiple viewmodels to partial views on the page really helps make a complex ui much more maintainable. Thank you so much for this write-up I’m definitely going to share this w/ my friends.

    0
  13. 30

    To experiment these tools will be my holiday work, and I do think I will definitely have fun with it, thanks for all your hard working on it, I will summarize it as a blog post in Chinese to spread the evolution of frontend MVC :)

    0
  14. 31

    Great article. I can see the benefits of having so much choice but it would be good if there was a widely enough adopted MV framework that it would become a first choice option when building web apps, the same way in which JQuery has become a standard choice (well for myself anyway). Sometimes too much choice can be a bad thing.

    0
    • 32

      You’re absolutely spot on with questioning the merits of having so many options available. I think in the case of JavaScript MV* frameworks, there’s still a great deal of uncertainty about what the best (or right) way to approach structure is, which is why so many developers try to offer their own take on this.

      I think that in time, once the adoption rates of a few specific frameworks improve we’ll move closer and closer to convergence. I don’t see there being just one single framework that’s recommended for use, but perhaps fewer than a hand-full that the community at large consider *the* right options.

      0
  15. 33

    David Mair Spiess

    July 28, 2012 12:13 am

    Awww, i have spent so much time evaluating over a lot of these frameworks. And if you finaly choose one for the job, you have this feeling in the back of your head, is this tool really the appropriate one.
    I find myself often switch framework if i get stuck on something i don’t like, instead of investigating deeper.

    0
    • 34

      Is there a framework you find yourself using more often than the others? Sometimes it’s better to invest time in writing utilities that build upon what you commonly use rather than regularly switching between a few solutions (which probably have their own learning curve required to use them).

      0
  16. 35

    Adrian Florescu

    July 28, 2012 1:51 am

    I want to start writing non spaghtti code.

    I will review in depth all pros and cons for all of the framework, and based on that I will choose my first framework!

    Thank for this article.

    0
  17. 37

    What about the newly announced Wakanda ? It’s seems to be a more complete JavaScript solution (Framework + visual designer + fast server) and it’s open source.

    Wakanda Framework
    Widgets and the fast, standards-based datasources that feed them.

    Wakanda Studio
    A visual designer for your datastore and front end, as well as code editor.

    Wakanda Server
    A super-rapid datastore and HTTP server, it’s a home for all your app’s business logic.

    http://www.wakanda.org/

    ====

    Also what about Enyos the open source framework for WebOS ?? Full object ore=iented Javascript framework with a strong focus on web mobile applications

    http://enyojs.com/

    0
  18. 38

    I think the next year is going to bear witness to more change than JS has seen in its history, and things that people have never heard of will become, if not widespread, at least widely know.

    0
  19. 39

    Once again Addy, nicely done. More explaining and less “Build Twitter with * ” articles are an excellent resource for the community. We need these ones every now and then. The sheer choice to frameworks is ridiculous, becoming a haunting ultimatum for choosing your Christmas present as a child. Just one pick.

    TodoMVC is an awesome resource. I hope it continues to grow.

    Some nice dev quotes there too :)

    0
  20. 40

    I’d be curious to see 3 more attributes for selection:

    1st, whether the framework can be incrementally adopted or requires full adoption. For instance, I have an existing application with traditional page-request model. I’d like to use an MV*-like approach to first create some rich widgets, taking advantage of component model-view data binding, recommended AJAX methods, etc. I’ll eventually go on to take full advantage of the power of the framework, including routing for sub-parts of the site. I believe that Backbone is fine for this (just ignore Routers at first) and obviously something full-stack like Meteor is ruled out, but I don’t yet understand whether all the excellent options you included might also work for me.

    2nd, whether the framework can live side-by-side with existing JQuery components or standalone JQuery code. In my opinion there’s too much good stuff happening in the wider JQuery community to commit to a framework that makes it difficult to adopt components individually. And it’s not just a matter of making sure that the underlying DOM isn’t dynamic/obscured, it also has to be careful about aggressively refreshing parts of the page, etc. There’s a middle ground where you can – without modifying the component’s source – write a little external scaffolding code to trigger framework sync events.

    3rd, less important but also interesting, is compatibility with popular server-side frameworks. Is it easy to apply a particular framework on top of WordPress, Drupal, Django, Rails, whatever? I suspect that many of these are designed specifically for Rails but would require some server-side adapters for usage in PHP, etc. If this is already done, it’s likely due to community adoption as much as technical effort on the framework developers.

    Thanks for a really useful article!

    0
    • 41

      I call your first criterion “augmentation”, the ability to augment existing sites or apps. One of the dev quotes mentions Dojo being able to tackle that use case, and KnockoutJS also gets a mention for that above: “I should be able to use it with whatever framework I prefer, or even an existing app”.

      I haven’t seen much about your third criterion, except some tutorials on coupling a server-side framework, used strictly to provide a REST API, with a client-side MVC framework. eg, Django + TastyPie (an excellent REST framework) + Backbone.js. The REST part is easy, but that doesn’t really deal with refreshes, AMD, and other integration problems one would encounter in a hybrid app.

      0
  21. 42

    It’s not just the framework, it’s the tooling and IDEs and how they work with.

    0
  22. 43

    Hi Addy, first of all, great article. You should receive an award for this, made my day. You had me at the explanation on what should I use and why.
    I have a question, though.. we’ve seen companies like twitter backing down from client-side rendering because of performance issues (apparently, all the resources were being loaded on the fly..?) and constantly I read that many devs are building apps this way and leaving the body tag without a single piece of information, resulting in bad SEO.
    What’s your hunch about that? Sorry if I wasn’t clear enough.

    0
  23. 46

    Thx for the great article.
    I`m missing mootools :)

    0
  24. 48

    Nicola Peluchetti

    July 30, 2012 7:55 am

    Great article. Really helpful, it was something that was needed. Thanks also for answering @Caio’s question :)

    0
  25. 49

    Regarding JMVC, what features need to get fixed? Any feature in JMVC that needs to get fixed is almost certainly not even in the other frameworks. The only “tricky” thing I’m aware of is packages implicit dependency problem. But, packages is unreleased feature.

    0
    • 50

      Justin, I couldn’t resist posting to thank you and all your team for the work you put into JMVC and now Can.js. It is truly a beautiful, highly productive framework, and I love to work with it.

      0
  26. 51

    Hi,
    We are looking to migrate from a gwt app into ember.
    I am looking for some info about side by side option for the transition period, plus any plan/guidelines on how to do the conversion as painless as possible.

    10xs in advance.

    0
  27. 52

    Thanks for the excellent tour de JS MVC and related frameworks. I am a long time ExtJS user delving into the new lighter weight offerings (backbone.js and angular.js in particular) and it’s great to get the benefit of others experience making these architectural decisions.

    0
  28. 53

    Thanks for the nice read with full of information. Your post has made the whole new Javascript concept crystal clear. You have real described it well what MVC is and how it actually is used. I have little confusion about the Backbone. It would be great if you can explain it.

    0
  29. 54

    Great Article!

    0
  30. 55

    Our Vanilla example is not meant to demonstrate MVC (neither is the jQuery one). They’re there to show developers how a non-MVC application without the decoupling of concerns would manifest so they can see how to take say, spaghetti code and turn it into something more organized. The closest thing we have to true MVC is possibly the Maria.js implementation, but we’ll be happy to take a look at what you’ve put together!

    0
  31. 56

    One thing i would like to know is the scale of complexity each framework can accomplish. For Eg. Can backbone create something massive like Google Docs? Dojo can (I think). Ember says it is for creating “ambitious web application”. The example on the site for a helpdesk doesn’t look ambitious to me. Perhaps it is underneath.

    A warning for every framework would be nice like “Not for massive applications stay small or medium size”

    0
  32. 57

    Darren Sherwood

    August 7, 2012 4:50 pm

    Hi Addy

    I am also wondering how you fell google’s closure library fits into this (given you work for google). I understand it does not have data binding and is a library of controls and utilities so I imagine it is something that could be used in combination with one of these ‘mvc-ish’ frameworks. Perhaps you could ask around at google who has done so.

    I guess I would also like someone to do a similar round-up comparing HTML5 boilerplate, bootstrap, jQueryUi / jQuery Mobile, closure and also this new one (http://keyholesoftware.wordpress.com/2012/08/06/montage/)

    …AND some advice on how well these work together to provide lightweight web apps that adapt well to different devices.

    Then again I expect this will come from the Yeoman project team when they come to explain the choices of their chosen components?

    0
  33. 58

    Hello.
    Correct me if I’m wrong, but I think, backbone.js has prototypal inheritance. It’s Model.extend() is not a shortcut to Underscore.js _.extend(), which does copy object attributes. Check this out https://github.com/documentcloud/backbone/blob/master/backbone.js#L1323 with their “inheritrs()” helper.

    0
  34. 59

    “There certainly are complex Web applications where the partial rendering of views can* be coupled with a single-page application effectively, …”

    I really like what you are doing with Aura. But I am having a difficult time migrating my understanding of it into the above scenario. Is the can-asterik in your sentence essentially a footnote that “it may be too difficult?” The php-based CMS I am using manages a lot of documents and ties a large user/club relationship association together, but developing a single page js api within a CMS page would really help the UI experience. (So I’m hoping your answer is: “it’s easy!”) :)

    Are you far off from showing a more complex Aura example (which you state is an intention of yours) ? The Aura TODO example you give does not use routes and I could use it. :)

    Finally, “Thank you.” In trying to take my technical skills into the web I have had to read enormous amounts of information. Your writings are some of the best (if not “the best”). And in my view, how you have built a decoupled, widget-based api with a mediator pattern is excellent and I can see it safeguarding my investment in learning it (due to it’s modularity) compared to other JS frameworks.

    0
  35. 60

    I was always confused about knockout and backbone, because I have study both of these.but you cleared my mind.

    I have create some projects with knockout.js, because its simple and quite easy the remaining library is too complicated or either not explained well.

    Thanks

    0
  36. 61

    Sorry but I don’t understand the purpose of all this JS MVC frameworks. Isn’t the DOM already MVC?
    It looks like these frameworks implement a lot of useless abstractions.
    Just have a look at the JQuery+Handlebars version of the TodoMVC application. It contains 10 times less artifacts than any other versions.
    In fact you don’t have to put all your control logic in one big js file. You can split it vertically by use cases in multiple files.
    You can also separate event binding logic from the control logic itself.
    I don’t read here any arguments (execpt the obvious ‘Don’t write spaghetti code’) in favour of these frameworks?!
    So what can I do with these MVC frameworks that I can NOT do with JQuery (and plugins) that justify the use of the heavy abstractions provided by them?

    0
  37. 62

    Nice article. It would have helped if you provided a definition for the AMD acronym for folks that are not familiar with Asynchronous Module Definition.

    0
  38. 63

    Hi,

    Something I’ve posted on forums to not much response, but this seems like a good place for it :)

    NB: I’m coming from an MVC.Net perspective, so when I say MVC here please bear that in mind.

    Here’s my dilemma. I want all the goodness of controllers, I want strongly typed views and model binding – basically all the best bits of MVC.Net. However, even a fairly simple page will require some client side script for showinghiding elements, confirmation boxes & all that funky stuff that users expect for todays interactive web pages. You normally end up with ‘page specific script’ which will be a number of event handlers and bindings, with no real structure as such.

    The way Backbone, Knockout etc are designed almost relegates MVC.Net to a simple ‘web API’ to handle RESTful requests and respond with some JSON. You seem to end up moving logic that *I believe* should be in the ‘server side controller’ into a ‘script controller’, which I’m not really happy with (because I’m primarily a .Net developer!). Like you have mentioned, this is fine in something like GMail, where the majority of the application is on the client.

    I want: a structured script representation of my Model, that allows me to wire up all my client event handlers for my View and keeps everything in a logical order. But I still want model binding, data annotations, validation and logic in my .Net controller, everything I want handled by MVC.Net. I want the best of both in other words :)

    How I want this to work – MVC should render the view and use strongly typed model binding. A script that represents the view in some way (that I don’t have to write manually to replicate my server model) should automagically take over on the client to handle any dynamic events, allow me to manipulate the state on the client and then submit the form back to the controller using a standard POST.

    Most of the applications I’m working on at the moment are Line Of Business, but they can still have some fairly complex client side functionality. I’m not using any framework at the moment, I’m just namespacing my script and wrapping up some jQuery (i.e. Javascript modular pattern) … it works, just not sure if it’s the best way to be doing things. I’m interested how others developing in MVC are addressing this?

    Any thoughts appreciated

    0
  39. 64

    Anyway, Implementing MVC on both client and server doesn’t make sense. I will still go with full stack MVC on the server end.

    0
  40. 65

    Thanks Addy for this fantastic piece of work.
    I’m an early Dojo adopter that switched to jQuery later on. Since then I was thinking about switching back, mainly to have a proper template and MV* tools. but this article showed me that there are many tools I can use keeping jQuery and jQueryUI around.
    I added CanJS, KnockoutJS and AngularJS to my list, any suggestions?
    Thanks again.

    0
  41. 66

    What class does Mustache.js belongs to. I couldn’t find it in your comparison list.

    0
    • 67

      One thing that is very important, which I only see referenced here in passing, is the accessibility of common control types, which has a huge impact on user experience, contract procurements, marketability, and many other aspects.

      There is a Bootstrapping library available at
      http://whatsock.com/bootstrap
      That can be used to create accessible interactive components using semantic HTML markup, which may help with this.

      As an FYI, it is a misconception that ARIA will make things accessible. If the keyboard functionality of interactive components doesn’t precisely match the ARIA attributes applied to them, then these components will not work accessibly. I’ve recently seen this with GWT, and in many other places.

      0
  42. 68

    Addy, any chance that you and the “we” that is your TodoMVC team might cover Sencha? We’re using 3.4 where I am (though there are more recent versions). I’m totally new to MVC and I’m having a tough time with making anything work in Sencha.

    0
  43. 69

    Thanks in favor of sharing such a nice idea, post is pleasant, thats why i have read it entirely

    0
  44. 70

    If you desire to improve your familiarity only keep visiting this web site and be updated with the latest news posted here.

    0
  45. 71

    Hi,

    I was wondering whether could we make a large e commerce application like flipkart.com in Emberjs for frontend and having Java spring at the backend?

    0
  46. 72

    Really Nice For Getting started

    0
  47. 73

    Hi Addy

    I started my career as a Web Designer using photoshop, flash. But from last 2.5 years I diverted my career from designer to developer. I learned jquery and little bit javascript also.
    Presently working in singleton pattern only.
    I am planning to use js framework in my current project. But the same problem is that how to choose the best one.
    I am new in these frameworks, except knows only jquery. I have gone through some of them i.e. knockoutjs, emberjs. but their syntax and coding is different as I couldn’t understand. Although I am learning through e-books and youtube videos also.

    Please suggest me one which is easier to learn and implement in my current project.

    baljeet
    India

    0
  48. 74

    Hi,

    I recently developed a tiny JavaScript MVC framework based of just a few JS files. It’s features consist off easily extensible classes, autoloader and a tiny footprint.

    https://github.com/deanvaughan/Simple-Javascript-MVC

    0
  49. 75

    Manish Pithwa

    May 2, 2013 2:08 am

    Can you please post matrix of features comparison across all these above ?

    0
  50. 76

    At last i think i am now able to choose the right candy in the candy shop of js frameworks :). a big thanks to you Addy

    0
  51. 77

    David Gilbertson

    June 2, 2013 4:08 pm

    Addy, do you ever sleep? Everywhere I go you keep popping up with really useful stuff!
    Also, I find Google trends can paint a picture for beginners (that’s me) getting a feel for general interest in different frameworks, like so:
    http://www.google.com.au/trends/explore?q=ember+js%2C+backbone+js%2C+angular+js%2C+knockout+js%2C+dojo+js%2C+yui#q=ember%20js%2C%20%20backbone%20js%2C%20%20angular%20js%2C%20%20knockout%20js%2C%20%20dojo%20js&cmpt=q

    0
  52. 78

    Addy, people just love to say “Addy,” so I figured I would addy another addy daddy….

    0
  53. 79

    I have to say, when we went to write our app, we thought long and hard about what frontend framework to use. There were so many options. Many had been experimented with on the company’s various products. The write-ups weren’t helpful in choosing one. All we knew is we didn’t like what we’d seen. In the end, we decided not to use one and it has really made all the difference.

    0
  54. 80

    What about Durandal?

    0
  55. 81

    Great write up! Go Ember.js ++

    0
  56. 82

    This was insanely helpful and exactly what I was looking for. Thank you.

    0
  57. 83

    Hi !
    Thanks a lot for this article.

    A question : to create a desktop app with web technos. What do you think about using :
    HTML5
    + MV* Framework to structure : AngularJs OR EmberJs ?
    + Package the application into a native Desktop app : TideSDK or Brackets-Shell ?

    According to you, which solution is the best ?

    0
  58. 84

    Fantastic article, thank you so much for all the research and effort you applied. I am trying to wrap my head around A) JS MVC/MVP/MV* frameworks in general, and B) Ember.js / Backbone.js in particular. I am seriously indebted to you for this educational surge. Keep it up!

    0
  59. 85

    This is definitely one of the better and perhaps least biased articles I’ve read. I think a lot of developers write their own frameworks because the ones available don’t necessarily do what they want. Too complicated oddly structured want templates don’t want templates want mvc don’t want mvc only want feature x and y but not a-k etc. Of all the frameworks on the net I investigated over 30 to see if any did what I wanted and although I could have gotten away with a couple of them it would have been a bit messy or difficult. I wont say they are bad because many of them are extremely professionally made – but seem to be less generic the bulkier they get. I did like in particular RappidJS and Angular. I thought underscore and backbone were also exceptional. However I still ended up creating RapidOS (examples http://www.youtube.com/webrenovators) for the reasons I mentioned. We may create the basic todo app but their guidelines almost all exclude the way we do things even such as routing which to us will open a new window.

    0
  60. 86

    Thank you for that _awesome_ article! Really been struggelig on what framework to use, but this helped me a whole lot! :)

    0
  61. 87

    Great article, I’ve been a Web Designer for years but am now trying to delve further into Development / Javascript side of things and this provides a nice introduction.

    0
  62. 88

    I created an MVC framework “Oils JS”. It’s built on top of Express and Node JS. Please help rate and suggest areas for improvement. The link is http://mannyvergel.github.io/oils-js/

    Thank you.

    0
  63. 89

    I would like to implement views as graphics drawn on Html5 canvas. Views as html templates are useless in this case. Which framework would be more suitable?

    0

Leave a Comment

Yay! You've decided to leave a comment. That's fantastic! Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or else it will be deleted. Let's have a personal and meaningful conversation instead. Thanks for dropping by!

↑ Back to top