Rails is for slobs

<rant>

To me, the Ruby on Rails bandwagon is a streetcar that I habitually jump onto and off of as I work. Every time I try to give up

PHP, I do so by compromising the quality of the documents I produce. Rails encourages you to create sloppy markup. Without a doubt, the language does a fantastic job at eliminating the [CRUD][crud] involved in web programming, but at what cost?

I think HTML is a beautiful, intricate and subtle language abused by web programmers like Hollywood attempting a Stephen King novel. (Yeah, so I’m a nerd. Moving on…) As a web programming framework, Ruby on Rails has the distinct ability to simplify the creation of HTML in order to encourage more semantic, valuable and elegant use of the language; it could help make the web a better place.

Does it? No.

Perhaps I’m alone in this view. Perhaps I’m a neurotic freak. Perhaps I’m just not a good enough programmer to solve these problems myself. Regardless, every time I develop a web application with Rails, I grind my teeth at the sloppy code (typography, content) that I’m left with.

Rails can’t figure out unicode.

It comes from reading too many books, but there is a soft spot in my heart for good typography. I would stand outside of Two Weeks Notice with an apostrophe on a stick too. And every time I see “--” used as an em dash (—) I want to scream. I appreciate a fine ellipse. I do make spelling errors, but hey—nobody’s perfect.

Now most keyboards can’t type these fancy punctuation marks without pressing three or more keys, and the most common character set on the web (the default for most English-language servers) can’t even display these characters natively. There are two solutions to this problem: escaping these characters, or switching to Unicode (which can handle almost any character in almost any language). Conveniently, Rails does neither.

According to the Rails wiki,

Rails basically knows noting about Unicode. Although it offers some hacks and half-solutions to using Unicode, it also reminds the reader that the functions Unicode breaks are used heavily under-the-hood, and could cause unpredictable errors.

Ruby also has a built-in html_escape function (a.k.a. h()) to escape characters that might cause problems and prevent security issues. Yet h('…') == '…' and not the escaped equivalent (… or …).

Granted, setting up this weblog to use Unicode was not a simple process. Wordpress doesn’t do it by default, no does my server, nor my template … you get the point. Luckily,

PHP has the power to let me solve these problems in a straightforward, albeit convoluted manner: I had to tell my server to send the right headers, had to set my database to the right encoding, and had to put the right encoding in my HTML, as well as include the Unicode characters in the actual content.

While I could (theoretically) make these same fixes with Rails all of these layers are not separate. They interact and make assumptions about each other. Changing settings in different areas has the potential to fubar other parts. Once mature, Rails should have an application-wide setting for text encoding.

Rails can’t figure out XHTML.

All of the built-in Rails helpers create

XHTML elements instead of HTMLtags. Yet it sends all files as HTML, notXHTML. Generated files don’t even have a DOCTYPE or namespace declaration, which means they’ll be treated haphazardly by web browsers. While I don’t think this is [dangerous][], I do think it show a poor understanding of what XHTML is and its benefits. Negotiating content between the two is a masochist’s pipe dream (I tried it).

Rails should use HTML as their default for a number of reasons:

• The Web is not going to give up on HTML in the next 10 years.
• Users unfamiliar with the nuances of the two languages will most likely have XHTML-invalidating errors anyway.
• Rails already sends its content as text/html
• Rail mostly uses helpers to create empty elements (<link>, <image> and <input>), so only hand-crafted code needs to conform one way or another.
• HTML performs more uniformly across browsers today (i.e. Internet Explorer never puts HTMLstrict in quirks mode).
• The document object model always works the same way inHTML, and always will.

This point is largely moot, as today there is little to no functional difference between HTML and

XHTML when they are served with the sameMIMEtype. But if it doesn’t matter, why use the language that is not future proof and most people get wrong anyway?

Luckily, if this is an issue, there is a tiny plugin to change this default behavior. I was not able to get it to install last time I tried; if you want it, contact me. Wordpress doesn’t give me this luxury—its helpers generate XHTML-style empty elements, and I am forced to play the XHTML game or invalidate. For now.

Are these valid issues?

To most people? Probably not. Those people are probably the same ones who wear white socks with black shoes and think Al Gore really meant to say he invented the Internet. They have a job they need to get done, and Rails helps them do just that. As for me, I take pride in what I create; I like other people to see my work—to really inspect it—and see that from bottom to top, I know what I’m doing.

</rant>