Probably the best framework in the world

Evaluating choices for a technological stack for your new project is usually a daunting task. Most of us will probably resort to a Google search for “should I use X” and if you put “Rails” in the equation you’ll probably get a lot of people saying that „Rails is dead/deprecated/old” and so on. This might especially show up in discussions regarding insert-the-latest-fad-in-web-development-here. It’s true that Rails is old. 15 years is a long time in technology and here, at Applover we’d like to argue that Rails is definitely not dead yet. We’d like to go even further and claim that Ruby on Rails is an excellent choice for your next big thing in 2021.

The curse of choice

Most web applications will have 3 major moving parts: backend, frontend, and the database. It’s simple, just pick Spring, Express, Flask, Sinatra, or any other simple library and start coding. Except it doesn’t work that way at all. Any of those libraries will have you make a lot of decisions.

Some questions about Ruby on Rails you will have to answer might have something to do with the frontend:

  • How do we route URLs to controller actions?
  • How do we generate responses?
  • Do we use JSON:API?
  • Do we parse incoming payloads?

Some questions will involve security:

  • Do we use JWT for authentication and authorization?
  • How do we mitigate common security vulnerabilities like XSS, SQL injection, etc.?

Another set of questions will come up when dealing with the database:

  • How to access the database? Which library should you use to do that?
  • How to manage the database schema?
  • What’s the naming convention for database tables?

And we have more problems to solve when regarding developer tooling:

  • How do we get new developers up-and-running quickly?
  • Can we actually do that?
  • How do we manage dependencies?
  • What debugging tools are available?
  • Are they good?
  • How do we write tests?
  • How do we manage test data?

Every project relying on libraries instead of frameworks will have to make those calls at the beginning, sometimes even before anyone can start working on the project. All of this decision-making is really taxing, and it’s something you can avoid (we’ll get to that). We can assure you that’s just the tip of the iceberg. We are yet to encounter our greatest challenge – time itself.

The passage of time

Not everything stays the same for a long time, especially in programming. Once you have picked your tools, it’s time to glue them together. This will, of course, take time. More time passes and you have made some progress, maybe even shipped off a successful MVP. Your project is working but your GitLab or GitHub CI tells you that your dependencies have security vulnerabilities. So you do what must be done and upgrade. Much to your dismay, you discover some of your hand-picked libraries are incompatible with each other or their dependencies have version requirements that don’t overlap. You find yourself caught between a rock and a hard place.

Another thing that might change in time is your team composition. Some people leave for what they perceive as greener pastures and new developers join your ranks. They will have to be onboarded carefully and will understand the conventions established in the project. Developers are usually curious so they might want to know why we configured a certain library in a certain way. They will also want to know if we can change that. This is not a bad thing per se but it adds to the total complexity of your project which will grow in time and will consume even more time.

Less is more

Ruby on Rails takes the burden of decision-making off your shoulders the moment you type in rails new in the terminal. Most of the aforementioned questions are answered and the appropriate decisions are made. This does not mean you will not have to make any decision, but most of the plumbing has already been done for you so you can focus on what’s truly important – the problem you are trying to solve and its domain. „Optimize for programmer happiness” is the first pillar of The Rails Doctrine. In the past 15 years, Ruby on Rails and its community had ample time to mature, improve and keep moving forward. It also had ample time to build trust with developers and investor alike by breathing life into big-name products like MyFitnessPal, Airbnb, Kickstarter, Basecamp, Dribble, Goodreads, GitHub, GitLab, Fiverr, COOKPAD, Couchsurfing, Zendesk and probably thousands of other projects you might have never heard of. All of this happened despite people saying that “Rails doesn’t scale” or “Rails can’t be used for serious problems”.

Having worked with Ruby on Rails for the past few years, I have been proven that this framework enables developers to focus on delivering the project's business value rather than spending plenty of time on configuration overhead and low-level technical details. It's almost effortless to kick-off the project and then iteratively implement features in an agile manner.

Zuzia Kusznir

Back-end Developer

Back to the passage of time

Shipping your product is only the beginning. With time, source code can also accumulate cruft. It should be obvious that there’s no framework and/or library that can make the code maintainable in the long run but looking at Rails’ continued existence we are sure that it gives you the best chance at producing maintainable code

The ecosystem usually evolves with the new Rails version so you can expect the last stable version to work for years to come and upgrading to the next version is usually a well-trodden path.


Do you want to find out more about Ruby on Rails development?

Talk to our team!

Another thing that comes to mind when talking about maintaining a Ruby on Rails application is the second pillar of The Rails Doctrine – „Convention over Configuration”. Being rooted in convention means that there are fewer places where things can go off… the rails. Of course, the core conventions made up by the Rails team will not fit all use cases but it doesn’t prevent your developers from coming up with their own conventions and capitalizing on them. This would be the case in any other team as well.

Consider also the benefits of the business side when thinking about betting on Ruby on Rails in 2021.

Thanks to intuitive, simple and readable syntax resulting in much higher productivity alongside with fast prototyping and scalability, Ruby has been a great fit for both developers and companies who would like to deliver their software faster and adapt to market needs easily with reasonable costs.

Piotr Sobusiak


Is Ruby on Rails the silver bullet?

No technology is. But if you need to create something quickly and retain the ability to iterate and improve on it then Rails is still very much a solid choice. I hope that after reading this article, it is clear that Rails can be used to deliver quality software used by millions of people. We’re doing our part to prove it by creating projects for e-commerce, HR services and Insurance Fintech. At Applover, we think that choosing Rails allows developers to start thinking about the problems they need to solve instead of wasting time on plumbing. And that’s what makes Ruby on Rails still the best choice, even in 2021.