Mention Rails, and you will often believe you are debating White Castle burgers. You either love or hate it with little room for anything in between. DHH created a framework where you generally have to play by his rules and if you disagree with those rules, you might become frustrated or a bit disgruntled while working in the framework.
Whether you are comfortable working within DHH’s framework or not, the fact is that the train is moving and it includes new features that will improve your apps as the version matures. Developers using Rails will cringe at points similar to what we felt with the introduction of the asset pipeline. Even tonight, as I write this post, I have had a moment of asset pipeline cringing. Hating the change… or as DHH puts it, the “progress”…
However, there are numerous advantages to using Rails and the newest installment will build on and create new features that will make development easier, more secure, and more fun (at least we hope in the long run).
The public betas are out and a number of applications are already deployed in production running Rails 4.0. Not surprisingly, DHH’s own 37 Signals Basecamp Breeze was one of the first to make the leap back in January and they have plans to convert the entire Basecamp application to Rails 4.0 in the near future. PaaS providers, such as Heroku, are also moving to embrace the new technology.
So, what are some of the ways that Rails 4.0 will rock your world.
1. Ruby 2.0 preferred
Rails is moving in to the future with Ruby. Although you can use Rails 4 with >= Ruby 1.9.3, the preferred Ruby is 2.0 for this newest iteration of Rails.
2. Turbolinks
Uh oh. Perhaps now is the time to spend a very worthwhile hour watching the DHH RailsConf 2012 speech, because the mantra of progress, progress, progress, must be kept in mind.
So, what does it do? Basically, it is designed to put the links in your web app in turbo mode, thus the name Turbolinks. It does this by keeping the current page instance alive and replacing only the body and the title in the head.
How fast is it?
Well, that is sort of a difficult question to answer. It really depends on how much CSS and JavaScript you have. The Turbolinks site says that it may be up to twice as fast, but you certainly may not notice this type of improvement. The good news that it is fairly easy to test and determine if it makes sense for your development and use it only if it benefits you. So read on…
Do I have to use it?
No. Although by default, all internal HTML links will be sent through Turbolinks, it can easily be disabled. If you mark the body with data-no-turbolink, all links on that page will be regular links. You also have the ability to be a bit more granular, for example, you could also mark a div with data-no-turbolink and the result would disable Turbolinks for all links inside that div.
So what’s the risk?
Well, compatibility for one… Some of your favorite javascript libraries, plug-ins, and snippets will not work out of the box with Turbolinks. There is a pretty significant effort to get these working, but this may be a showstopper for those developers that don’t have the time or energy to focus on troubleshooting third-party issues.
Another thing that you will need to keep in mind while using Turbolinks is that if you have a lot of JavaScript, you could run in to some memory leak issues.
It’s a bit early to tell if this feature will rock your world or if the fact that you can disable this behavior is the cool part.
RussianRussian Doll Caching made easy
This performance increasing technique works by nesting fragment caches to maximize cache hits.
For the developer, this is a fairly straight-forward implementation. If you have a model that has a belongs_to relationship, you can just add touch: true and will ensure that when the instance is changed, that it updates the related model as well.
To illustrate, say you have a model Pet and Dog model:
class Pets < ActiveRecord::Base
has_many :dogs
end
class Dog < ActiveRecord::Base
belongs_to :pets, touch: true
end
That simple ‘touch’ addition allows us to make sure that when a dog is modified, the pets model is updated as well.
So the view template should look something like the following:
<!-- app/views/pets/show.html.erb -->
<% cache @pet do %>
<h1><%= @pet.name %></h1>
<%= render @pet.dogs %>
<% end %>
<!-- app/views/dogs/_dog.html.erb -->
<% cache dog do %>
<div class='dog'>
<span><%= dog.name %></span>
<%= dog.owner %>
</div>
<% end %>
So now if you have a bunch of dogs, if you edit one dog, the pets cache will break, but in the rendering of the HTML, all but one of the partials can be obtained through the cache, which will improve render times.
Although we’ve seen some cooling in Rails growth in recent years, one thing is certain, Rails 4.0 is coming, so don’t get caught laying across the tracks 🙂
