9 Reasons Why We Love Ruby on Rails at Loomly 😻

As mentioned in my previous post, I wrote the first line of code of the web application that would eventually become Loomly in August 2015, with Ruby on Rails.

Back then, I would frequently hear arguments as to why Ruby on Rails might not be the right choice and that there were some new options on the table that might be a more suited solution than DHH’s creation to build my project.

Credit

As a pragmatic entrepreneur (pun intended), I am always curious to get some feedback and spot potential pitfalls early on, so I dedicated a significant amount of time to analyzing each argument against using Ruby on Rails, and consistently came to the conclusion that nothing was reasonably “holding” enough to ditch that perfectly decent framework.

I went as far as playing around with other options, from Go to Node.js and even Meteor, and could not find a solution at that time that would fit my need as perfectly as Ruby on Rails.

So, I stuck with Rails 4 and, looking back, I think that decision was one of the wisest I could make, and one that immensely contributed — along, of course, with the support & contribution of outstanding advisors, investors, collaborators & customers— to the fast growth and humble success of our company.

As such, I believe it’s only fair to give credit where credit is due: below I am sharing 9 reasons why we truly love Ruby on Rails at Loomly.

1. Adequacy

Loomly is a Content Management System (CMS), which allows users to upload, view, update and delete information. This is the very definition of a CRUD (Create, Read, Update & Delete) application.

Interestingly, the official Ruby on Rails website defines it as:

“a web-application framework that includes everything needed to create database-backed web applications according to the Model-View-Controller (MVC) architectural pattern”.

As you may know, the MVC architectural pattern lends itself perfectly to CRUD applications, making RoR a great tool for this particular job.

2. Rapid Prototyping

When Noémie & I speak with investors, we consistently hear that most startups at our revenue stage tend to be built by teams of 20 to 40 people. We will be 12 by the end of 2018. At the moment, we are 8. And at the beginning of this year, we were just 4.

One of the aces up our sleeve, which allowed us to build such a feature-rich platform, with such a small engineering team, in such a short time, is Rails. As a framework well versed in programmer happiness and productivity gains, Rails lets us build fast, ship often and, therefore, delight our customers with great responsiveness to their feature and improvement requests.

3. Community

Let’s state the obvious, first.

It is true that Ruby is not the coolest kid around the block anymore, in particular compared to JavaScript, Python & Go, although it still remains quite ahead of Elixir:

See details

And it is correct that Rails may not be as “hip” these days as it used to be in the mid 2000's:

See details

Nevertheless, Ruby on Rails remains one of the most popular web frameworks out there, side-by-side with Django (Python) and way ahead of Node.js (JaveScript), Gin (Go) & Phoenix (Elixir)—at least when it comes to Google trends:

See details

Notes:

1. For accuracy purposes, I had to use the terms “gin framework” & “phoenix framework” rather than “gin” & “phoenix”, which were referring to unrelated topics as well.
2. Joe Chasinga makes an excellent point that “Go was built for the modern web” and as such “has all the built-in tools (…) to accomplish most web programming tasks”. This is the reason why below I will use Go in my analysis rather than Gin.

As I am writing these lines:

• On Stack Overflow, a quick search for the [ruby-on-rails] tag returns more than 298K questions. In comparison, a similar search for the [django], [node.js], [go] & [phoenix-framework] tags respectively returns 182K, 247K, 33K & 3K results.

• On GitHub, there are also close to 238K repositories and more than 3.4K users related to Rails. Again, in comparison, a similar search returns 121K repositories & 1.7K users for Django, 118K repositories and 2.5K users for Node.js, 150K repositories & 2.5K for Go, and 5.8K repositories & 139 users (which seems really off) for Phoenix.

There you have it: the huge, smart & committed community behind Rails is another reason why developing software with this framework is so efficient and enjoyable.

In the early days of Loomly, when I hit an impasse, I just had to reach out to the community through StackOverflow and I would receive help in a matter of minutes.

The open-source community surrounding Ruby and Ruby on Rails is so extraordinary that even these days, when we need to build basic—and sometimes not so basic—components for our system, chances are there is a Gem for that, which we can at the very least leverage (if not use as is) instead of reinventing the wheel.

Oh, and one more thing: beyond online platforms, the IRL Ruby community is just incredible. I met our very first engineer, Ben, through SD Ruby (thanks Etienne & orangewolf), when I was fortunately paired with him during a “hangman” hackathon and thought he was one of the smartest persons I had ever met. I connected with our second engineer, Ari, through LA Ruby (thanks anna & Claudio). I was running into some issues with our invite system and he offered to help: he turned out to be another one of the smartest persons I had ever met.

Needless to say that I am truly grateful to both the Ruby and the Rails communities for (em)powering our company.

4. Scalability

Ok, let’s address the elephant in the room.

Ever since Twitter was said to abandon Ruby on Rails — and finally ditched it — RoR has been unfairly labeled as a framework that “does not scale”, which contributed to slowing down its adoption in the past few years, as new options became available. While it is true that there are languages more scalable than Ruby, it’s also crucial to keep in mind what kind of “scale” we are talking about.

As Carlos A. Becker puts it:

“You probably don’t and probably will never have numbers even close to Twitter’s. You probably don’t have the same problems. The solutions that work for Twitter may not work for your application.”

Now that is perfectly valid.

First, because Twitter has to deal with hundreds of millions of users, while we will probably deal with hundreds of thousands at scale, a couple of million at best.

Second, because Twitter is a social network while we are a SaaS platform: their business model depends on their ability to reach and sustain critical mass, while ours doesn’t, just like Shopify’s and Basecamp’s don’t. Those are two (out of many) extremely successful platforms built with Rails.

In 2016, our user base grew 4,360%. In 2017, it grew 330%. And, so far, in 2018, it grew 161%. Not once, scalability (or lack thereof) got in our way. So, in our specific case, Rails has been wildly scalable and perfectly suited to support our growth.

5. Reliability

Our customers depend on Loomly to publish content on time to third-party platforms, from all around the world, night and day. Most of that content is scheduled in advance by users and handled seamlessly by our application, through our beloved background job processor: Sidekiq (an excellent open-source project written in Ruby by Mike Perham). In other words, the core value proposition of our solution relies on our ability to offer uninterrupted service, with an uptime as close as possible to 100% and a codebase as bug-free as humanly possible.

Since its initial release in 2005, Rails has matured and proven to be well-maintained and stable. Its stability can likely be attributed to the fact that testing has always been a strong pillar of the Rails ecosystem & best practices.

At Loomly, we strive to test our codebase thoroughly, adequately, and cleanly using RSpec as our automated test suite. That, along with continuous integration and delivery practices — thank you CircleCI for making this easy — and our faith in Rails stability, allows us to confidently make changes to production quickly with low regression risk.

6. Evolutivity

Rails is not only getting more reliable with every update, but is also getting more powerful with every release, allowing us to push the envelope and build new things at blazing speed.

To name a few, Rails 5 introduced:

• Turbolinks 5, allowing us through these fantastic iOS and Android wrappers to build hybrid mobile apps by embedding web views from our web app into native “shells” respectively developed in Swift & Java. Not only was this incredibly fast to develop (1 month, 1 engineer), it has also added very little, if any, maintenance and development burden: less app store and review submissions, as well as no need to build and maintain separate features for both iOS and Android.
• Action Cable, which “seamlessly integrates WebSockets with the rest of your Rails application.” While I cannot disclose just yet what we have built with it, I can say, with confidence, that Action Cable is propelling our application to new heights, making the development of real-time features and page updates a breeze.

However we look at it, Rails keeps giving our engineering team an edge, so much so that we are now in a position to race , feature-wise, against competitors 10x—and even 100x—bigger than we are.

7. Compatibility

Rails is already a powerful tool in and of itself.

Blend it with other mighty languages, libraries and tools, and the realm of possibilities becomes virtually endless.

While our application is technically a monolith (for now), following the standard MVC architecture in a single, large codebase, we have been able to supercharge our stack in many interesting ways:

• UI: although we don’t use Rails as a backend API serving an independent, frontend client, we leverage the react_on_rails gem (thanks ShakaCode) and Webpacker to include (and easily integrate) interactive React components in our views.
• Mobile: per the above, leveraging Turbolinks, we built a light iOS app with Swift and a light Android app with Java, serving web views from our Rails app.
• DevOps: the default support for Ruby on Rails from SaaS solutions, such as AWS’s EC2, S3, RDS, Elastic Beanstalk & CloudFront, and CircleCI is great and allows us to take advantage of modern infrastructures and practices in a plug-and-play manner.
• Machine Learning: we are working on a cool predictive analysis engine project, built as a micro service (with Python, Jupyter Notebook, SageMaker). Iterating on that project separately, and integrating it with our main product over an API is extremely easy with Rails.

All this to say that, just because we use Rails, does not mean we can only use Rails. This infinite integration potential with other technologies is yet another reason why we love RoR so much at Loomly.

8. Longevity

As you probably know, Rails had initially been built by the folks at Basecamp for their own needs, before getting extracted as a standalone project and released under the MIT License.

One thing we strongly share with the Basecamp team is the idea of investing in things that last (per their About page):

The best business advice we ever got is from Jeff Bezos from Amazon.com (Jeff bought a small piece of our company in 2006). He told us “Find the things that won’t change in your business and invest heavily in those things.”

We are also in this for the long haul, as we have articulated a pretty ambitious vision for Loomly, which we are extremely determined to accomplish. Although we have absolutely zero intention of flipping the company and selling it on the first occasion, even if we did (again, we do not), we would still need to see pretty far down the road, as it generally takes at least 7 years to go from inception to exit, be it an acquisition or an IPO.

In the context of such a long commitment, betting on a technology which has been around for more than a decade, while constantly evolving, seems like a safe bet. For that reason, too, we love Rails at Loomly.

9. Natural Selection

When we hire new team members, especially on the engineering side, there are five things that we particularly value:

• Experience
• Problem solving
• Productivity
• Humility
• Attention to detail

Being familiar with the Rails Doctrine, we have not been extremely surprised to see that many Rails developers we spoke with were on the same page in terms of conventions, testing & documentation.

One thing that we did find surprising though, is how consistently most of these developers also shared the above five traits.

As if Rails acted as a magnet, strongly appealing to candidates who were naturally a good culture fit for Loomly, while repelling those who were not, very early on in the hiring process.

For making it just a little bit easier on us to build a great team, we sincerely love Rails at Loomly.

Conclusion

If you have made it this far, you have probably understood that the aim of this article was certainly not to claim that Rails was “objectively” the best framework out there.

Actually, I don’t think Ruby on Rails is a panacea or an absolutely superior option that should be used to solve every single problem in the world.

But I do think it’s a robust framework that presents significant upsides when used properly.

For instance, to build Loomly.

And I thought it could be useful for other entrepreneurs to share our experience and explain how one engineering decision shaped the company we are today.

Also in this series:

• Episode 1: How Loomly Was (Really) Born
• Episode 3: What The Job Of A Fast-Growing Startup CEO Actually Is