Before Ruby on Rails (or Rails) and before MVC, getting and posting data from a SQL database required creating a function that passed strings into the connection, binding the results to a callback function, and then finally returning the results. The act of sending a string through felt icky and wrong — dirty, even. A typo would throw an error, not to mention the fact that you’re basically writing code in two different languages, for two different paradigms, to achieve one output. The whole process felt incomplete: like it was the rushed effort to solve a problem many developers faced. How do you efficiently connect your app with your data?
Rails uses a model-view-controller (MVC) architectural pattern, which separates the data and logic from the input and output, effectively creating flexible data migrations and a quick development process. But, as one developer notes, “We are stuck in a voice of OOP and inheritance and meta-programming that encourages lazy thinking and lazy software”.¹ Perhaps an opinionated, object-orientated programming language like Ruby or Rails, needs an overhaul.
Rails is old technology
Released in 2004, Ruby on Rails boasts a mature framework. One that is stable, flexible, and easy to read. It is Rails’ English-like syntax that leads to simplicity and ease of use. This was initially what attracted a lot of developers, but after more than a decade of evolution, it’s what’s turning them away.
The ambiguous, english-like syntax of ruby that makes rails so easy, is exactly why it’s not simple.¹
The illusion of “ease-of-use” is hidden in layers upon abstracted layers, making debugging a difficult task. So difficult, in-fact, that Ruby on Rails ships with an inline debugging helper, which is itself a task to decode, especially for beginners. Developers with more Rails experience will find solace in the fact that Ruby is at a point of maturity that not many languages or frameworks have reached. Again, its greatest strength is also its greatest weakness.
Worse, with maturity comes the risk of stagnation. The ruby community, namely the creation and use of gems, is nowhere near the behemoth that is NPM, and now that NPM has merged with GitHub², they will only continue to grow.
RubyGems currently has a total of more than 55.6 billion gem downloads.
NPM has an average of about 88 billion package downloads — per month.
Some might consider the slow creation of new, or even well-used gems, as one of the reasons that Rails continues its steady decline. Although it’s proven to be a reliable technology, it struggles with the performance in enterprise applications. Scaling has always been Rails’ weakest trait.
For at least a couple of years now Ruby is no longer exciting. And it doesn’t have to be — in the long run I don’t expect programming languages to be exciting, I want them to be mature, stable, and reliable. And that’s how I see Ruby in 2019. Every year there are fewer areas in which I need to turn to languages other than Ruby. It’s not and I doubt it will ever be a true “enterprise” technology, but when you need to move fast and be flexible — Ruby will remain a great choice for the coming years.
Filip Tepper, Senior Engineer, Castle Intelligence
Rails enables fast, consistent development
Yet, Ruby and Rails is still a very popular framework. Ruby’s creator, “Matz” even has plans for what Ruby will look like in the next 25 years, so his intention is that support will be around for quite some time. Some of the biggest and most influential companies have switched to Rails. GitHub recently converted all of their code to Rails — an endeavour that spanned years. GitHub’s competitor, GitLab also wrote their code in Rails, citing how “the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality… Because there’s all these best practices that are on your happy path, it’s also a way to keep the code consistent when you ship something like GitLab. You’re kind of guided into doing the right thing”.³
A framework like Rails provides the flexibility to iterate over your code, which allows a developer to easily add features or make incremental improvements to the app. All while keeping the code tight, the conventions consistent, and the app performant.
“Ruby was optimized for the developer, not for running it in production,” says Sid, CEO of GitLab. And therein lies the heart of Rails: wielded in the hands of an experienced developer, Rails can be a powerhouse of a framework. As with all frameworks, languages, or paradigms, Rails has its strengths and weaknesses (scalability being one of the largest weaknesses of Rails); but where and when it’s strongest, it drastically outpaces the competition. E-Commerce giant Shopify, for example, chose to use Rails for its ease of development.
Based upon the model-view-controller paradigm, Rails splits responsibilities of tasks down to input, routing, logic, and output. Utilizing database models, a quick query can easily be transitioned into a partial to be output to the user. And with data migrations, updating or making changes to that database is both quick and reversible.
One of Rails’ key benefits is in developing sophisticated applications quickly. Not many frameworks can test Rails’ speed and stability, and with 25 more years of support from both the creators of Ruby and Rails, developers should expect more use and more scalability.
What’s in the future for rails?
The latest version of Ruby on Rails, version 6.0, was released only a month and a half ago, with new patches and pulls happening everyday, and with Ruby’s new “version 3x3” expected to be released later this year, developers can rest easy knowing that their favourite framework is still alive and well.
Two new Rails features that shipped with v6 are ActionMailbox and ActionText:
- ActionMailbox provides tools that allow applications to integrate with email in new, progressive ways. Emails can be interchanged between platforms, and can automatically be turned into tickets or database requests.
- ActionText integrates Basecamp’s (the founder of Ruby on Rails) text-editor, Trix, and utilizes rich text editing online.
Whether it’s functional programming or opinionated object-oriented programming, developers want fast, flexible, and powerful frameworks. The continued evolution of Ruby and Rails ensures we’re on the right path each step of the way.
Still, there may be a better way.
Perhaps thought leaders and hero-developers need to step away from popular frameworks for a minute and critically assess the state of programming languages. Rather than continued iteration, maybe it’s time for a new paradigm — a new way to program. One that doesn’t feel overly opinionated, but still feels human.