For those who wonder how to build a Todo app in different javascript frameworks, you should definitely check out TodoMVC: http://addyosmani.github.com/todomvc/

It is a great site to check out different frameworks/approaches/philosophies. There is also an example for the todo app written in Dart using Web Components (similar to AngularJS)

https://github.com/dart-lang/web-ui/tree/master/example/todo...

I'd suggest keeping in mind that TodoMVC hides how well the different frameworks perform with more complex (nested / inter-dependent) models though.

Maybe I'm misreading it, but it looks like you might have a typo in todos-router.js. See http://ahamlett.com/Backbone.localStorage/docs/todos-router...., in the call to define() -- your dependencies are 'jquery' and 'backbone', but you take in '_' and 'Backbone'. Then, you later use '$'.

Good catch! It's fixed now. Keep the feedback coming! I'm particularly interested in design pattern suggestions.

Nice documentation! Hadn't seen docco before; pretty neat doc generator. http://jashkenas.github.com/docco/

An example of the TODOs app with AMD is great! Now if only Backbone and Underscore would support AMD natively so you wouldn't need to Shim them.

there's always the amd-version of those here -> https://github.com/amdjs

This comment has nothing to do with Backbone but we tend to use the sugar syntax for defines:

define(function(require){ var whatever = require('dependency'); });

instead of

define([ 'dependency', ], function(whatever) { });

We do this because it's way more readable for files with numerous dependencies.

Also, we make Backbone, $ and _ globals so we don't have to inject them in every single module.

> Also, we make Backbone, $ and _ globals so we don't have to inject them in every single module.

We don't; we explicitly define every dependency, always, so that it does not make any assumptions about the environment it runs in (a webpage with jquery / underscore included via script tags, for example). Second, our end-product is a single .js with Backbone and some other dependencies all combined into it. (we're not allowed to use a CDN)

That sounds like a pretty good reason not to make those globals.

We did it when we realized 100% of our modules had those three dependencies. Haven't found a drawback yet.

I like the fresh take on organizing the example but I disagree with the 2nd bullet point. Jérôme Gravel-Niquet's example encapsulates everything inside of an anonymous function and I don't see any var leakage into the global namespace.

Very nice idea. Good stuff! Should todolist.js be in a folder called Collections?

Maybe, I like to pretend it's a flask app and lump anything that models an api resource in the same folder. After all, a Collection is just an array of Models.

What do you think?

Probably should be named TodoCollection.js either way.

Yeah, I have to agree with keeping them separate and renaming it to TodoCollection.js.

As someone looking at this for the first time, even after breezing over the code that was my immediate question: wait, where was the collection again?

Yeah, I've been keeping them separate, if only to make it easier to decide what kinds of functions go where.

I think the todo app is not good enough to compare different frameworks maybe we should come up with another app , that has a least some ajax and a more complex business logic to handle.

I totally agree. The only problem is hosting the api for a new example app. I could write an example app using the github api requiring OAuth. Does anyone know of a public api that allows modifying resources without login?

CoffeeScript isn't for everyone. I've used it, and I really prefer JavaScript. While there's some nice things about it, I personally find it to be incredibly unreadable. (Sure, you can write a mix of JS and CS, but that just seems wrong.)

(That being said, I love LESS and can't imagine writing pure CSS, so I do understand how you feel.)

Same here, I've used CoffeeScript on a biggish project and found myself longing to return to JavaScript.

Maybe my mind is too low-level for CoffeeScript... I prefer seeing var and being verbose.

and fix javascript by hand ... i prefer working on my business logic.

"working on my business logic" and "preferring explicit languages" are not mutually exclusive -_-

"I don't know how to say this without sounding like a dick, so apologies in advance."

I'm curious why you did not use CoffeeScript when you updated this example?