Backbone... I just don't get it. It seems like there's too much complexity. I'm mainly a back-end developer, so perhaps it's just me.
Later I discovered Knockout and in 2 hours, I was up and running, and it never got in the way so far.
I can only encourage people to at least try the tutorials, it will be time well spent:
> It seems like there's too much complexity
It's not really a "blackbox". It's quite easy to understand and extend too.
For instance, you can create your own custom bindings: http://knockoutjs.com/documentation/custom-bindings.html
This is about the only place where it gets low and dirty and involves you writing DOM manipulation code.
It was much more pleasurable to work with when it was no longer magical.
Then can even be used together (see, e.g., knockback.js which combines Knockout data binding with Backbone) to complement each other.
All you're really complaining about seems to be lack of data binding in Backbone. So you pick your preferred data binding mechanism and plug it in.
For data binding there's tons of alternatives that co-exists nicely with Backbone, including Knockout via Knockback, or Rivets, or any number of modules written specifically to work with Backbone - the choice of data-binding mechanism is orthogonal to the choice of using Backbone or not.
... and it was written in a horribly obnoxious manner. The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone? If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.
It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.
As stated in the disclaimer itself; because people use backbone as if it will help them manage the complexities of creating rich client side UI, when I actually think it's a terrible choice for that.
> If your issue is really as stated that people use Backbone for the wrong things and to highlight the benefits of data binding for views, then address that, instead of writing some inane comparison blasting Backbone for not providing features you the at the end admit isn't its focus.
I want to grab people's attention that they're doing it wrong. It's like when you slap someone in the face to wake them up.
> It's a bit as if I were to review your blog post as musical theatre and then at the end admit I knew all along it was actually a technical blog post but that I'd decided to slate it for lack of singing anyway.
Well, you're evaluating my article as if it was meant to be an objective non-biased review of "pros and cons". It's not. It's an opinionated piece of text that comes from personal frustrations.
Though for the record, I actually respect and admire the author of backbone, after all, he's also the author of coffee-script, which is just awesome.
The components built are FX tiles, trade and order tickets.
I've abused knockout to some rather interesting ends, but I've never attempted to use it for as an in browser MVC setup.
I think of Knockout and Backbone as fulfilling two different purposes.
Dude Backbone only works for trivial examples, and even then, and I mean, even with trivial examples, Backbone is almost useless.
I haven't yet been bitten by Knockout in any bad way.
I disagree. Backbone is a structuring framework; if you can't make it work with bigger projects, you're doing it wrong.
Angular is more of a framework than a library. You have to do everything the Angular way or things will become very difficult. In trying to learn it, I found it quite complex (beyond the basic hello world examples).
I would sell it as a framework to invent your own HTML tags, handles the communication with server and does routing, if needed. The two-way data binding is very very nice, but it feels so natural it not even is a selling point :)
- Knockout's organizational conventions appear inadequate to organizing larger projects, whereas Angular puts its module system right out front
- Yes, Angular definitely has the highest learning curve of any JS framework, but it more than makes up for it in the power, simplicity, composability, and expressiveness of the resulting app code; if it's too difficult for you, stick to something like Knockout or Backbone.
- Oh, and there's no extra hand-waving for data-binding, because Angular uses a much simpler (and in aggregate, more efficient) approach to computing DOM updates
Knockout.js is great to get started at adding interactive UI on a JSON back-end, and I think AngularJS is the natural progression.
You will still bind to events, you will still manipulate the DOM, you will still do all the manual work.
I really recommend looking at Knockout.js instead.
It really gets rid of all the DOM manipulation code that tends to become so complex and spaghetti like.
How? It provides a declarative language for two-way binding between the UI and the data.
Check out this example: http://jsfiddle.net/FEVbz/
In the HMTL pane, edit the input boxes and watch as the other DOM elements update automagically.
Notice how simple and clean the Javascript code is. All it's doing is initialization and setup. Nothing else. No event binding. No dom manipulation. No spaghetti. No nothing.
Shameless plug:
Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js
http://dev.hasenj.org/post/35572197519