Developing Backbone.js Applications(addyosmani.github.com)
addyosmani.github.com
Developing Backbone.js Applications
http://addyosmani.github.com/backbone-fundamentals/
43 comments
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.
0. http://backbonejs.org/docs/backbone.html
0. http://backbonejs.org/docs/backbone.html
I wrote Backbone.js tutorials using HN search API. I hope my posts help you.
http://smagch.github.com/posts/2012-11-20-model-is-stateful....
http://smagch.github.com/posts/2012-12-10-assemble-modules-b...
http://smagch.github.com/posts/2012-11-20-model-is-stateful....
http://smagch.github.com/posts/2012-12-10-assemble-modules-b...
If you are working on a non-trivial application and it's not too late to switch, may I suggest: http://emberjs.com/guides/router_primer/
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.
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.
Is CoffeeScript necessary with Ember?
Not at all. As a Coffeescript dev it's actually taking some effort to learn Ember with Coffeescript as all the guides and docs are for JS.
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.
Erik, links please!
Also, have you published that Backbone tutorial you were working on yet?
Also, have you published that Backbone tutorial you were working on yet?
Where's the good literature on advanced backbone development?
Partially agree. A couple of points:
- 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 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.
Mind posting links to those several outstanding tutorials on the web?
Try AngularJS :)
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 ;)
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 , ... )
yui compressor is deprecated
By who? Genuinely curious.
Ah, found it myself: http://www.yuiblog.com/blog/2012/10/16/state-of-yui-compress...
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.
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.
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.
If the request fails a failure notification should be shown, and a rollback to the client model will/can be made.
Wow. Surprised this hadn't been posted yet. I've been sharing this with people for a while now and I just assumed it had already been submitted.
Chaplin (despite being CoffeeScript) is also a good framework to check out since it demonstrates several good practices for large Backbone.js apps
Chaplin (despite being CoffeeScript) is also a good framework to check out since it demonstrates several good practices for large Backbone.js apps
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 ?
I will greatly appreciate your feedback.
I will greatly appreciate your feedback.
I would love to hear if you tried Backbone before your build your framework. If so, what are your reasons for making it.
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 .
Is the jury out on best practices for SEO when using frameworks like Backbone.js to build "one page" sites?
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.
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.
definetly, an user admin or a L.O.B app dont need to be SEO friendly , if you want SEO and you are doing single page app f you are doing it wrong.
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.
[1] https://developers.google.com/webmasters/ajax-crawling/docs/...
[1] https://developers.google.com/webmasters/ajax-crawling/docs/...
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.
That guy is my web dev hero.
I found this to be a good reference when I was looking for something a bit more in-depth than the typical Todo examples.
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.