New York JavaScript Meetup: A sneak preview of the Cujo.js MVC framework

My live notes from John Hann’s 25 August 2010 presentation on modern JavaScript frameworks to the New York JavaScript meetup.

Modern JavaScript frameworks rock! Dojo, jQuery, MooTools, Prototype… alleviate us from browser quirks so we can concentrate on coding awesome web sites. But none of these offer any guidance whatsoever—and hardly any tools—for building enterprise-worthy, ultra-rich web applications. It’s just too easy to create inflexible, unmaintainable spaghetti code.

A few Javascript-based, in-browser Model-View-Controller endeavors have popped up to help provide solutions. Most of these are simply rehashed server-side MVC frameworks. They just don’t get it. MVC sucks for web development. The bigger the project, the worse it gets.

Cujo.js was specifically designed to eliminate these inter-dependencies. Yes, it’s an MVC framework, but it’s different…

The above slides are from a presentation on Cujo.js, but are not the slides to this presentation.

cujo.js: A sneak preview

John Hann
lifeIMAGE, Inc.

cujo is about building ultra-rich web applications.

What is an ultra-rich web app?

  • Feature-rich
  • Single-page app (“spa”)
  • Desktop-like
  • You “live” in the app

Examples: lila Inbox, meebo, Gmail, Google Docs, Facebook

Why would anybody want to build a spa?

  • Responsiveness
  • Mobile (HTML5 apps, Phonegap)
  • Cross-platform
  • Vendor-agnostic
  • Auto-update
  • Offline
  • More responsiblity to client (more clients), less for server (fewer)

The rise of the JS libraries

  • Prototype
  • Dojo
  • jQuery
  • Mootools
  • Mochikit

Why JS libraries?

  • Browser abstraction
  • Language abstraction
  • Plugins, components, widgets

All the node-wrangling tools to build all ultra-rich applications.

However, 5,000 lines of tangled JavaScript later, what the heck happened?

It’s your nodes, dumb-ass. Stop fiddling with your nodes! Building an ultra-rich app requires software engineering.

We’re building desktop applications on the web.

Why can’t I just fiddle with my nodes?

  • Bigger app
    • More complexity
    • More code
    • More coders
  • Complicating factors:
    • Customization
    • il8n/L10n
    • Authorization
    • Animation

How to uncomplexify?

  • Modularization: “Think tiny”
  • Encapsulation: Don’t touch my coadz
  • Loose coupling: I won’t touch your coadz
  • Reuse: Don’t repeat yourself
  • Separation of labor: Mind your own biz

Does $() help?

It doesn’t

3rd-party solutions help Dojo and YUI do more than jQuery, but not enough.

Don’t believe me?

Does $().fn help modularize my CSS?
Does dojo.connect() protect my code?
Does $().live respect my widget’s personal space?
Does $.extend help me reuse HTML?
Does $.animate coordinate nicely with my CSS designer’s CSS files?

Animation is not behavior—belongs with designer (CSS3 transitions)

Cujo is built on Dojo.

Dojo MVC?

models, views, controllers…

Why is cujo.js moar?

Data flows magically between nodes & server.
Template languages disappear (and so does the ID attribute!)
Views invoke the …

Dojo 1.6 data stores are hawt!

Data stores are data models. Most handle client-server communication so you don’t:

  • json
  • json-rest
  • couchdb
  • flickr
  • google
  • csv
  • xml
  • atom
  • etc

Data binding provides the “last mile.” (Dojo 1.6 will provide data binding). The end result: “live” data. As live as you want it, anyway.

What template language?

Why use a {{template language}}? HTML5 data-* attrs FTW!

inheritance: data-cujo-override
loop*: data-cujo-iter
conditional*: data-cujo-if

“oohtml,” anyone?

The “holey” web trinity

oojs + oohtml + oocss => cujo.mvc. View complete module, yet still overridable.
my/HawtWidget.js (aka “view-controller”):

Ancient browsers grok CSS2.1 & CSS3

Once you take control of the stylesheets, the sky is the limit.

Ever wish this worked in IE6?

  • Two selectors (chained) on an element: .myWidget.selected
  • child selectors
  • Transitions

Moar modularization

JS, CSS and HTML as a single unit is easier to create, test, maintain and extend.

dojo.declare('mgp.view.Logo', cujo.mvc.View, {…

Moar encapsulation

Self-contained, “black boxes”

Minimize cross-dependencies.
cujo.js mixins FTW!
cujo._Connectable limits dojo.connect()
cujo._Settable limits dijit’s set()

Moar loose coupling

It’s good to be loose and ignorant of your own parents! Cujo emphasizes:

  • doj.connect
  • dojo.publish/dojo.subscribe

Moar reuse

Just say no to copy-and-past coding practices.
Increase maintenance
cujo.js embraces OOJS and OOCSS.
OOHTML enables OOCSS (automatically applies inherited classes)

Jon Hann gives a strong endorsement of OOCSS. Learn it

Moar separation of labor

$.css() and $.animate are the CSS designer’s job. Layout is also the CSS designer’s job.

Get over it.

Moar about view state

Classical OO inheritance: Descendant classes inherit attributes and behavior.

Pure prototypal inheritance: Descendant objects inherit attributes and behavior.

OOCSS: Descendant objects inherit attributes and run-time state.

When can I haz Cujo.js?

Cujo.js is in stealth mode while we test moar browsers, finish features, document and clean-up code. Release 0.1 on Github around 15 September 2010


Q: Some people think these frameworks proscribe too much.

A:Possibly went too far the other way. Can define and extend. Theming. Don’t want to use the templating language, can pull in your own.

Q: What is the performance overhead?

A: Two aspects: load-time. Actually processing CSS at load-time. Do a lot of feature detection, not browser-sniffing, so difficult to do that build time.

Q: You mentioned how Facebook was different in the beginning?

A: FB only loads 3KB of JS and that 3BK is responsible for loading and running the rest.

Leave a Reply