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.”

The Rails 3.0 development team has been working to improve the security model, and also has also been working closely with Thomas Enebo and Charles Nutter, co-creators of JRuby. JRuby allows Ruby code to run on a Java virtual machine without modification, and it gives Ruby developers access to Java libraries. Katz said that no specific work was done for JRuby, but that Rails 3.0 has been tested along the way to ensure compatibility.

“A lot of the things we added to Rails 3 were shaped by JRuby and Charlie [Nutter],” said Katz. “Charlie wants to allow existing Hibernate models to work within Rails. That’s not going to ship with Rails, but the way we built it, it’s possible to swap in something for using Hibernate.

“Because of the fact that we’ve made our layers agnostic, it’s really easy to work with JRuby. We will see things, Hibernate being the first obvious example, that will highlight this interoperability.”

For the future, Katz said the Rails team is looking at the development model created by Sinatra. Sinatra is a domain-specific language for quickly creating Web applications in Ruby. While Ruby on Rails speeds up the development process, Sinatra forsakes configurability and customizations in favor of simple and fast development.

Katz said that much of Sinatra is too simplified to bring into Rails’ primary code without significant work. He also said that the effectiveness of Sinatra could be increased by allowing Sinatra templates to function in Rails.