Firstly, allow me to state some facts. Rails is a really good framework for Ruby. Prototype, the JavaScript framework that comes with Rails, is also really, really good. The problem lies with the intersection of the two.
Dan Webb points to the problem. In Rails, you can add JavaScript helpers to your links, simply and easily. But those helpers then create redundant links (a href="#") with inline event handlers. As Dan quite rightly asks:
What happens when the user doesn’t have a new browser or has script disabled? What do search engines index?
Those are pretty fundamental questions.
David Heinemeier Hansson responds to Dan’s post, saying:
I’ll trade purity in HTML for purity in .rhtml any day of the week.
I couldn’t disagree with this sentence more. I’m all for making the developer’s life easier but when convenience for the developer is valued above ease of use for the end user, your priorities have become seriously messed up.
Fortunately, a solution should be forthcoming. Dan is working on a patch. Also, I remember talking to Dunstan when he was working on Odeo, another Ruby on Rails application, and, with a little bit of hacking, he was able to get the JavaScript to behave. That does prompt the question, though: if it is possible to have Rails produce unobtrusive JavaScript, why doesn’t it do so out of the box?
It may sound like I’m picking on Rails here, which isn’t my intention. On Wednesday, I listened to David outline the benefits of the framework and it was very convincing. But it’s precisely because Rails is built upon the ideals of best practices and doing the right thing that it pains me to see it fall short of those goals in this one area. After all, it doesn’t surprise me in the least that the ASP.NET framework spits out the most awful obtrusive JavaScript, as Stuart noted:
There’s a huge
__VIEWSTATEform variable, and links seem to call a JavaScript function called__doPostBack(). Of course, it requires JavaScript to work. This is shit. Yes it is.
It’s kind of like Google and Microsoft: nobody would bat an eyelid if Microsoft censored search results in China, but when a company with the ethos “don’t be evil” does it, they are quite rightly held to a higher standard. So, if I seem to be unfairly singling out Rails, that’s just because it’s held to a higher standard.
Posted by Jeremy on Monday, February 13th, 2006 at 9:49pm
Comments
This is an important issue not just for developers who care about the "purity of their HTML," but also, as Dan is suggesting, for people contributing content in application spaces that need to be indexable by search engines at Yahoo, Microsoft, and…oh, drat…what’s that other one? The machine has become a crucial part of our audience, because the way the searchbot reads our text determines to a lare extent whether we get access to a human audience; search has become the principle gateway to edge content, and we depend on simple, machine-readable HTML to help searchbots help readers find the creative work we post in "edge systems" (many of which, for good reason, are written in Rails).
Most of the people creating content at the edge don’t fully understand the nuances of audience-acquisition in the Googleocracy…it’s up to developers to make sure that this is as straightforward as possible.
# Posted by Eric Miraglia on Monday, February 13th, 2006 at 11:01pm
Your analysis is spot-on. I frequently use bits and pieces of Prototype unobtrusively (in both static and dynamic environs), and I am similarly disappointed by Rails’ kludgy JS helpers. I won’t presume to scoff at how "easy" this would be to implement, but I will look after this patch-effort with great interest.
# Posted by Daniel Stockman on Tuesday, February 14th, 2006 at 12:13am
As I voiced on Dans comments I have the same issue with that as well. Again I like rails but it’s fabled speed seems to be, in a few places, aimed more at rapid prototyping (not the JS library!) apps than building the finished thing. The latter taking more time than you might think.
And dont even mention the hideous linkButton asp.net control.
# Posted by Gareth on Tuesday, February 14th, 2006 at 1:57pm
I hope that your patch can be absorbed by DHH into the rails tree, and they can make an effort at truly having good javascript support.
# Posted by JohnO on Tuesday, February 14th, 2006 at 2:02pm
Hey guys. It’s great to see passion around wanting to improve the use of Javascript in Rails. Love it. But let’s keep beans and apples in separate pots. The Javascript helpers does nothing to prevent you from writing machine-readable HTML that’s easy to index and to provide script-powered ahrefs that also serves as normal links.
The charge is that Rails uses inline JS calls in the onclick, onsubmit, and other triggers. This does nothing to change the structure of the document (there’s no superflous tags or forcing of specific tags), but it does indeed lead to verbose attributes of said tags with that inline JS stuff.
So this is a matter of purity of the resulting HTML for the human eye. Nothing more. Mind you, though, that I care deeply about the beauty of code to the human eye, so I can most definitely sympathies with people desiring that the generated HTML be beautiful too. Which is of course why I say: Rock on!
But let’s be sure to keep things in perspective. There’s no need to pad the argument. Desiring beautiful HTML purely for aesthetic reasons is plenty motivation to attempt to improve ;)
# Posted by David Heinemeier Hansson on Wednesday, February 15th, 2006 at 5:34am
Looking at Basecamp’s HTML this was the one thing that gave me pause for thought - I’m glad to see you highlight this issue Jeremy.
While David may be right that Rails doesn’t prevent the better way of doing scripting, it certainly isn’t the convention, it would be extra work. David knows how important conventions are and should work accordingly.
Rails has a lot to recommend it but they really need to practise what they preach with the use of accessible JS - onClick is just so last year.
# Posted by Jason Kitcat on Wednesday, February 15th, 2006 at 3:12pm
Indeed, href="#" is an accessibility nightmare. I mean, who cares (at this point) if JavaScript is inline. Yes, unobtrusive would be ideal at its best, but it’s not like we can achieve the accessible webpage via this.href from an onclick event handler directly on the anchor element. But for the record, I did not directly advocate the use of inline JavaScript, I’m just saying it can still exist and not screw accessibility.
# Posted by Dustin Diaz on Sunday, February 19th, 2006 at 3:15am
I noticed IconBuffet (a RoR app), uses accessible AJAX links. Even though the javascript is inline, it at least degrades nicely when scripting is not enabled. This behavior should be the default in Rails.
# Posted by Brian Sweeting on Wednesday, March 1st, 2006 at 5:58am
Sorry. Comments are closed.