I got the early release of this book on Oreily Safari and I have a rather low opinion of this book. I was developing a Backbone.js app wanted to use this book to provide insights but this book was surprisingly completely unhelpful. I was ( and I guess I still am )struggling with rendering components , item views and list views and managing events/models and struggling with router etc. I am not the only programmer with these issues; there are plenty of non-trivial question about backbone.js on Stackoverflow. This book has little to help one understand the internals of backbone.js or how and where to apply underscore.js . For some reason this book veers off into node.js development as if every one using backbone.js is going to wrote a node.js back-end server app. Thankfully enough, there are several outstanding tutorials on the web on backbone.js and the underscore.js libraries as very well documented and the demo app is also very illustrative. I purchased this book on OReilly Safari to support the authors but the book is a complete disappointment.
I can't offer much help with many of the other issues you mentioned but if you really want to understand the internals of backbone better I don't think there's really a better path than reading the annotated source [0]. One of backbone's strengths is that it is so minimal, and the source so compact.
I love Coffeescript/Underscore/Backbone and have made many applications with them. But for large sites with lots of nested views, I prefer Coffeescript/Less + Emberjs + Handlebars + Bootstrap.
Check out recipes with backbone. I was in a similar place(past to do apps, but not ready for anything substantial) and I found it to be a great help. Truth be told, there is not a lot of good literature on intermediate backbone development and I think that's really hampering its adoption.
- I like how he shows integration with a couple of different backends (Sinatra & Node). Makes it more practical and 'real world' than just 'assume we have this bit of JSON to work with'.
- As other people have mentioned, the build process as a whole is becoming important with frontend MV*
- Check out Marionette to ease the boring bits of Backbone. There's a chapter on it in Osmani's book now; not sure if it was there when you read it.
- The book is still not set to be released for another 6 months; Osmani's JS Design Patterns book was fantastic so I'm sure this will be great too.
I agree it's important for book about client dev to be backend agnostic , and too many books on js clientside frameworks contains unnecessary parts about server side development with nodeJS.
However, nodeJS makes it easy to quickly build a thin backend for the purpose of making the frontend work quickly, furthermore , nodeJS is becoming a tool that is really necessary in frontend development , you often need a buildstep before deploying code on the server ( minif , concat , ... ) , so a little chapiter on node makes sense in my opinion ;)
nodeJS is becoming a tool that is really necessary in
frontend development you often need a buildstep before
deploying code on the server ( minif , concat , ... )
Certainly there are minifiers like Uglify that are Node.js packages, but I wouldn't go so far as to claim that Node.js is now "necessary" for frontend development. I'd bet an awful lot that YUI Compressor, Google Closure Compiler, even things like jsmin.c are being used much more than similar Node.js-based tools.
I bet people doing some javascript aint going to install java just to minify their script, nor ant to manage tasks , nor maven to fetch packages when you get everything with node+npm. If you do testing , and you should , you need node to run tests.
I tried Backbone and am now looking at Angular... but part of me is starting to think "is this such a good idea?". All the authentication stuff, and validation, and so on has to be done server side anyway, and perhaps replicated in the JS framework. Also, keeping models in sync looks like it might be easy to screw up.
The paradox is that the more dynamic and "app-like" you want your site to feel, the more javascript you need, and eventually you need a better way to organize it than the jQuery spaghetti code you typically end up with, which inevitably leads you to a javascript framework like Backbone or Angular. It's not necessarily a good idea or a bad idea, it's just a problem that needs to be solved.
It is also, by the way, the same problem native app developers have to solve when they create an app that relies on a web server for its data. They must make sure their models are in sync and that authentication and validation happens on the client or is at least represented consistently.
If it still doesn't feel right to have a thick javascript application on the client, though, you might want to do a little research into how 37 Signals wrote Basecamp two. They did it without relying on a thick javascript client framework and instead pass up all the JS/HTML necessary on each request and use HTML5 pushstates to keep the app dynamic and snappy.
As a related note, I highly, highly recommend Angular.js. Aside from all the awesome two-way bindings stuff (which you get with a lot of other frameworks), the big selling point for me was the fact that dependency injection is baked in at every level and the emphasis on writing testable code that doesn't rely on DOM manipulation.
I suggest you try it out, I think your lines of code will greatly decrease. The biggest reason I prefer to program in Angular over Backbone is that I simply don't have to write rendering logic code because of data-binding. There's no "render" function, no jQuery DOM manipulation for common tasks, because all rendering behavior is declared in the HTML. Unless you're doing something non-trivial, in which case you should write a custom directive. (For those unfamiliar with Angular, a directive is a declaration of a new HTML tag or attribute with custom behavior which can be reused throughout your app)
I've got to admit that I've never worked on a substantial Backbone app, but many of the issues I see people having with Backbone (regarding rendering item and list views, programmatically binding events, etc..) are simply non-existent in Angular.
We investigated using Backbone vs. Angular for a project and went with Angular and could not be happier. It's not just the two-way data binding, which you can get with frameworks like Knockout.js and Ember.js; it's the dependency injection and testability of the code. Never before have we had this good of test coverage in a pure javascript app, and most of it is unit tests which is very impressive considering how concerned javascript usually is with manipulating the DOM.
You don't necessarily have to replicate validation on the client side. You have just have server form responses / validation errors come through AJAX responses and display them client side.
Client side stuffs like validation,etc ... are here only to enhance user experience , you dont want a user to wait til the page reload just to know the password he entered should be at least 6 characters long. Same thing for auth , permissions to access resources are set server-side, and dealt on the client with HTTP response codes. So there is nothing to keep in sync,The server is still free to forbid any resource access, or invalidate granted access.
Sorry, I didn't mean to imply that the auth stuff needed to be kept in sync, I meant models. People are used to pushing a button and getting a GO / NO GO response of some kind, whereas it seems that with some of these frameworks, people could edit something and have that not show up, if something went wonky in the middle: it's saved "locally", but the ajax request hasn't been completed yet.
Great work! The only thing is that this needs to get updated based on the changes of the new 0.9.9 release. Specifically you do not need to create a custom dispose function, remove now will remove listeners bound to the view.
Anybody wants to look to another one (not launched, still a beta version, but created with large projects in mind, speed of development and long time maintenance in mind): https://github.com/salboaie/shape ?
Yes, but what I was looking was a very different beast: Bindings with properties chains, declarative style when possible, typed models with auto-computed expressions, reusable components (controllers/presenters), separation of views from controllers (as little code as possible in views - in shape we have only html with bindings).
Our background was Flex with a MVVM framework we created. We tried to replicate it in HTML5 .
I'd always assumed that the product you'd build with one of these frameworks would live behind some sort of authentication such that SEO wouldn't really be an issue because the bots wouldn't see it. Your marketing site would be driven by a separate CMS.
I was working on a project that would have benefitted greatly from being single page, but the SEO requirement kept us away from it. (Going the phantom.js route seems wrong and icky, though Meteor is going that route so my tastes may be wrong.)
There are enough places where things can be handled with jQuery, but it's not nearly as elegant. The question wasn't if we were a single page application, but rather that we had enough in-page interaction that using jQuery was unwieldy. I have ideas that are coalescing on how to handle the in-between stage, but I'm not quite there yet.
What about situations where you need to be SEO friendly, but you have enough in-page interaction and reused components that mere jQuery starts to become unwieldy?
Nothing prevents you from using backbone in static pages. Also, Google's spiders can crawl javascript-heavy apps [1], but I'm not sure that's a future-proof approach. If your interactive content is that important for SEO, it should already be in the HTML, with the interaction layer on top.
This book has been a big help while learning backbone. It would be helpful to add some details around how ajax requests created by the framework. It was nice when I realized I could use models as ajax request making utilities.
peepcode and nettuts+ videos on backbone are great too. This book is definetly interesting and worth buying for beginner that want non trivial exemples and advices on how to work with client apps in general.
