Rails 5 Changes

What’s new in Rails 5?

With the brazenness and controversy that has always surrounded it, Ruby on Rails 5 made it’s debut. David Heinemeier Hansson, the founder of the powerful web development framework  made the introduction at this year’s RailsConf. Rails has dramatically increased the speed of web development, but has fallen under criticism for not following peer endorsed architectural principles. DHH, as David Heinemeier Hansson is commonly referred to, confronts these principles head on and has created much controversy with his beliefs on software development. So does this major release move Rails software development down a less contentious path or one that will evoke even more debate?

According to DHH, Rails is heading down the right path. That should be of no surprise, but what is rather surprising is the lessening of vitriolic denunciations of the criticism directed at Rails.  In the RailsConf keynote, DHH talked about monolithic software, a bad word in development circles, and in his customary tongue-in-cheek way called it “majestic”. DHH realizes that such proclamations are very scary to many software developers, and assures them that you don’t have to build monolithic software with Rails. But is this really true with the direction Rails is going?

Before answering, let’s take a look at what Rails 5 introduces. The good stuff is that there are definitive improvements that increase the speed of development despite what coding philosophy you may have. For example, the annoying pain point that beginners face in deciding whether to use “rails” or “rake” to issue a command in the terminal is gone. All rake commands are included in the “rails” command. So instead of “rake db:migrate”, you can just type “rails db:migrate”. It’s a small change, but every step towards simplicity is more time that a developer has to focus on the actual problem domain. Another step towards simplicity is the inclusion of the rails-api gem into Rails itself. Now Rails, out of the box, can generate a new app that just includes what is necessary for an API: “rails new my_app –api” Restarting Rails and Spring is now also possible with “rails restart”. For those of us who have spent needless time debugging an issue without realizing a quick restart of Spring was all that was needed, this is a nice a little addition. Those are some of the improvements in efficiency, agnostic of developer religion. Now let’s dive into the religious wars.

Rails 5 introduces a new version of the controversial TurboLinks. TurboLinks is DHH’s attempt to bring the snappiness of client-side MVC apps to Rails apps. The first version of TurboLinks was criticized for not following the trend of JavaScript client-side frameworks such as Backbone.js and Ember.js and for not being practical for anything but the simplest apps. The first version of TurboLinks simply replaced everything within body of the body on each page change, while keeping the CSS, JavaScript, and most of what was in the HTML HEAD tag. That provided a speed boost to pages, but it was still refreshing the entire page as seen by the user. Alternatively, libraries such as WiseLinks https://github.com/igor-alexandrov/wiselinks, provided practical features such partial page reloading and the ability to work in older browsers. The new version of TurboLinks catches up though. Now any HTML element can be marked with “data-turbolinks-permanent” to prevent it from being reloaded during a new page request. For those proficient in JavaScript, the PJAX-like approach offered by TurboLinks and WiseLinks may provide a shorter learning curve than the prolific JavaScript MVC frameworks. The code readability and maintainability can also be competitive with MVC frameworks if the developer is experienced in architecting custom JavaScript code. TurboLinks isn’t the only disruptive technology included with Rails 5.

ActionCable is a brand new feature in Ruby on Rails 5 that provides easy use of web sockets which allows the server to send messages to open browser sessions. WebSockets has been popular in features such as chat rooms which we required instant updates. Web browsers implement WebSockets in different ways which make it difficult to create your own custom solutions. ActionCable takes care of these details and allows you to focus on the actual messaging. ActionCable, although disruptive, will most likely not elicit controversy as TurboLinks has done. ActionCable can used as more of a tool rather than a design pattern affect your software’s architecture. There are Rails classes on the both JavaScript and Ruby sides which do influence the application’s design to a certain degree, but those classes can be encapsulated if wanted your software architecture to unaffected by ActionCable. You are, however, tied to the Rails framework with ActionCable, but that’s not anything new in Rails.

So do these new additions change the direction of Rails? For good or bad? The philosophy of Rails has remained the same. It still aims to provide a quick and easy way of developing new web applications. The culture is quite moving, as DHH proclaimed you can take Rails and “as one person, can have fighting chance”. Critics will be quick to point out that while Rails greatly enhances the speed of development of new applications, it starts to fall apart when used to build more complex and larger applications. That may be true following the architectural principles that permeates Rails, but it is quite possible to use the good time-saving parts of Rails with your own custom architecture. It won’t be an uneventful marriage, but it’ll allow you to increase your ROI in the early and later stages of your application.

Should a Startup Use Ruby on Rails?

At CabForward, we recommend using Ruby on Rails for the development of a web app. It is particularly effective at building what most folks in the startup world refer to as a Minimum Viable Product (MVP). We see an MVP as version 1.0 of a product, which is different than a proof of concept. A proof of concept, in our opinion, is something you know you are going to rebuild. But an MVP should be built carefully, with the future in mind and using technologies and architecture that will grow and scale with you. We have seen the wrong technology decision early on in the life of a startup, either cripple or completely destroy momentum in the later, more critical phases of a fledgling company. The Rails framework gives startups and enterprises alike the ability to build a product quickly and to change that product down the road as the needs of the business evolve. This is a powerful value proposition and one that positions Rails as an excellent platform to protect your investment from a very disruptive and tumultuous business landscape.

CabForward℠ is an Open Source Developer

CabForward is Ruby On Rails in Austin, and one of the leading mobile custom programming companies in Central Texas. We use Ruby On Rails because it is an open source platform which is optimized for programmer happiness and sustainable productivity. It’s our favorite because it lets us write software that doesn’t suck. 

Why? Because our Geeks Care. 

Let us know how we can help.

To take a look at some of the projects we have completed in recent months, check out our portfolio page.