Rails – The next five years
One of the talks that I was able to attend at this year’s RailsConf was ‘Rails – The Next Five Years’ by Yehuda Katz. I thought it was a really interesting presentation – Yehuda discussed why Rails is still relevant (after being around for 8 years) and the direction that he thinks Rails should be going for the next few years.
I agreed with most of what he said and it was very thought-provoking – it really made me think about how Rails is different and what it means for everyday development as well as the future of the framework.
The Ideas Underlying Rails are still controversial
Rails has always promoted the idea of convention over configuration. If you’re using Rails every day you probably don’t think about it, but this is actually a rather controversial idea. Every other web-framework focuses on being flexible rather than being opinionated and trying to eliminating some of the default choices developers face on a daily basis.
For example, consider the REST conventions introduced in Rails 2. Before RESTful routes were introduced we constantly had to make decisions about what we wanted our different routes and actions to look like – decisions that we had to make over and over for every application we developed. While we did have to take some pain in switching over to RESTful routes, there were benefits which made it all worthwhile.
I don’t think I’ve ever had a conversation about how we choose our routes since then – even though the introduction of REST was a controversial decision the existance of a convention meant Rails had already made the decision for us. In my opinion this is a good example of how the introduction of a convention has been a big win for Rails – it doesn’t actually matter that we chose REST. The mere introduction of the convention has removed the need for a trivial decision that we all had to make.
The other type of common problem that Rails tries to solve is problems which are very hard to understand. A good example is XSRF protection – it’s a reasonably tricky problem to understand, but we all have to deal with it. The fact that Rails has this protection built-in means we don’t have to worry about it – the framework solves the problem for us.
So Rails tries to eliminate trivial choices and solve problems which are difficult to understand by introducing conventions. What does this mean for the future of Rails?
JavaScript Applications versus HTML Applications
Rails 3 has very good conventions for developing HTML applications – you get MVC, RESTful routes, helpers, a templating engine – pretty much all the different elements you need for developing an HTML application. Where Rails doesn’t currently have strong conventions is with developing JavaScript applications – applications which are developed using client-side frameworks such as BackBone, Spine, Ember or JavaScriptMVC. In these types of applications Rails is primarily used for serving and consuming JSON.
Yehuda has been working on ActiveModel Serializers – this is a library that integrates with Rails and allows you to easily standardize the JSON being returned from your Rails. I didn’t actually think about it until he pointed it out, but there are various decisions to be made when returning JSON – whether or not to include id’s, how much of the object graph to load, how associated objects should be serialized (do you include only the id or do you include the entire object), etc. When your Rails application is primarily used for this purpose you end up having to make these decisions over and over – clearly an area where Rails could introduce some conventions to help us out.
My 2 cents
I agree that this is the correct direction for Rails to take – it should be easy to develop JavaScript applications with Rails. Personally I would like to see Rails push the limits in this area and expose a Hypermedia API by default. This means the JSON being returned would include links to the different objects being exposed by your application. Yehuda did mention this in his presentation and I think this would be a great addition to Rails.
The other area I would like to see Rails standardize on is with authentication and authorization. Currently most applications use libraries such as devise and it seems very strange that there is no standard solution within Rails.
Happy coding.