Maybe it’s because I was so overwhelmed by the dozen files that made the previous combination tick, but I was ready to kiss CanJS when I saw the directory tree contained a grand total of four files. Yes, I know, four large files are not better than a dozen small ones, but it seemed that an application as simple as this Todo list shouldn’t need such granularity.
The CanJS homepage is a hoot. You can go to the download button, and instead of just sending a giant file your way, it asks you what kind of templates you’d like and what modules you’d like to include. Then it gives you the option to minify the download. So you get exactly what you’d use in production.
The self-description of the framework is as follows:
Frankly not very exciting, but that’s par for the course so far. The index.html is polluted, as was to be expected, by Handlebars directives – but you don’t need those, you can use something else. The app.js (the main entry point) simply sets up the routes. There is a model file, todo.js, that handles both the item and the list (which is a static member of the item).
Most of the functionality is encapsulated in the components file, todo-app.js. Its functions are mapped to the template/index.html by magic attributes, prefixed by “can.”
The CanJS page on “Why CanJS?” lists all the usual obviousness. It’s Flexible! It’s Safe! It’s Fast! It’s Easy! Sadly, it’s hard to verify any of it based on the assertions made.
What can be said that the one example we are looking at, the Todo sample app, is fairly easy to follow and, indeed, performs very well. In particular, it’s not just fast (as advertised), it’s also one of the examples with the smallest code base. Overall, a winner.