The first beta of Rails 3.0 was released in early February, bringing together numerous Ruby on Rails sub-projects and introducing a new modular underpinning for the platform.

Yehuda Katz, Rails framework architect at Ruby testing company Engine Yard, said that much of the work that has taken place over the last year has involved the merging of outside projects into Rails, the overall modularization of the platform, and a new focus on default security practices.

In Rails 3.0, the platform inserts an escape command automatically to escape content brought in from other sites, halting the potential for cross-site-scripting vulnerabilities occurring by accident. Katz said Rails is now more pessimistic by default.

Since the December 2008 merger of Rails with the Merb project, Katz, who was one of the driving developers behind Merb, said, “The community has gotten a lot healthier. People were feeling like Rails was getting stagnant. A lot of people are coming back now, and there are a lot who are coming to Rails to contribute for the first time.”

Webrat, an integration testing framework, has been merged into Rails 3.0, as has Micronaut, a behavior-driven development framework. Both of the projects started as independent open-source efforts.

But the biggest change to Rails 3.0 is the modularization of the platform. Katz said that the Rails team went through the codebase and endeavored to remove all the ingrained code that tied Rails to outside frameworks, like TestUnit and Prototype.js.

“Rails is no longer coupled to Prototype,” said Katz, explaining the removal of close ties to the JavaScript compatibility framework. “That was a community effort. David Heinemeier Hansson [creator of Ruby on Rails] tweeted, ‘We’re running behind,’ and a community formed out of the ether. Less than a week later it was all done.”

This uncoupling extends to other aspects of Rails. “Rails controller-view code is no longer coupled to the models, so you can use any views you want,” said Katz. “We also added support for other templating languages. We made it a lot easier to support other testing frameworks. TestUnit was standard, and others had to do a lot of work to strip out our support for TestUnit and add their own. Using RSpec felt worse than using TestUnit. TestUnit itself is a plug-in now.”