Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Technical review from Jeremy Ashkenas #342
(minus some general book/market comments)
The first intro sentence: "How do you write an organized, maintainable
"work your way through the internals, practicals" ... it looks like there's
"The challenge with this approach is that it doesn’t take long to get lost in a
What is MVC?
Nice explanation, but it would be worth hitting home that the entire central
When Do I Need A JS MVC Framework?
"GMail and Google Docs" ... non-Google examples would be welcome in this
Why Consider Backbone.js
This series of sections is getting a little bit sales pitch-y. I'd try to find
The "Does the following describe you?" graf is very jargon-heavy -- which would
"It should be imperative, allowing Views to update themselves when Models
MVC Applied to the Web
This section could use a bit of love. At the moment, it probably confuses the
That said, an explanation of how traditional (read, Rails) server-side MVC
MVC In the Browser
This is a strange section that doesn't really explain what it's trying to say,
Client-Side MVC - Backbone Style
I'd avoid using the
"Instead, the Controller responsibility is addressed within the View." If you're
"A Model may also have single or multiple Views observing it." It's not explained
For Collections, it's also worth mentioning that they're useful for performing
You mention Handlebars and Mustache, then immediately say
Re: the "Controllers" mini-section ... I think you've already covered this up
What does MVC give us?
"To summarize, the separation of concerns in MVC facilitates modularization
"Doesn’t support deeply nested Models, though there are Backbone plugins
Backbone Basics / Models
"Model.set() allows us to pass attributes into an instance of our model" too
Re: Validation -- make sure that this section is up to date with the latest
"The events attribute" section could use a bit more meat. It's pretty core to
TodosCollection is an awkward name for it. Perhaps just call it
"Note that using Collection.reset() doesn’t fire any add or remove events.
"The complete list of what Underscore can do is beyond the scope of this book,
When first discussing events, it's worth mentioning what they are -- a basic
"since removing a View without unbinding its handlers can result in memory
"In Backbone, routers help manage application state and connect URLs to
"As of Backbone 0.5+, it’s possible to opt-in for HTML5 pushState support" These
"It is also possible for Router.navigate() to trigger the route as well
At this stage in the game, it's a little unfortunate that this book uses the
The repetition of large blocks of the same source code is a bit strange.
Exercise 2: Book Library - Your first RESTful Backbone.js app
Ahh, a non-Todo example. Lovely!
Nice work walking through the basic connection over to Node and Mongo. Folks
Maybe use an Underscore function or two to simplify repetitive stuff like this?
"we will use the dateFormat jQuery plugin" Might be worth just using a couple
"Another, simpler way of making Backbone recognize _id as its unique identifier
Backbone Boilerplate And Grunt-BBB
Just my opinion, but I'd strongly recommend removing this section. I think that
I wouldn't start by showing
"Backbone.js doesn’t implicitly handle relations or nesting, meaning it’s up to
"One approach is to make sure each child model has a parent attribute" ...
Is it possible to have one Backbone.js View trigger updates in other Views?
Instead of starting with a mediator, start with just having the one view reach
How would one render a Parent View from one of its Children?
Also a bit strange advice. The simplest thing to start with would just be:
... only use events when an actual inversion of control is desired (which it may
How do you cleanly dispose Views to avoid memory leaks?
The example BaseView is a pretty bad idea. Having a view keep an array of
What’s the best way to combine or append Views to each other?
The best way to combine or append Views together certainly shouldn't start with
... just plain jQuery.
Better Model Property Validation
The best way to do this probably isn't to stick validation in your model
"If this sounds familiar, it’s because extend is an Underscore.js utility,
I'm not going to have many opinions on these, but perhaps a few...
You can probably remove the "Memory Management" section in Marionette, now that
"It’s an AMD-compatible version of the Underscore templating system that also
It's a little strange to have the simple
Looks like the section on Thorax got mis-copy-pasted to the bottom as well.
Deserves a little more time and love. I'd expand the conclusion by a page or two,
@dcmaf I'm trying to decide what we should do about the section discussing the Front Controller pattern in MVC applied to the web. With the updates to mention Rails MVC in place, should we:
(a) Keep the Front Controller section as is - did you find it helpful?
The style of the following vids, I really appreciate to explain the M* patterns,
I just read back through the Fundamentals chapter and I think the Front Controller section looks okay. To me, coming to client-side SPA development from a server MVC background (Java/Spring MVC in my case), this is easier to follow than the Ruby on Rails example.
I think the Ruby on Rails discussion could use a diagram similar to that in the Front Controller section. The Backbone sections (Client-Side MVC & Single Page Apps, Client-Side MVC - Backbone Style, or Implementation Specifics) could use a analogous diagram showing how client-side MVC works. I think something along those lines would help with contrasting client-side MVC with server-side MVC, which seems to be the intent of this section.
@addyosmani It doesn't look like this change regarding Router.navigate() was incorporated:
I find the updated solution to Better Model Property Validation (based on Jeremy's suggestion) to be confusing. It seems to be saying that the best solution is to not use the built-in Model validation support and to write an external validator instead. It then goes on to present a solution using the internal validate() function.
It might also be worthwhile to stick in a mention of the Backbone.Validation plugin and its preValidate method. I was using an approach along the lines of what is presented in this section and found using preValidate very helpful.
I've finished reviewing the updates related to Jeremy's review. The new expanded conclusion looks good.
One thing I've noted is that the book consistently advocates using Backbone vs. a roll-your-own solution, but does not directly contrast it against other MV* solutions such as Angular and Knockout (although there are allusions along the lines of how it is minimal, etc.). It might be helpful (perhaps at the end of the fundamentals chapter) to discuss the framework approaches taken by other MV* implementations and how Backbone fits into the overall MV* landscape.
@dcmaf Thanks for the feedback. I've added a note about Router.navigate and a few paragraphs on the validation plugin. To try making sense of the better model validation section, I've given the two plugins we discuss their own headers and moved Jeremy's advice to its own header as the final point in the section. That (I think) allows it to be presented as an alternative, rather than contradicting with the rest of the advice in the section.
Does it make more sense in it's current form?