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
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
  • Want to use JMVC with RequireJS? Here’s an
  • Got a favorite template engine? It comes packed with 3 of
  • Want to package your app for sharing so people don’t need Steal?

    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
Controllers can listen to jQuery events, OpenAjax events, and be made to
work with any other event system. You can
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

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
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

Fast Performing

JavaScriptMVC doesn’t take any chances with performance or memory. Read

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

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
The server team is being slow, grab

More than likely, JavaScriptMVC has solved your problems (excluding
widgets). If you need help, we are extremely active on the
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

CanJS 2.2 Release

Justin Meyerposted in Development, Open Source, Uncategorized on April 5, 2015 by Justin MeyerCanJS 2.2 is out. It's awesome. This article covers the top 10 enhancements added since 2.1. Some of the improvements include Browserify and StealJS support, can-EVENT arguments, observable promises, and in-page automatically rendered templates. The article includes a lot of good JSBins to learn from too.

Getting Started with Cordova

Brian Moschelposted in Development on March 26, 2015 by Brian MoschelAt Bitovi, we’re big fans of building applications with web technologies and using build tools to target other platforms like iOS, Android, and desktop. This article will provide a quick guide to getting up and running quickly with Cordova.

Contact Us
(312) 620-0386 | contact@bitovi.com
 or cancel