Proudly coupled to Ruby on Rails

For many people in the web world Ruby on Rails is a thing of the past, set aside in the web framework nursing home together with the likes of ASP.NET and JSP. At Happy Scribe though, we are convinced that Ruby on Rails was and is one of the top contributors to the company’s success. Luckily, we aren’t alone. A wide range of companies, big and small, use RoR to serve millions of users every day. Shopify and GitHub are the most known ones, who also give back to the community by pushing the framework forward and spreading the word to get more people onboard.

The highlights

Useful conventions

The Rails Doctrine describes a set of principles that the framework tries to live by. For us, two of them create a winning combination that ensures programmers can focus on what matters and don’t have to spend time making decisions that can be delegated to someone else:

• Convention over Configuration: An example is Rails’ project and file structure. Every new project comes with a trusted MVC pattern. On top of that, it includes a default set of actions (index, show, update, delete, etc.) that cover most use-cases for any webapp. Just name the view and the controller function with the appropriate name and voilà, things just work.

• The menu is omakase: Refers to a set of libraries and technologies that anyone configuring a new Rails project can just install without having to go down a rabbit hole of comparing GitHub stars and commit history to assess different options. For every concern of your application, from connecting to the DB to sending emails, there’s either one default library shipped with the framework or a couple of external ones battle-tested by the community. As a result, most Rails applications have the same stack of core libraries and tools.

Thanks to them, our CTO Marc managed to build the initial version of Happy Scribe in less that 2 weeks when he was still at university and with no real-world programming experience. That same code served as a great foundation for the growth that came in the following months. Six years later, we’re glad to say that we’ve never had to go through the typical startup’s “full rewrite” needed to support the exponential growth post product-market fit. We are quite sure the outcome would’ve been different if Marc had chosen the MERN stack. Just imagine an Express app built by someone that hadn’t learnt all the best practises from a Senior engineer at a mature company.

Productive and fun

Working with Ruby on Rails is an enjoyable experience—most of the times. Thanks to minimal boilerplate and server-side-rendering, creating a new piece of product requires little time. No time is lost deciding on what payload to send down the client and how to store it in the state for rendering. Templates, together with Turbo frames, cover 80% of the product needs. When it comes to implementing live updates, Turbo Streams makes it really simple to push new UI from the server directly to the clients that need it. Finally, for the other 10% of in-client reactivity, Stimulus is there to add the necessary JS sprinkles.

Rails’ simplicity means that at Happy Scribe all engineers are full-stack. This enables us to work on entire features individually, providing us with all the context that empowers us to make product and technical decisions with all the information in mind. All in all, our time as developers is dedicated to the tasks that add value to the product, reducing the amount of lines of code required and abstracting the complexity away, all whilst having fun being productive.

Avoiding trends

Finally, an under appreciated power of RoR is that it removes tempting distractions that engineers love to devote too much time on. In the JS world for example, every other week there’s a new React-based library promising faster render times, or a new server-side runtime that claims to outperform NodeJS by a huge margin. In the Rails ecosystem we can stay focused, and all our “what ifs” can be put towards thinking about how to upgrade to the next major version of the framework.

The infrastructure space hasn’t managed to scape from the hype cycles either. Microservices, container orchestration, multicloud, serverless, you name it. Only recently people have started to wonder if these technologies, designed for organizations with thousands of engineers, made sense in their company. Our main application is a majestic monolith deployed in Heroku. We agree with Daniel, “Microservices were a 0% interest phenomenon”.

The lowlights

Ruby is slow

Many people believe that Ruby is slow and doesn’t scale. We could write a thousand words about how it actually isn't (have a look at the new YJIT compiler) but instead we’ll just say that Happy Scribe spends €1k/mo on Heroku web servers, which is around 0.2% of our revenue. We could decrease that by one order of magnitude if we migrated to a cheaper cloud provider like Hetzner, which is what we did for our media processing infrastructure.

Hard to hire Rails engineers

We have to be honest with ourselves, it’s not Rails hey-day anymore—although that could change in the coming years. Students aren’t learning Ruby on Rails in their free time nor bootcamps are teaching it. In 2024, JavaScript and all its different flavours are king. According to Stack Overflow’s latest Developer Survey, around 40% of the respondents selected Node.js and/or React as their go-to technologies, compared to only 5% choosing Ruby on Rails.

These statistics are quite discouraging for anyone trying to hire RoR engineers in 2024. However, there are some good news: RoR can be learnt, and really fast! There is no need to have prior RoR knowledge as a hard-requirement in our job postings. Here’s more: none of the engineers that have worked at Happy Scribe knew RoR before joining the company. Despite that, they all became productive really fast, pushing their first contribution to production in their first handful of days. In 3 to 6 months they are fully immersed into the Rails mindset and writing complex and idiomatic code.

Framework lock-in

There is no denying that Ruby on Rails is a complete web framework, so applications are strongly tied to it. Even if someone wanted to break away from Rails, there is really no alternative for it in the Ruby ecosystem. All in all, the truth is that once you start with RoR you are kind of married to it for life, but we accept that constraint.

Not only that, we consciously reject a pure Hexagonal Architecture. The fact that we could build the same application in Django doesn't mean that we are going to do it. The most likely outcome is that we stay with Rails forever. We don't need to abstract away all Rails just in case we migrate out. If we did, we would lose most of the advantages of using it. We couple strongly and proudly with Rails.

Conclusion

Finally, it is worth mentioning that in the last couple of years the RoR framework and its community have started to see a renaissance. The framework is advancing at an unprecedented speed, keeping up with modern web fundamentals and adapting them to the Rails mindset. Hotwired is a clear example of two new technologies, Turbo and Stimulus, used to bring the interactivity that users expect directly into the framework’s core. These advancements give us even more reasons to believe that the framework will keep serving our and our users’ needs in the future.

At Happy Scribe, Ruby on Rails is more than just a framework, it's a strategic partner in our journey of growth and innovation. Its blend of convention, productivity, and stability makes it an invaluable asset in our tech stack, and we see it staying that way for years to come.