top | item 2196753

Backbone.js Tutorial with Rails Part 2

93 points| jamesjyu | 15 years ago |jamesyu.org

19 comments

order
[+] dogas|15 years ago|reply
This seems like shoehorning a JavaScript-based web framework on top of an existing web framework, which looks like it adds a lot of work.

I almost threw myself out the window after seeing that hard-coded HTML in a JavaScript string. How is that maintainable or even nice to look at? It's not.

Am I crazy? What is the benefit of this? With a bit of customization rails could do this out of the box without a duplicate MVC arch.

[+] ladon86|15 years ago|reply
Let's say you're writing an app like Google Docs, which does a lot of work on the client.

Before long you're going to have a real mess of Javascript variables, DOM elements and arrays of stuff, which is why it's useful to have MVC structure on the client as well as the server.

Your server models sync automatically to your client models, you can hit model.save() to persist your client models, and your client views represent the data in a way which can be quickly adapted if requirements change.

For a less dynamic app you don't need it.

[+] pdelgallego|15 years ago|reply
This is not the best example.

You actually don't need to hardcode the html in the javascript. You can use a template system that is already included in backbone, or you can preform a request to the server,

I prefer the first approach.

[+] jamesjyu|15 years ago|reply
Actually, in the tutorial, I go through how you can use Underscore templates, which are stored as .jst files alongside your regular ERb templates. (no hardcoded strings)

I can tell you know that after using Backbone for a largish javascript project, it really eases the pain that comes with syncing data to and from the server, and handling all the random bits of javascript that usually pile up in a Rails application.

Basically, it gives you a logical place for everything.

Of course, if you're app isn't javascript intensive, there's no reason to use it.

[+] ankimal|15 years ago|reply
We ve started using this after I could not spin my head around all those spaghetti jQuery based functions we have been using as an excuse to make dynamic web apps. If u are using a lot of front end JS but dont want to migrate to a full blown framework (sproutcore, cappuccino etc.), Backbone.js is a great choice.

Word of caution though, it can get a little frustrating to start with (especially event binding) but once over that first bump, this just makes your code so much more readable and maintainable.

[+] dustineichler|15 years ago|reply
James, i rolled part1 into an app(s). Merci. I'm building all my rails apps this way from here on out.
[+] glenjamin|15 years ago|reply
Please correct me if i'm wrong, but isn't this pretty much the same as http://news.ycombinator.com/item?id=2196160

There's no graceful degradation at all, and in order to provide graceful degradation you'd have to duplicate the view templates (at the very least).

[+] moe|15 years ago|reply
Graceful degradation becomes increasingly less relevant (except for the "degrade to internet explorer" part).

When was the last time you used a browser that had no javascript? When did you last time manually confirm a cookie?

User Experience trumps Graceful Degradation.

[+] gaustin|15 years ago|reply
Does anyone know if Backbone.js is compatible with MooTools?

I like the MooTools API better than JQuery's.

E.g.

new Element('div').grab(new Element('a'));

versus

$('<div></div>').append('<a></a>');