Hacker News Reader

Hacker News

Comment by hasenj | Hacker News Reader

Full thread

hasenj

Backbone.js is not going to solve your DOM spaghetti problems.

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

View on HN

I've taken a look at both Backbone and Knockout over the past week or so, and I definitely prefer the Knockout approach.

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.

Like you, I'm more a back-end developer and attempted to pick Backbone initially for my SaaS, but I wasn't very successful with it.

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:

http://learn.knockoutjs.com/

  > It seems like there's too much complexity

Backbone helps you to do the things you understand. Knockout let's you do things you don't necessarily understand. Sometimes black-box approach is OK. Sometimes not.

Knockout, while it seems magical at first, is actually not so hard to reason about.

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.

I'm not familiar with Knockout, but it sounds like my experience when we were getting into the Flex framework at work a couple of years ago. We thought the data binding was so magical, but once I started to work with it, I had a very good mental model of how the MXML/ActionScript compilers were doing their magic.

It was much more pleasurable to work with when it was no longer magical.

I'm not familiar with either framework, but at least I can understand the intent (if not mechanics) behind Knockout code. With Backbone, it's like reading a whole different language.

Apples and oranges. They address different areas, and so you'll combine them with different other code to fill in the gaps.

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.

In theory they are different, but in reality people use backbone because they think it will help them reduce the bloat and mess in their code, when in fact backbone will not help with that.

Really? My experience is that it does. So is the experience of many others. Data binding was far down the list of issues I've needed to fix in the places where I've experimented with Backbone.

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.

Would be interested to hear more about what you mean here?

> Here's an article I wrote about why I think Knockout.js is so much better than Backbone.js

... 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.

> The disclaimer clearly shows you realize they have different purposes. So why the antagonistic tone?

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.

For anyone tempted: keep in mind, how trivial this example is. When time comes to nontrivial things knockout will bite and bite you hard.

while this is an interesting reply, it could be way more interesting if it contained a "because ...." subsentence, could you expand on this?

As opposed to Backbone, which doesn't bite you hard?

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.

"Dude Backbone only works for trivial examples, and even then, and I mean, even with trivial examples, Backbone is almost useless."

I disagree. Backbone is a structuring framework; if you can't make it work with bigger projects, you're doing it wrong.

what do you mean by non-trivial?

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.

We build online trading applications with KO (we use it only for the view, we have our own Presentation Model were we have observers which pretend to be KO observables) and we have found it quite helpful.

The components built are FX tiles, trade and order tickets.

How would you say Knockout compares to AngularJS? I've looked at both and Angular seems really really clean as well.

I'm looking at AngularJS to handle some more advanced cases; my understanding is that AngularJS provides roughly what Knockout.js provides, then more features around (but please note I didn't dive very far yet in AngularJS!).

Knockout.js is great to get started at adding interactive UI on a JSON back-end, and I think AngularJS is the natural progression.

As I said here: http://news.ycombinator.com/item?id=4792638

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).

Only recently i started with AngularJS. Ik took me a few days to understand it and then a week or two to get addicted to it. At first the terminology might scare you off: directives, controllers, watches, promises, services and more. But now it really makes sense to me and i love it.

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 :)

Corollaries:

- 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

I have yet to see a single viable example of a Knockout app that's been progressively enhanced. Until then, I'm not even going to consider touching it.

Knockout is horrible because you end up putting the "messy jquery code" in the html ! While there is no auto-binding in backbone, it is not really an issue in large apps. Furthermore , knockout doesnt have a persistence layer.

You don't put "code" in the html.

Knockout's declarative language is not messy; just verbose.

Reply on news.ycombinator.com