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!
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.
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.
Boiling the frog
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