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.

Foundations

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.

Flexibility

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:

$.Model('Recipe',{
  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();

recipesD.done(function(recipes){
  recipes[0].isTasty()
})

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

$.Model('Recipe',{
  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.

Lightweight

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!

Conclusion

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

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.

Web Application Theory

Justin Meyerposted in Development on June 27, 2014 by Justin MeyerUnderstand the technology and architecture choices Bitovi make and why we make them. What Bitovi does and why.

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