4 min read

Rails: not dead yet and ready to be your startup’s BFF

Turns out, the reasons why Rails is loosing the popularity contest and is not catching up with the newest tech-trends, are the same reasons, why it can create you a robust safe space to grow your next gig, without all the noise of the modern web development.

When considering options for your new project, you might be wondering whether Rails is Dead Yet. It is easy to find more popular programming languages than the old Ruby. Why should you bother, then?

Turns out, the reasons why Rails is loosing the popularity contest and is not catching up with the newest tech-trends, are the same reasons, why it can create you a robust safe space to grow your next gig, without all the noise of the modern web development.

As someone who has worked with various tech stacks and managed teams, I have a unique perspective on the intersection of technology and people. While I certainly don’t claim to be an expert, I believe that my perspectives from both the technical and human sides can provide valuable insights. In this post, we are going to focus on the technology side. Let’s dive in!

Technology

Web development has become significantly more complex over the past decade. What was once a job that could be handled by a single person now requires a team of various functions. Nowadays, it seems necessary to have a backend developer who can implement the API as many micro-services applying Event Driven approach, a frontend developer who can handle all the nuances of the modern Single Page Application, and a cloud engineer who can build a deployment pipeline, create a Kubernetes cluster at the cloud provider of your choice, and make sure all databases, Kafka and Redis are up and running. We want to build for the future!

It might sound like I’m exaggerating, but I think we can all find examples of over-engineering investments that didn’t pay off in our former projects. The reasons behind these approaches were often very valid in the contexts of the original projects that inspired them, but they didn’t always translate well to other projects, which might bleed out of money in meantime. What works for Google, Meta and Netflix most likely is not going to work for you — unless you sleep on an insanely big pile of cash.

Popularity

I jumped on Ruby on Rails wagon in late 2008, as the framework was just about to get very popular and provide relief for many ambitious Java/PHP developers who missed great working ergonomics in their stacks. The selling point was programmers happiness, convention over configuration, and low time to market. It was environment an engineer obsessed with delivering business value could dream of.

The years 2009–2012 I felt most productive as engineer, ever. Delivering was matter of minutes for trivial changes, or couple of days for bigger features. Backend engineers took care of the business logic and information delivery to the browser. The role of a frontend developer leaned more towards the artistic side on the art-engineering scale, whereas it is more heavily weighted towards the engineering side of that scale today. The main “frontend framework” was jQuery and Unobtrusive Javascript (UJS), empowered by JS responses generated by the server. While deploying applications to bare metal did have some drawbacks, it was still an effective solution for many early stage start-ups due to its cost-effectiveness and sufficient performance. We achieved agility with simple architectures, easy to comprehend by a single human being. We embraced The Majestic Monolith.

Boiling the frog

The problem was that jQuery was not Rails — it did not provide guiderails to write maintainable Javascript code. There were many awesome initiatives trying to fix it, even to mimic Rails (i.e. EmberJS). We fall quickly into the trap of embracing frontend frameworks everywhere. Single Page Apps can have certain use cases, but for most of apps we write, they are certainly an overkill. For the majority of use cases there is little benefit of maintaining two routers (frontend and backend), JSON or GraphQL API between your frontend and backend.

The strength of Rails comes from the unity of the frontend and the backend. Reducing its role to a mere JSON API framework killed its competitive advantages. Splitting the frontend and backend created even more needs, such as a typed API and contracts between the JavaScript and Ruby parts. The browser has become a JSON API client that renders screens using various templating engines implemented in JavaScript. This is not what it was meant to be. The purpose of a web browser is to render HTML received from servers.

Another trend that emerged later was the Microservices Architecture, which promised the ability to scale engineering teams to hundreds of developers, which might be tempting. However, the scale of investment is not reflected in the overall velocity. Distributed Architecture comes with a big overhead, such as asynchronous communication and events. Building a core codebase to support these concepts consumed a lot of work-years in too many companies, and the many of them did not live long enough to see the benefits. I would like to suggest that Distributed Architecture hides the problem of rotting standards in smaller organizations. It is easier to suppress collaboration and let smaller groups of people work on smaller codebases, experiment, and align on their own standards. However, the challenge of aligning a couple of dozen engineers to work on a single codebase is not big enough to justify going with the Distributed Architecture and its costs. Also, that potential benefit is, in my opinion, dangerous as it introduces silos in the organization.

We now find ourselves in a world where it is safe to choose J̵a̵v̵a̵, distributed architecture, and single-page applications by default without fear of being fired. However, I do not believe that these are always the best solutions, as many applications do not require such complex infrastructure and engineering efforts.

The alternative approach offered by Ruby on Rails allows smaller teams achieve amazing results in much less time, given they won’t leave the Boring Rails path and won’t get tempted by ideas not fitting their scale. This approach requires some level of self-discipline from senior engineers, but that is the story of the next article.

What start-ups need from the technology?

  • non-enterprise solutions which let developers focus on delivering business value over building fancy architectures
  • framework with concepts graspable by a single individual — too many building blocks quickly becomes unbearable
  • solid guiderails and patterns for common use cases
  • boring framework delivering end-to-end solution — let’s not waste time composing low level bricks