Backbone.js v0.9.10 Released

> YOU CAN DO 95% OF PRESENTATION LOGIC IN THE HTML

For us developers that have fought for years for separation between content, presentation, and logic, this is the very reason Angular/Ember/Knockout are not as popular as Backbone or other frameworks.

I've worked on a reasonably large Backbone app in production and I've written several toy apps with Angular.

I think that a lot of people dismiss Angular as yet-another-mvc-framework without ever discovering the key elements of Angular that are actually novel and worthy of study. Personally, I think that Angular is a local maximum in client-side JavaScript app development. But even if you don't agree, you should at least understand how it is different.

1) Angular prefers declarative

This doesn't mean you don't write procedural code. This means that if you want to do something proceedural, you should package it up as a Directive. Directives are where behavior and logic live. Your templates simply arrange and parameterize a tree of directives. This means that you have limited and well understood moving parts that can be tested in isolation, in combination, or in the application context. Contrast with the traditional big bag of event callbacks, which can only be tested in the application context and are more difficult to re-use in other application contexts.

2) Angular works like a game engine

Most traditional UI frameworks are a graph of intertwined callbacks. Games, however, traditionally have a pair of functions called Update and Render. The Update functions permutes the world and the Render function draws the new world. Angular works similarly, but it might not be immediately obvious. There is a "Dirty Checking" pass, where your view models, a simple hierarchy of poorly-named "scopes" are essentially diff-ed against the previous iteration. Then the Directives take over and permute the DOM to match the new view model.

Let's call the "Controller" part of the "ViewModel" and then just simplify that down to "Model". Inherently, Model and View systems are co-dependent. You have a graph like M V. Angular's system graph is less like single bi-directional edge, and more like two directed edges in a cycle. That makes little difference when viewed abstractly with the two subsystems as nodes. However, once you break M and V down into subgraphs, the traditional Model & View systems look like a spaghetti mess of bi-directional relationships. An Angular application, on the other hand, would look like less like a lattice and more like a circle.

From the changelog:

> Model validation is now only enforced by default in Model#save and no longer enforced by default upon construction or in Model#set, unless the {validate:true} option is passed.

From the documentation on Model#set:

> If the model has a validate method, it will be validated before the attributes are set, no changes will occur if the validation fails, and set will return false. Otherwise, set returns a reference to the model. You may also pass an error callback in the options, which will be invoked alongside the "error" event, should validation fail.

Is the documentation out of sync, or do I not understand the changelog correctly?

Those were added in 0.9.9, and yes -- they might be useful. If your app tends to have views and models be created and destroyed together on the same cycle, then you don't need to ever `stopListening`. Garbage collection just works as it should.

The new-ish methods are handy when your models live longer then your views do. Because this inversion tracks the listeners on the object that's listening to events, instead of the object that's emitting them, it makes it easier to unbind all of the things a view is listening to, when you want to remove just that view. To that end, `view.remove()` stops listening automatically.

Lo-Dash is a mostly-compatible rewrite of Underscore, with a fascinatingly different approach to the codebase. Instead of using little functions that are implemented in terms of each other, it relies on code generation to create (eval) explicit large and optimized versions of many of the core iteration functions at load time, in your browser:

https://github.com/bestiejs/lodash/blob/master/lodash.js#L35...

It's a very fun bit of code, and a great example of how differently a fork can be implemented while preserving more or less the same API. There's never been any tension about the project itself -- just about some of the "marketing" methods used to pitch it in the past. That said, Lo-Dash's main developer is contributing to Underscore directly as well these days, so it's all copacetic.