Final Ruby on Rails 3.0 Beta Due at RailsConf, RC to Follow

The Ruby on Rails community is set to release a final beta of Rails 3.0 as early as June 8 and to deliver a release candidate of the latest version of the popular Web framework by June 11. Meanwhile, the outline for Rails 3.1 is being plotted.

BALTIMORE-The Ruby on Rails community is set to release a final beta of Rails 3.0 as early as June 8 and to deliver a release candidate (RC) of the latest version of the popular Web framework by June 11.

In an interview with eWEEK, Yehuda Katz, a Rails framework architect at Rails cloud company Engine Yard and a key committer to the Rails core, said his goal is to deliver a final version of the Rails 3.0 beta by the time of his keynote address, which is scheduled for the evening of June 8 at the RailsConf 2010 show here.

Katz said the release of the final beta at the annual conference of Ruby on Rails developers will allow folks to "bang on," or test, the beta so that the team can get feedback to ply into the RC of the technology, which Katz said will be delivered by June 11.

Meanwhile, Ruby on Rails creator, David Heinemeier Hansson, delivered a keynote on the morning of June 8, saying he did not like to get into "future code" or vaporware during a talk so he would focus on Rails 3. However, by the end of his presentation, Hansson began to talk in general terms about what he hopes to see in Rails 3.1.

Hansson said his company, 37Signals, has begun to move many of its core applications to Rails 3. He said one of the strengths of Rails 3 is that it is "a lot easier in dealing with the annoyances" of programming.

In addition, Hansson said Rails 3 blends the power of Rails that experienced developers want and need, with the type of programming environment that also is attractive to beginners. "We want more people to get into the game," he said.

Ruby and Rails have been known for being attractive to beginners; however, some in the community feared the language could fall into the trap of making changes that focused more on the experienced or advance developer and did little for the beginner. Rails 3 overcomes this challenge, Katz says.

"Rails has always been very good for beginners, but at this point, it would be easy to say, -Oh, let's give in to the 1 million or so developers we have and give all the benefit to them.' Rails 1.0 was entirely focused on the beginner, but with Rails 3 we are able to deliver benefit for both groups. It's more about not losing the momentum of beginners while giving the people who've been around awhile the challenge and capability to make new and better stuff."

Katz echoed Hansson in saying that Rails 3 is primarily "focused on improving the code base, making hard things easy. We made a lot of user-facing improvements." He also said "the team improved dependency management, improved the way plug-ins work, and we improved performance and security."

The team improved dependency management with Bundler, which works out of the box with Rails 3. Bundler manages an application's dependencies through its entire life cycle across many machines.

"There have been many attempts to do this, but Bundler brings the best-of-breed dependency management techniques to Ruby and puts a Ruby shine on it," Katz said.

Both Katz and Hansson also talked about the enhanced Router, ActiveRecord and ActionMailer technology in Rails 3 as being key improvements. For instance, the new Router helps developers avoid flow ownership issues, "hasheritis" and yield overhead, Hansson said.

And regarding security, Rails 3 applications are "by default protected XSS [cross-site scripting] attacks," Katz said.

Toward the end of his talk, Hansson said, "I do sometimes get sucked into vaporware code," and began to rattle off some of his concerns for what should come in Rails 3.1.

One thing Hansson mentioned was that Rails 3.1 should improve the way Rails handles JavaScript, Style Sheets, icons and images. "We're looking at dealing with icons and images by rolling them down into sprites," he said.

Spriting is the concept of pulling together several images so that they appear as one single image. "If you have 50 images, you want to show that as one image," Katz said.

A 37Signals post about spriting said: "Another approach we've used is CSS sprites, a method for combining many graphics into a single image which is then displayed via CSS. For us this technique reduced dozens of HTTP requests into one-a single, cache-friendly image file."

"The gist of Rails 3.1 is now that we've restructured things [with Rails 3], it's time to go look at some of the other big issues, like improving how JavaScript, CSS and images work in Rails," Katz said. "Most Web frameworks say that is just static and treat it as such, but we want to take a different approach. With Rails 3.1 we're looking at the remaining user-facing things we need to fix. We won't have to go back and do the refactoring we did in Rails 3.0. Rails 3.1 will be more about adding nice things to the framework."