David Heinemeier Hansson >> Rails has embraced Ajax in its core deeper and faster than any other integrated framework out there. We have the authors of the most successful Javascript frameworks for Ajax development in our core group: Sam Stephenson of Prototype and Thomas Fuchs of script.aculo.us.

"Rails has embraced Ajax in its core, deeper and faster than any other integrated framework..."

This has granted Rails a huge lead on integrated Ajax development. By chasing the notion that Ajax in Rails should be "as easy as not to", we're stripping the rocket surgeons of their monopoly on this technology and making every developer capable of creating modern applications with Ajax.

We're approach the 1-year anniversary of Ajax in Rails while most everyone else are still considering this early-adopter technology.

Satish Talim >> Are there any plans to integrate (a) multilingual support into “Rails” (b) a Reporting tool into “Rails”?

David Heinemeier Hansson >> There is already plenty and strong multilingual support in Rails through plugins such as Localize and Globalize. Internationalization is one of those features where different people wants different things, which makes it a questionable candidate for framework extraction. Good frameworks do their best when they're abstracting the ways most people do most of their things.

So no, we're not looking to get the kitchen sink into Rails. But we're very enthusiastically encouraging people to develop plugins. Once something is a plugin, it integrates with Rails so cleanly that you can't tell the difference between "native" Rails and "plugin" Rails code.

Internationalization and reporting are both obvious candidates for plugins.

Satish Talim >> One of the wonderful features of Rails is the differentiation between production and development environment, which normally doesn’t come with web tools. Was it a conscious decision to add a flavor of "Enterprise" feature in Rails?

David Heinemeier Hansson >> Actually, we have a conscious mission to avoid things with enterprise labels. To me, enterprise is not about technology or best practices. But all about legacy, complexity, and doubtful value.

"We have a conscious mission to avoid things with enterprise labels..."

So the fact that Rails supports three environments out the box (test, development, and production) is not about enterprise, but about pragmatism and need. To do sane development, you need this division. Every thing from the smallest 4-hour application to the biggest projects benefits from it.

Satish Talim >> Is “Rails” well-suited for Enterprise level applications?

David Heinemeier Hansson >> Again, I think of the "Enterprise" label as an excuse to deliver expensive and painful software over budget and late. So I'm hesitant to say that Rails is well suited for that. But if you take the more generally used definition, such as "important software for the Fortune 1000", then yes, I most certainly think Rails is well suited to serve them. Who are not interested in getting valuable software faster and cheaper?

I think of the "Enterprise" label as an excuse to deliver expensive and painful software over budget and late.

The caveat to that is of course that a lot of enterprises are culturally and mentally unable to embrace the philosophies that Rails are built upon. So if you're not having any luck getting agile methodologies adopted by your organization, there's a good chance that Rails will be a poor fit. Not for technical reasons, but for political ones.

And the final caveat is of course that Rails is about a vertical, but huge, scope: The service/database-backed application. So it won't help you launch rockets into space or power the pacemaker. It's just about delivering applications for the web.