Hacker News Reader

Comment by Tichy | Hacker News Reader

I haven't looked into it in detail, but I am interested in an opinion. Could Backbone.js possibly be overkill? I think on the server side that kind of framework evolved to deal with server side specific issues. Should it just be ported back to the client?

I have only started to develop something with sammy.js (also a JS framework with routing and so on), and it already seems to me it might not always be a good match. For example sometimes I only want to render a part of the screen/web site again, not the whole thing. What then should be my route? I guess it could work like the AJAX updates in Rails, but still, I wonder if it is too complicated to go through all the routing and so on.

Why not just bind events to actions directly, and update at will from inside the event handler?

What advantage do backbone.js models provide over javascript objects?

View on HN

What advantage do backbone.js models provide over javascript objects?

Event binding, refreshing to the server, dirty tracking, etc.

Basically, the pattern is: get JSON doc from the server, inflate it into a model, hook in a view, and then as you mutate the model, in code or the UI, the UI and server are updated. Can you write this yourself? Of course. Do you want to? That's up to you.

Personally, I find Backbone's sugar most useful for views. You make a DOM element that represents your thing, and then you program in terms of that thing, and the UI "just works". It's wonderful.

Anyway, Backbone is absolutely not overkill. It's just what many apps need, and you can use as much of it as you want.

(I should point out that I don't do server-side HTML anymore. My web apps are JSON/REST endpoints that also serve a few pieces of static HTML, JS, and CSS. Everything UI-related is done on the client side. Backbone makes this amazingly easy.)

"My web apps are JSON/REST endpoints that also serve a few pieces of static HTML, JS, and CSS."

^^^^ THIS

This is also a particularly good pattern for mobile applications as well. Your app serves a tiny page, and then lets it load the data basically in the background. Combine with some localstorage to show the information from the last time they were there right away, and you can make apps that feel significantly more responsive than they were before.

For small web pages (not web apps), as well as web apps that don't involve much JavaScript -- you're absolutely right, there's no benefit in using Backbone.js.

The idea with Backbone is to provide structure for large JS applications that involve manipulating state in the client. Too often, they can devolve into jQuery spaghetti, all updating a nested global JSON object. Backbone models provide a large number of data manipulation functions (map, reduce, filter, reject, any, etc...), RESTful persistence for your data, as well as events you can hook into, so that your models and views are notified whenever the state changes.

In the end, instead of peeking into a blob of JSON, tweaking the DOM manually, and making a $.ajax call, the hope is that you'll be able to write:

    note.save({title: "Lorem Ipsum"});

... and all of the UI currently referencing the note automatically updates, and the changes are saved to the server.

Also, note that Backbone has quite a different philosophy than Sammy. For more on that, see: http://news.ycombinator.com/item?id=1887563

Can you give us some comments on knockout.js and <angular>?

I'm afraid I can't give you anything informed ... as I haven't used either of them in anger.

That said, they take a very different approach: less about data modeling and events, and more about binding JSON structures tightly to specific DOM elements. I have my own concerns about if it's possible to build truly high-performance web applications with such a granular scheme -- for example, Knockout.js calls JavaScript's "eval()" on every "data-bind" attribute in your HTML. But without someone taking the time to port the same app to all three libraries, and then evaluating it with benchmarks, it's all just speculation.

I've just been building a large app with Backbone.js, and I can tell you that it is seriously versatile. I don't use the routing at all, I just move objects around and save and load them from and to the server. The great advantage is in the structure it gives your app.

Say you have an onscreen cat picture which can be moved around the screen (it has x,y coordinates). So you create a CatModel with attributes called x and y. You have a CatView which has an associated div - the cat picture. Now you can just bind your view to the "change:x" and "change:y" events of the CatModel, and have it update onscreen whenever the data model changes. Maybe every time you move the CatView with your mouse you call model.save() - that will be sent as a REST request for you. Now call model.fetch() every 5 seconds, and the onscreen cat picture will move to whatever state is held on the server. The code is clean, and tiny.

I guess what I'm saying is that it will only take you 5 minutes to create a massively multiplayer online cat picture moving game, with far less code you might otherwise have needed.

sounds fun. Let me know when you're accepting beta signups for your cat mmo.

One of the really nice things about Backbone is you can you as little or as much as you need. Don't need collections? Don't use them. No need for a controller structure? Not a problem. You could also build your own thinner structures on top of its Event structure to get the advantages of event-driven callback structures without any of the other stuff.

It sounds to me like you're using controllers because it seems logical coming from a Rails background, not because you need to. Take a look at the example Todo app - no controller, entirely atomic screen repaints as needed via collection/model to view bindings.

The models provide a framework for things like validation or presenter methods and keeping data and methods separate as well as a framework for event binding with a really, really nice syntax.

These are valid concerns.

I think that the client/server distinction is in a state of flux right now. As we make richer applications on the web, a lot of that server complexity is being moved to the client. The goal of Backbone is explicitly to deal with this.

Backbone is, however, designed to deal with fairly complex applications. If you've got something that's relatively simple, then Sammy might be the way to go.

What Backbone does provide is enough structure to encourage nice, clean, modular designs. Something that JavaScript developers haven't had to think about quite so much in the past. The other options that attempt this are huge, and don't provide a lot of the flexibility that web developers are used to.

If you think you've got a simpler, cleaner idea, then by all means give it a try, but out of the options out there, Backbone is my favorite.

For rich JavaScript app I find Backbone underwhelming. There's too much wiring up to do and as you say you might as well bind events and actions directly. If you've written richer desktop like apps before than Backbone is nothing new. It's more for the people who use HTML and Javascript without much thought to structure, dare I say the vast majority of jQuery users.

Backbone's advantage over normal javascript objects is Backbone provides events when objects and collections change. I dislike how Backbone achieves that through force use of set() and get() as property accessors. I prefer KnockoutJS models as they look and behave like plain old javascript objects, i.e. you don't have to call model.toJSON() to use a model as an argument for a plain object.

Reply on news.ycombinator.com