In spring 2019 the version 6.0 will arrive. It triggered a reflection on the direction of Rails. The sixth version is on the horizon with changes that are exciting but also safe for business – a lot has changed since version 1.0. Version 1.0 was released in December 2005. The Rails core team is aligned with the business needs on the market better than ever. What does it mean in practice and what does it mean for the future of creating digital products?
Ruby on Rails development - some history. How did the revolution start
December 13, 2005, version 1.0 of the Rails framework was released by DHH (David Heinemeier Hansson). It was a breakthrough – the approach to web development became totally different than before thanks to Ruby’s features. RoR praised Convention over Configuration, which means that you don’t have to write dozens of configuration files. Instead of spending hours on configuration, you just rely on a convention – both naming and directorys structure have to be specific – it saves a lot of time and works really well
Ruby on Rails development - a little bit of magic
At Netguru, we run workshops for Rails beginners. I mentored there a few times, and one of the most frequently used words (in the context of Rails itself) was “magic”. This way of handling things is not something that you expect as a developer, but after realizing how fast you can move and break things, it’s really astonishing how quickly things can be created. For example, you just need to type “rails generate” in your terminal and all necessary elements are quickly generated. You just need to put additional logic if it’s needed – something that can’t be done with merely a template. It relies heavily on established conventions, for example, you create a file representing a model or a controller inside a dedicated directory, and the framework will know what it can expect there. You don’t need to create any additional entries inside the configuration saying that model X is stored here, controller Y is placed there, etc. After some time, you just get used to conventions and the magic disappears. But, of course, the speed of developments remains the same.
Breaking the Status Quo
Thanks to Rails, we’ve seen dozens of web frameworks trying to imitate RoR conventions and solutions. I’d say that this small revolution broke away from the Ruby ecosystem itself and spilt to other languages. Established and working conventions have been reused by other popular languages such as PHP and Python – the frameworks just needed to be adjusted for the given language. It’s safe to say that the Ruby implementation is the most-magical because of Ruby’s features. It’s a really dynamic language that helps to produce working code a bit faster. Today, the speed of development is similar, it’s just a matter of language preferences.
When Rails began to become more and more popular with its 1.0 version, the digital world was totally different than today – most of the Internet was running on PHP. Websites those days were based on not-so-good-looking tables, with non-matching colors, and dramatically bad user experience. Facebook had just started, and we had only begun to use Gmail’s first version . The speed of development in Rails was much faster than anything that preceded it, which was a huge thing. That’s why so many coders tired of PHP tried RoR. Even here at Netguru – it may not be a well-known fact – the first projects were also written in PHP.
Wasn't perfect at the beginning and updates were hard (especially connected with Ruby, like 1.8 to 1.9 migration. Most major version changes required a lot of work. For example, at some point, Rails creators totally changed their mind about the way incoming data was to be fetched from users. Each parameter passed from the browser had to be whitelisted so that we could be sure it was safe. The check has been moved from models to controllers. Changes like that one appeared because, Rails creators looked for better approaches. Those changes had huge implications for updates, but, at the same time, they changes had to be introduced to solve problems better in the future.
Rails creators noticed it and from version 5, we are able to build API only apps, which means that we deliver only the backend part, which is invisible to the user, and the frontend is a completely separate app (of course, it was possible earlier but without the support from built-in generators). The popularity of chatbots brought about some sockets features. Creating a chatbot in Rails 5 become much easier than before. Since version 5, we can also store assets, such as images and videos, directly in the cloud using dedicated solution inside Rails (ActiveStorage).
As core features are established and battle-tested, the Rails team delivers regular security updates too. We can clearly see that the changes in the framework are aligned to what happens on the web development market.
Ruby on Rails: Business Direction and the Future
The Recently released RoR versions mimic the current market trends, focusing on the capability for building only APIs, abd introducing sockets, cloud uploads, or better handling emails with no breaking changes. More importantly, updating from previous versions should now be really painless, which is a good indicator of the framework’s maturity.
For developers and application maintainers, it’s great to switch to a higher version without any additional work required. It is great news for businesses based on the Rails backend. From a business point of view, picking the right framework is a really important decision. I’m happy to conclude that the current state of Rails delivers not just rapid prototyping but also maturity, which wasn’t there a few years ago. So picking Rails for the business means that you won’t need to invest huge amounts of money just to perform updates. It has changed a lot since the beginning of the framework. Of course, the code needs to be maintained and legacy should be handled but updates are not a huge cost anymore.
The Rails core team steer the framework to stable directions, still taking market trends into consideration while planning upcoming releases, assuring security fixes and bugfixes. We have seen it in latest releases. If the market starts adopting API-only backend apps, so does Rails. When we saw a need for integrating more with the cloud or support websockets, Rails releases delivered these features.
It’s also important that the Rails team looks at the popularity of external libraries (gems), and when something gains enough attention it’s transformed into a core feature in Rails. This is a great indicator of the usability of newly added features, because when a gem becomes popular, it also guarantees that the embeded Rails core feature (based on that gem) will be popular. Relying on really useful features that are already heavily in use helps to track what’s really needed inside the framework.
From the application owner’s point of view, Rails guarantees less costly application updates and a great return on investment. Picking Rails right now is an even better choice than a few years ago. The current development and the roadmap for the future can lead to a conclusion that the most important business value that Rails brings up – that is quick prototyping – is still here, and now we can safely assume that the cost of maintenance is lower than ever.
Ruby on Rails is mature framework, our business is safe, and updates to newer versions will go smoothly. The Rails team is aligned with the business needs of the market better than ever. It’s an evolution not a revolution.
With 13+ years on the market, Rails still draws in new developers and encourages them to explore the benefits of convention over configuration.
Since version 1.0, the way the Rails framework understands its users needs has changed a lot. We are sure that the direction is right – the Rails maintainers closely follow the changes in the web development market. Each update is almost painless for businesses and delivers additional values that are aligned with what is going on on the market.