Journey Through The JavaScript MVC Jungle

by selene

When writing a Web application from scratch, it’s simple to feel like we can get by simply by relying on a DOM manipulation library (like <a href="http://jquery.

com”>jQuery) plus a handful of utility plugins. The trouble with this really is that it doesn’t require much time to obtain lost inside a nested pile of jQuery callbacks and DOM elements without any real structure in position for our applications.

In short, we’re bound to spaghetti code. 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 In Other Words MV*?

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

  • Models represent the domain-specific knowledge and data in an application. Think of this as being a ‘type’ of knowledge you can model — being 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 a software (e.g your markup and templates), but don’t have to be. They should learn about the existence of Models so as to observe them, but don’t directly communicate with them.
  • Controllers handle the input (e.g clicks, user actions) in a software and Views can be considered as handling the output. When a Controller updates hawaii of a model (such as editing the caption on a Photo), it doesn’t directly tell the View. This is the one thing that the observing nature of the View and Model relationship is for.

JavaScript ‘MVC’ frameworks that might help us structure our code don’t always strictly keep to the above pattern. Some frameworks will range from the responsibility of the Controller in the View (e.g Backbone.js) whilst others add their own opinionated components to the mix while they feel this really is more effective.

For this reason we make reference to such frameworks as following the MV* pattern, that is, you’re prone to use a View plus a Model, but much more likely to get 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 a new comer to this and feel it’s a lot to take in, don’t worry. It can take a bit while to get your face around patterns, but I’ve written more in regards to the above patterns within my online book Learning JavaScript Design Patterns just in case you need further help.

When Would You Have To Have A JavaScript MV* Framework?

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

At the outset, it isn’t terribly challenging to write a software framework that offers some opinionated way to avoid spaghetti code, however to claim that it is evenly as trivial to write something of the standard of Backbone will be a grossly incorrect assumption.

There’s a lot more that switches into structuring a credit card applicatoin than tying together a DOM manipulation library, templating and routing. Mature MV* frameworks typically not only include many of the pieces you’d end up writing, but additionally include solutions to problems you’ll end up running into afterwards down the road. This can be a time-saver which you shouldn’t underestimate the worthiness of.

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

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

Good examples of applications that fall under this category are GMail and Google Docs. These applications typically download a single payload containing all of the scripts, stylesheets and markup users requirement for common tasks after which perform a lot of additional behavior in the background. It’s trivial to switch between reading a contact or document to writing one and you also don’t must ask the applying to render the entire page again at all.

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

The Challenge Of Choice: A Lot Of Options?

The JavaScript community continues to be dealing with something of your renaissance over the previous couple of years, with developers building even larger and more complex applications by using it as time goes by. The language still greatly differs from those more classic Software engineers are accustomed to using (C++, Java) as well as languages employed by Web developers (PHP, Python, .Net etc). This implies that in many cases we’re borrowing concepts of the way to structure applications from that which you have seen done in the past during these other languages.

In my talk “Digesting JavaScript MVC: Pattern Abuse or Evolution”, I brought up the purpose that there’s currently an excessive amount of choice when it comes as to the to utilize for structuring your JavaScript application. Part of this issue is fueled by how different JavaScript developers interpret what sort of scalable JavaScript application ought to be organized — MVC? MVP? MVVM? Something else? This leads to more frameworks being created having a different take on MV* each week and ultimately more noise because we’re still trying to establish the “right way” to accomplish things, if that exists at all. Many developers accept it doesn’t.

We refer for the current state of recent frameworks frequently popping up as ‘Yet Another Framework Syndrome’ (or YAFS). Whilst innovation is obviously 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 alternatives so as to pick something maintainable. In many cases, the differences between many of these frameworks can be very subtle if not hard to distinguish.

TodoMVC: A Common Application For Learning And Comparison

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

Backbone.js, Ember.js, AngularJS, Spine, CanJS … The listing of new and stable solutions continues to grow each week and developers can quickly find themselves lost in the sea of options. From minds who have had to work on complex applications that inspired these solutions (such as Yehuda Katz and Jeremy Ashkenas), you will find many strong contenders for which developers should consider using. The question is, what to utilize and how would you choose?

We understood this frustration and wanted to help developers simplify their selection process around possible. To help solve this problem, we created TodoMVC — a project that provides the same Todo application implemented in nearly all of the popular JavaScript MV* frameworks of today — consider it as speed dating for frameworks. Solutions look and have the same, possess a common feature set, and ensure it is easy for us to match the syntax and structure of numerous frameworks, so we could select the one we’re feeling probably the most comfortable with or at least, narrow down our choices.

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

In the forseeable future we wish to adopt this work even further, providing guides on how frameworks differ and recommendations for which options to take into account for particular kinds of applications you may decide to build.

Our Suggested Criteria For Selecting A Framework

Selecting a framework is needless to say about a lot more than simply comparing the Todo app implementations. This is why, once we’ve filtered down our collection of potential frameworks to just a few, it’s recommend to spend some time doing just a little due diligence. The framework we choose may have to support building non-trivial features and may find yourself being used to maintain the app for many years to come.

  • What may be the framework really capable of?
    Spend time reviewing both the origin code of the framework and official list of features to observe how well they fit with your requirements. There is likely to be projects that may need modifying or extending the underlying source and thus make certain if this could be the case, you’ve performed research around the code.
  • Has the framework been proved in production?
    i.e Have developers actually built and deployed large applications from it that are publicly accessible? Backbone includes a strong portfolio of these (SoundCloud, LinkedIn) although not all frameworks do. Ember can be used in quantity of large apps, including the consumer tools in Square. JavaScriptMVC has been accustomed 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 become inspired by exactly 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 having a large amount 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, experiencing major periods of refactoring or other breaking changes that tend being more carefully planned out whenever a framework is mature. Mature projects also tend to have more detailed documentation available, either as a section 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 perhaps the other. Opinionated frameworks lock (or suggest) you to accomplish things in a specific way (theirs). By design they are limiting, but place less emphasis on the developer being forced to figure out how things should work on their own.
  • Have you really played with all the framework?
    Write a small application without needing frameworks and then try to refactor your code with a framework to confirm whether it’s an easy task to work with or not. As much as researching and reading up on code will influence your decision, it’s equally as crucial that you write actual code using the framework to make sure you’re comfortable using the concepts it enforces.
  • Does the framework possess a comprehensive set of documentation?
    Although demo applications can be ideal for reference, you’ll almost always end up consulting the official framework docs to discover out what its API supports, how common tasks or components can be created by using it and exactly what the gotchas worth noting are. Any framework worth it’s salt should have an in depth pair of documentation which can help guide developers using it. Without this, you can find yourself heavily relying on IRC channels, groups and self-discovery, which is often fine, but tend to be overly time-consuming when compared to a great set of docs provided upfront.
  • What will be the total sized the framework, factoring in minification, gzipping and then any modular building that it supports?
    What dependencies does the framework have? Frameworks often only list the total filesize of the base library itself, but don’t list the sizes of the librarys dependencies. This often means the main difference between opting for any library that initially looks quite small, but could possibly be relatively large when it say, is dependent upon jQuery and other libraries.
  • Have you reviewed town around the framework?
    Is there an energetic community of project contributors and users who would be able to assist if you come across issues? Have enough developers been using the framework that there are existing reference applications, tutorials and perhaps even screencasts which you are able to use to find out a little more about it?

Dojo And Rise Of The JavaScript Frameworks

As many folks know, the Dojo toolkit was one of the initial efforts to supply developers a means to developing more complicated applications and a few might say it in-part inspired us to think more concerning the needs of non-trivial applications. I sat down to ask Dojos Dylan Schiemann, Kitson Kelly, and James Thomas what their thoughts were about 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 create more structured (and more non-trivial) applications?

Years ago, even though 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 because the dominant application platform, many of the innovations pioneered in The Dojo Toolkit now appear in newer toolkits. MVC only agreed to be another package that Dojo has provided for quite some time, in addition to 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 photo for enterprise grade application development. This is exactly the same focus that’s has today with MVC, it’s just another “tool within the arsenal”.

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

That is not just a challenge from a documentation purpose, in addition, it implies that there isn’t a very important factor that Dojo does. Which is good should you are building software, but very difficult when you are starting out wanting to figure out where you can start. These are all things we are already attempting to work on for Dojo 1.8, within the form of tutorials and significantly improved documentation.

Q: Why should developers still consider Dojo and what ideas do you’ve arranged for that way forward for 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 concentrates on providing an MVC model that leverages the rest of Dojo. Coupled with dojox/app, an application framework which is designed to produce it simpler 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 can be just one of many viable ways where 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 provide you with markup language to you could make 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 others of Dojo, you can draw in whatever else you might need.

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

The TodoMVC Collection

In our brand new release, Todo implementations now exist for that most widely used frameworks having a large quantity of other popular frameworks being worked on in Labs. These implementations have gone through a great deal of revision, often taking on board best practice tips and suggestions from framework authors, contributors and users from inside the community.

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

We don’t pretend that more complicated learning applications aren’t possible (they certainly are), but the simplicity of the 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 using a particular solution or group 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 JavaScript and another using primarily jQuery conventions. As you can see, whilst these applications are functionally equal to something you might write by having an MVC framework, there’s no separation of concerns as well as the code becomes harder to read and gaze after because the codebase grows.

We feel honored that over yesteryear year, some framework authors have involved us in discussions about the way to improve their solutions, helping bring our experience using 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 produce initial comparisons when you’re reviewing choices.

Frameworks: When To Utilize What?

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

I want something flexible which offers a minimalist means to fix separating concerns within my application. It should support a persistence layer and RESTful sync, models, views (with controllers), event-driven communication, templating and routing. It needs to be imperative, allowing someone to update the View when a model changes. I’d like some decisions in regards to the architecture left approximately me. Ideally, many large companies have used the treatment for build non-trivial applications. While I may be building something complex, I’d like there to be a dynamic extension community across the framework which have already tried addressing larger problems (Marionette, Chaplin, Aura, Thorax). Ideally, there may also be scaffolding tools (grunt-bbb, brunch) available for your solution. Use Backbone.js.

I want something which tries to tackle desktop-level application development for the web. It needs to be opinionated, modular, support a variation of MVC, steer clear of the have to wire everything in my application together manually, support persistence, computed properties and possess auto-updating (live) templates. It should support proper state management rather than the manual routing solution a number of other frameworks advocate being used. It must also come with extensive docs and of course, templating. It should also provide 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 also optimized for performance. It also needs to support a method to implement models, views and controllers. It may not be used on as numerous large public applications just yet, but has potential. Ideally, the perfect solution is 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 targets achieving this through custom HTML tags and components that specify your application intentions. It should support being easily testable, URL management (routing) plus a separation of concerns through a variation of MVC. It has 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 which 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 variety of widget modules (graphics, charting, grids, etc) and strong support for internationalization (i18n, l10n). It must have support for OOP, MVC and the blocks to create more complex architectures. Use Dojo.

I want something which benefits from your YUI extension infrastructure. It should support models, views and routers and allow it to be simple to write multi-view applications supporting routing, View transitions and more. Whilst larger, it is really a complete solution that includes widgets/components also since the tools necessary to create an organized application architecture. It may have scaffolding tools (yuiproject), however, 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 the way to build applications. The framework should provide bare-bones essentials like model, view, controller, events, and routing, while still being tiny. It ought to be optimized for use with CoffeeScript are available with comprehensive documentation. Use Spine.

I want something that will make it easy to build complex dynamic UIs having 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 ought to be in a position to use it with whatever framework I prefer, or even an existing app. It must also come with templating built-in and be easily extensible. Use KnockoutJS.

I want something which will help me build simple Web applications and websites. I don’t expect there to be an excellent deal of code involved and thus code organisation won’t be considerably of a concern. The solution should abstract away browser differences so I can focus around the fun stuff. It should allow me to 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 also this article, we chose 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 whatever they felt had been missing in their project of choice.

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


Pros: The mixture 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, however, you end up having a nice separation of responsibility. I found that once I have all the feaures set up, adding fairly complex features only requires a couple lines of code. Without Ember, these same features would’ve been hellish to implement.

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

The key factors:

a) Features that i want to avoid a lot of boilerplate (bindings, computer properties, view layer with all the cool handlebars).

b) the core team: I’m a Rails developer and be aware of 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 any other frameworks. Right now, we browse the code trying to find docs which isn’t ideal.

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

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

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

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


Pros: Simplicity — only 4 core components (Collection, Model, View, Router). Huge community (ecosystem) and plenty of solutions on StackOverflow. Higher order frameworks like Marionette or Vertebrae with a lot 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 great deal of research required to figure out how to create 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 using the new RequireJS shim() method in RequireJS 2.0].

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

Cons: The amount of tutorials on how to accomplish things with Backbone is inconsistent and also at different periods of Backbones lifespan. I’ve asked other devs to use a take a peek at Backbone, and so they will be writing code for v0.3. Un-aware. Whilst not really a problem Backbone can fix itself, it is obviously a major dislike associated with all the framework.

I suppose in theory, you might 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 about the framework strictly itself, may be rectified from the community through sensible hacks and approaches. For me, which is why Backbone is great, the city backing it up.

Pros: Provides just enough abstraction without unreasonable opinions — enabling you to definitely 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 for the push nature of WebSockets.

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

Cons: The undeniable fact that there’s no view bindings automagically (although you can fix this). Re-rendering the entire view each time a single property changes is wasteful.

The RESTful API has a great deal of positives, but the insufficient bulk-saving (admittedly a downside to REST itself, but still) and also the difficulty in getting different URI schemes to work on different types of operations sucks.



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

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

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

Cons: I’d like being 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 make use of a fade or slide in in a straightforward 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 possess a built-in support to such functions as drag’n’drop, however this may be added using external components available on GitHub. I’d also like to see more 3rd party components readily available for reuse. I think it’s only a few time for your ecosystem around AngularJS to get more mature then these will be available just like they have been in communities like jQuery.

Pros: It minimizes drastically the boilerplate code, permits nice code reuse through components, extends the HTML syntax in order that many complex features end up being as simple as applying a directive (attribute) within 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 simple to master), nevertheless the gain is appreciative. Documentation might be better.


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

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

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

Cons: I don’t that way there is certainly no guidance or best practice in relation to application structure. Aside from having a view model, the framework doesn’t assist you to in defining a highly structured view model. It’s very easy to find yourself using a large unmaintainable function.


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, rendering it extremely portable, and comes out-of-the-box having a ton of features which range 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 finished toolkit.
Cons: The dojo/_base/declare functionality isn’t 100% strict mode compliant where there is currently some overhead due to backwards compatibility, though this will mostly disappear inside the Dojo 2.0 release.

Pros: Good components : tabs, datagrid, formManager… Renders exactly 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).


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

Cons: I’d want to see YUI3 support a few of the auto-wiring (optional) of Ember. I think which is really the important 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 according to AMD modules and pull in certain YUI3 components and other things from other places that are also using AMD.


Pros: Has all tools included, just need to run commands and commence building. I have used for the last half a year and it’s been really good.

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


Pros: Because Maria is a pure MVC framework that’s focused on being just an MVC framework. No more with 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.


Pros: Real apps rarely fit perfectly into an MV* box, as well as the most important stuff is often outside of 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, with no framework can ever be considered a 100% solution. Rather than try to become all things, cujo.js also provides lower level tools, architectural plumbling, along with a rich plugin system that can even be accustomed to integrate and extend other MV* frameworks.

Create the architecture that best suits your application, instead of 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 using their company 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 for the untrained eye but documentation is supposed to be coming soon.


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

For rich, commercial back-office applications I think ExtJS remains the best option if this comes to JavaScript solutions (i.e. not GWT etc). For public-facing Web apps I’d rather have a thing that gives me more treatments for the markup (and ideally something which degrades gracefully).

Cons: It includes a steeper learning curve than many of one other modern structural frameworks. One can debate that if you’re buying ExtJS for that long-term this time around spent learning pays off, however I think solutions enjoy it should aim to higher minimize the time it takes to train teams up in using it.

Pros: I think a large feature of ExtJS 4 is that it throws you in to the MVC mindset and also the preferred filesystem structure right from your bat. With Dojo the initial tutorials seem to become 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 decide to go a long way without touching more HTML than what is required to bootstrap your app.

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

Cons: The licensing is considered restrictive and difficult to comprehend by some. More people could be investing in ExtJS if it absolutely was clearer what are the upfront and long-term costs of utilizing it are. This isn’t a concern by incorporating 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, want to build with HTML and JavaScript, and for me there’s great satisfaction in mucking around as well level. Even though ExtJS makes it feel like you’re not really working with HTML it still offers a fantastic deal of power, particularly if you’re utilizing it to develop 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 your PITA to test with than I’d would like. Our tester actually wound up switching to Sikuli because it was becoming too much of a battle attempting to work with it in Selenium.


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

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

Don’t Hesitate To Experiment

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

In my case: I found that Batman.js required the smallest amount of 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 convey it over towards the frameworks I do use. Or, maybe I’d simply use Batman.js in a future project if I found the city and support around it improved over time.

Regardless of whether you find yourself employing a different solution, after your day all you’ve 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 sort of application layer, communication between Views, services that perform work or anything else. Developers may thus find that they sometimes must explore beyond just MVC — you will find times once you absolutely need to adopt what they have to offer further.

We reached out to developers that happen to be taking MVC further with their own patterns or extensions for existing frameworks to obtain some insights on in places 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 to have an object that coordinated various parts of an application. Most of the time, I’ve seen developers make an effort to solve this using a Backbone construct (e.g a View), even when there isn’t really a desire for it. This is why I instead explored the need to have an Application Initializer.

I also found out that MVC didn’t really describe a approach to handle regions of the page or application. The gist of region management is always that you can define a visible area of the screen and build out the most basic layout because of it without knowing what content was going being displayed within it at runtime.

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

There’s even a TodoMVC Marionette app readily available for anyone wanting 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 certainly are a few which simply cannot. For example, a credit card applicatoin consumes a alternative party API at runtime, but just isn’t given any information regarding how a data will probably be structured.

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

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

I’ve expanded on my experiences with request driven Javascript applications and J2EE patterns for anybody who does like to find out more. ”

Dustin Boston — co-author, Aura


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 choices to be able to create a decision which brings about sustainable, maintainable code. Framework diversity fosters innovation, while a lot of similarity just creates noise.

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

Experimenting with different frameworks will even offer you different opinion of how to solve common problems which will in turn make a better programmer.

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

Comments on this entry are closed.

Previous post:

Next post: