

Building a single page app with Backbone.js, underscore.js and jQuery - ericflo
http://andyet.net/blog/2010/oct/29/building-a-single-page-app-with-backbonejs-undersc/

======
jashkenas
Nice article! I think it hits a lot of the philosophy behind rich JS Apps.
Taking some key points from it:

* _Do not_ store state in the DOM. You'll live to regret it when you need to represent the same model in more than one place at once, or refactor your UI.

* Events are the way to go, when connecting changes in the model to updates in the view. Ideally, models know nothing about what UI happens to be on the screen at any given moment.

* If you're going to be doing interesting business logic in the client, it helps to have collections (in this case, Backbone.Collection) with a richer API than JS arrays: filter, any, map, reduce, reject, include, invoke...

* Lots of little testable JS files for development, one minified gzipped file for production.

The one point I'm in disagreement with is: "Keep your models as simple as
possible". In my opinion, client-side models really shine when they contain a
large part of your important JS business logic, and you can use the same
models in different situations to provide access-control, URL generation, data
munging, etc.

For example, here's a list of some of the methods we have on a Backbone.Model
called "Document": viewerUrl, publishedUrl, canonicalId, openViewer, openText,
openPdf, allowedToEdit(account), checkAllowedToEdit(account, message),
checkBusy, notes, uniqueEntities, isPending, isPublic, isPublished.

~~~
simonw
I can understand why storing state on the DOM would quickly start to suck if
you're building a single-page application, but I've found it works really well
for applications that work without JavaScript using progressive enhancement.

~~~
HenrikJoreteg
True, what I'm talking about in my post is definitely a different paradigm
than a more traditional web site where one of the goals is to make it widely
accessible for any and all users/devices.

ps. thanks for reading my post simon, u da man!

------
marstall
hi, i've been experimenting a bunch with different approaches to doing MVC in
Javascript. I did one project where I completely rolled my own rails-like
framework, with a base controller, base model & view functionality based on
EJS (my favorite js templating library).

Then I discovered sammy.js, which provides a nice approach to routing and
linking. my current project uses that, and i roll my own data access code &
use EJS for templating. I also have written all my own glue.

The space is calling out for a "Javascript on Rails" that takes a variety of
different libraries and combines them in a canonical way so that each new
project doesn't have to go through a shopping expedition, deciding which
libraries are currently the best.

What's needed, basically:

1\. Routing, navigation + back-button. Single-page JS apps operate very
differently from normal apps because many links are hash links, eg. #settings.
Sammy.js handles this nicely.

2\. models. Here I have a different definition of what a model is than
Backbone. I see a model as a class that wraps a particular service. So you
might have a TwitterModel, YouTubeModel, MyServiceModel, etc. They would all
benefit from inheriting from a base class that does the necessary networking
(JSONP, JSON, etc.). It would be nice if all data came back from the service
in the form of a Backbone.js Collection.

3\. Views. There is a lot of code that ends up being needed around rendering
templates. Think of the variety of different render() functions that exist in
rails. That translates to Javascript, in my experience. Rendering templates
into a div, doing pre- and post- processing, even swapping rendered blocks
into invisible divs so they can be swapped back in quickly when the user hits
the back button.

I could go on about the neat things that could/should be done, including all
the declarative programming and "convention over configuration" stuff that
rails does (example: render_foo() loads template foo.ejs and renders it into
<div id='foo'>)

Anyway I feel myself a bit lost in a sea of googling whenever I try to find
the definitive projects in this space - so I hope some will comment with their
fave MVC-esque projects for Javascript...

~~~
HenrikJoreteg
Sammy.js does look quite cool. I've poked around the documentation, but
haven't built anything with it yet.

I see what you're saying about "Javascript on Rails" but to me that's quite
different than something like backbone. What you're talking about is more
about "ajaxifying" a traditional browse-from-page-to-page experience. I
definitely think there's value in that for improving the feel and
responsiveness of a site. However, I'm more interested in truly emulating the
desktop app experience where, once you log in there is no concept of browsing
from page to page or "going back".

~~~
brianjesse
Have you seen Qooxdoo? I've made some very desktop-like apps with it
<http://demo.qooxdoo.org/current/showcase/#form>

------
ryandotsmith
"Also, since JavaScript has no formal classes there is no self-evident
approach for structuring an entire application."

Really? <http://javascript.crockford.com/prototypal.html>

~~~
jashkenas
Please don't just quote Crockford as gospel truth.

Crockford's prototypal revelation is only a slight alteration of the standard
constructor pattern, and not a particularly useful one. You still have a class
(the object that serves as a prototype for every instance you create), it
doesn't add any particular flexibility, and it's quite slow. I encourage you
to run the tests yourself:

[http://jsperf.com/object-create-vs-crockford-vs-jorge-vs-
con...](http://jsperf.com/object-create-vs-crockford-vs-jorge-vs-
constructor/9)

For me, that test clocks using Crockford's pattern to instantiate objects as
80% slower in Safari and Firefox, and 95% slower in Chrome, when compared to a
standard use of JS prototypes.

------
mrchess
Was there a demo for this app you built? i couldn't find a link

