Backbone.js Tutorial with Rails Part 2
jamesyu.org
jamesyu.org
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.
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.
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.
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.
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.
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).
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.
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.
Thanks for the assessment. I'll put that on my resume next to the 10yrs of web work.
search engine crawlers
http://code.google.com/web/ajaxcrawling/docs/getting-started...
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%):
http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-...
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.
http://www.google.com/support/webmasters/bin/answer.py?hl=en...
Google, Yahoo, AOL, and several other major web companies all recommend Progressive Enhancement. But sure, you know better.
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.
I'm not aware of anyone attempting to enforce this however.
I like the MooTools API better than JQuery's.
E.g.
new Element('div').grab(new Element('a'));
versus
$('<div></div>').append('<a></a>');
Let the hot forking action commence.