"ruby on rails" with "ajax"

Ruby on Rails 跟 ajax 有一点联系，在 web development 中可以协同使用。
ajax的应用越加广泛，可以被整合到各种应用中，Ruby on Rails 可算一例。

Ruby on Rails Koolaid, Redux

Excuse me for a moment while I eat crow with some humble pie for dessert...

In February, after reading Curt Hibbs' Rolling with Ruby on Rails, I posted a blog entry titled Ruby on Rails Koolaid. That blog entry was based solely on Curt's article: I took issue with his assertion that development with Rails was at least 10 times faster than with any Java framework.

I took a fair bit of abuse for that post and it seems that even 6 months later, some folks are still upset with me. I must say though, that Curt has been most gracious even though I publicly disputed his claims.

In retrospect, my post was stupid and irresponsible. To publicly disparage claims about a framework I knew nothing about was wrong, not to mention just plain dumb, and to those I offended, I offer my sincere apologies.

So, with that out of the way, was Curt right? Is Rails development at least 10x as fast as your favorite Java web application framework? In a word: maybe. I would definitely agree with 5-10x as fast, but I'm not sure about numbers over 10. Note: my observations are based on about 1 month of Rails experience coupled with what I've read.

Why is development with Rails so much faster than with JSF, Tapestry, Struts, or whatever? The single biggest reason is zero turnaround time. You make changes to your application, refresh the browser, and voila, instantaneous feedback. For some, this might not be as appealing as it is for me. Coming from a SmallTalk background, I like to make tiny little changes quickly in succession. Some folks, like my friend Rob, who I worked with on my Cleveland job, like to write a ton of code before redeploying the app in the servlet container. In fact, I took quite a ribbing from Rob because I wasn't man enough to write large chunks of code at a time.

One thing that surprised me about Rails, once I started using it, was how robust it is. There are some very cool things in Rails: Active Record (Rails' ORM and the single biggest component of Rails) makes it drop-dead simple to write CRUD applications and from what I can tell, is robust enough to easily work with legacy databases; scaffolding gives you canned views and controllers, and although you will indeed replace nearly all of the generated scaffolding, it nonetheless provides a significant productivity boost; partial views are sort of Tiles-lite—you get ~70% of the functionality in Tiles (and SiteMesh, for that matter)—and partials are very simple to use (I've found that 70% to go a long way); convention over configuration lets you adhere to simple naming conventions instead of specifying tedious details in configuration files; 3 environments, one each for development, testing, and production, make each of those phases a little easier; testing baked into the framework makes it easy to implement tests, which means you're much more likely to actually write tests; and finally, Ajax support is absolutely killer in Rails.

Another thing that I didn't realize early on was how much Ruby shines through the Rails. With Ruby, you can, at runtime, add methods to classes, and Rails takes great advantage of this feature by stocking your models with methods that represent what's in database tables. That alone makes Rails very intuitive to use. And as I've said before, once you've been loosed from the confines of static type checking, you may never want to go back.

But of course, Rails is not perfect. For example, Rails suprisingly provides no built-in support for i18n or client-side validation. Yes, you can wrestle with get_text() and use that in conjunction with Rails to localize text, but who wants to endure that pain, not to mention, you've still got other i18n issues, such as unicode, localizing dates and times, etc. Frankly, I'm baffled by Rails' lack of support for i18n. Lack of client-side validation's not that big of a deal—especially now that we can easily use Ajax to validate w/o page refreshes—but lack of i18n support, especially in today's flat world, is hard to understand. And it's not like Rails users don't want i18n; I have recently witnessed Rails users drooling over the idea of resource bundles. Imagine.

And then there's the static type checking issue. I know some folks wouldn't dare to develop mission critical apps without stc, and I won't try to convince them otherwise (although the tight corset that Ada straps on wasn't enough to prevent the infamous Ariane 5 Rocket disaster). One thing about letting the wind blow up your skirt is that you've got to write tests. No choice, when things are this free and loose. Luckily Rails makes tests a breeze to write.

As most of you know, I was on the JSF 1.0 Expert Group, so you might be curious to know how I would compare Rails and JSF. We'll leave that to another post, or perhaps set of posts, but for now let me say one thing: JSF was created primarily for tool vendors, whereas Rails was created for developers. A fair percentage of what Rails does (perhaps 80-90%) could be implemented in a killer JSF-based IDE that featured incremental deployment, active record, etc., but we're simply not there yet in the JSF world. (Note: for Tapestry users, you might want to check out Trails. I haven't used it yet, but it looks interesting, although I'd rather do time in Jails )

Everything Zen
Everything Zen
I don't think so

Everything Zen
from sixteen stone by Bush