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.
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?
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?
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 🙂