Having your Cake and Eating it without Getting Fat

by Justin Meyer

Having your Cake and Eating it without Getting Fat

Justin Meyer On stack overflow, someone asked what are the pros and cons of using JavaScriptMVC. Believe it or not, there no cons for using JavaScriptMVC.

posted in Development on May 4, 2011 by Justin Meyer

On stack overflow, someone asked what are the pros and cons of using JavaScriptMVC. Believe it or not, there no cons for using JavaScriptMVC.

But wait. “How can that be?” you ask. Certainly, everything has cons. Even ice cream makes you fat. Well … you are wrong.

Actually I lied. JavaScriptMVC actually has just one drawback. It’s “sorta” dependent on jQuery. You can use its testing, dependency management, and documentation engine with out the ubiquitous $. But if you want it’s MVC goodness, DOM extensions, and special events, you must use jQuery.

But, I’ll make the assumption that’s not a big drawback to most people exploring JavaScriptMVC and explain why JavaScriptMVC is chockablock full of WIN.


At my roots, I’m a hard core enginerd. I don’t believe in compromises. I think it’s possible to have a flexible, lightweight, fast-performing framework, that scales like spiderman. I think JavaScriptMVC almost perfectly strikes that balance.


JavaScriptMVC is actually the MOST flexible framework that I know. You can use every part without every other part.

  • You just want controller? Download standalone.
  • Want to use JMVC with RequireJS? Here’s an example.
  • Got a favorite template engine? It comes packed with 3 of them.
  • Want to package your app for sharing so people don’t need Steal? Run:

    js steal\pluginify app

It’s hards to find cons in a framework that lets you use just the parts you want. If you find something better, use it instead and let us know about it. We do the same thing! It’s why we switched from Prototype to jQuery and a 1000 other changes.

Besides using just what you need, JMVC’s components are also very flexible. Lets use jQuery.Model as an example. The easiest way to create a model that connects to a JSON REST service is like:

  findAll: "/recipes",
  create:  "/recipes",
  update:  "/recipes/{id}",
  destroy: "/recipes/{id}"
  // a helper method
  isTasty: function(){
    return /mushroom/.test( this.title );

This allows you to do something like:

Recipe.findAll({}, function(recipes){
  recipes[0].isTasty() //-> boolean

And now models support $.Deferreds allowing:

var recipesD = Recipe.findAll();


But what if your service is … God forbid … XML? JavaScriptMVC is flexible enough to connect to any service layer:

  findAll: function(params, success, error){
    return $.ajax({
       url: "/recipes.xml",
       dataType : "xml json recipe.models"

Here’s an example of a Model that uses localStorage. Controllers can listen to jQuery events, OpenAjax events, and be made to work with any other event system. You can register any template engine to work with $.View and Steal’s build system.

It’s damn hard to find cons in a framework that has sane defaults that can be abandoned if necessary.


At the always awesome JSConf, John Hann, angry at frameworks, made the case for modules instead of frameworks and libraries. He’s upset that trying to use a single part of a framework brings in too much unused code. This even made it to readwriteweb.

Mr. Hann should love JavaScriptMVC as there is almost none of this. JavaScriptMVC has no ‘Core’. Each component loads only what it needs. For example, unlike jQuery UI, JMVC’s default drag does not have the ability to limit it’s area, to move in steps, or to scroll an area that it hovers over. In JMVC, those are plugins. No waste!

Fast Performing

JavaScriptMVC doesn’t take any chances with performance or memory. Read this article why JMVC renders as fast as possible.

JavaScriptMVC is also the easiest way of avoiding memory leaks. This is a whole ‘nother article that needs to be written. But take my word for it, if you use JavaScriptMVC in the default way, with controllers doing the binding, it is almost impossible to create leaks. And if you aren’t using $.Controller, you are almost certainly leaking memory. This article shows a short example. But it doesn’t touch on how JavaScriptMVC can automatically clean your model instances when they are no longer being used. This is a HUGE problem for long-lived apps that load 1000s of records. JMVC does not have this problem. Do you?

Because of its flexibility, if your app is small, you can use just a few parts of JavaScriptMVC. However, if it turns into an unruly monster, it’s got your back. Everyone writing jQuery should be using $.Controller. But if you need testing, pull in FuncUnit. If you need dependency management, use steal. If you need performance, use $.curStyles. The server team is being slow, grab $.fixture.

More than likely, JavaScriptMVC has solved your problems (excluding widgets). If you need help, we are extremely active on the forums. If you need even more help, you can hire us!


Despite an ugly name and (until recently) website, at its foundations, JavaScriptMVC is almost an ideal framework for jQuery. You can use just what you want without any penalty. What could be better?

blog comments powered by Disqus

Module Loaders: Master the Pipeline!

Ilya Fadeevposted in Development, StealJS on June 30, 2016 by Ilya FadeevThis article is for developers who want to dig into JavaScript Module Loaders. We will look at how module loaders work, what the stages of the pipeline are, and how they could be customized.