Hacker News new | past | comments | ask | show | jobs | submit login
Backbone.js Tutorial with Rails Part 2 (jamesyu.org)
93 points by jamesjyu on Feb 9, 2011 | hide | past | web | favorite | 19 comments

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.

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.

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.

Backbone has built in support for templating. All you have to do is tell your View object what template it needs to render and you're on your way. Obviously, you can use whatever you are comfortable with: mustache, underscore, jTemplates etc.

Or you can hardcode them using CoffeeScript's heredoc syntax.

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.

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.

James, i rolled part1 into an app(s). Merci. I'm building all my rails apps this way from here on out.

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

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.

Spoken like a true novice.

If you want to completely throw out search engine crawlers viewing your content, 508 compliance, and 5-10% of your visitors with Javascript disabled, then sure ignore Gracefully Degradation. Not to mention that Graceful Degradation is frowned upon to begin with, you should be Progressively Enhancing. Starting with a site deeply entrenched in spaghetti Javascript code and trying to make it work without it takes a ridiculous amount of time compared to just building the site without a single line of Javascript written to begin with, and just provide all the fancy features after you have a full, working site.

Spoken like a true novice.

Thanks for the assessment. I'll put that on my resume next to the 10yrs of web work.

search engine crawlers


508 compliance

It may sounds harsh but most sites couldn't care less about accessibility because it's not required by law and because users with assistive devices don't account for a measurable portion of their revenue.

5-10% of your visitors with Javascript disabled

Not sure what kind of site you have there, my reports are more inline with what yahoo measures (i.e. hovering around 1%):


Starting with a site deeply entrenched in spaghetti Javascript code and trying to make it work without it takes a ridiculous amount of time compared to just building the site without a single line of Javascript written to begin with

Spoken like a true novice.

508 Compliance might be a luxury in the US, but not making a website accessible would be a breach of the Disability Discrimination Act (DDA) in the UK.

I'm not aware of anyone attempting to enforce this however.

Doing something for 10 years doesn't make the work you did over those 10 years right.


Google, Yahoo, AOL, and several other major web companies all recommend Progressive Enhancement. But sure, you know better.

I think you're talking past each other. If you want to build a web-based spreadsheet application, you neither "progressively enhance" nor do you "gracefully degrade". Your browser is either a supported runtime or it's not.

Sure, if you're building a content site, you will want to have progressive enhancement, but if you're building a client-side application, SEO concerns and the other concerns of content-delivery sites are less relevant.

Well, sorry to see you resort to argumentum ad hominem after I replied to each individual point that you made.

Does anyone know if Backbone.js is compatible with MooTools?

I like the MooTools API better than JQuery's.


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



This isn't up to speed with the latest version, but it could probably be brought up to date pretty easily:



Let the hot forking action commence.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact