The most common Rails questions and concerns answered
Rails is the tech stack we recommend at RTS Labs to many of our clients. Rails is a great choice for many projects (we’ve witnessed this firsthand), but we understand you might have questions, especially when comparing Rails to a more widespread language or framework.
We asked our developers to answer some of the most common questions and concerns raised by our clients, along with some reasons why they still choose Rails today.
“Rails isn’t enterprise-y”
Exactly! (Just kidding.)
We think this concern is largely due to a disconnect between most people’s definition of “enterprise.” If you’re a company that values its first-party support contracts and “Five Nines” Uptime SLAs, you probably have a different set of concerns, but that’s not most of our clients – or even most companies.
A lot of the time, we think “enterprise” just means “big.” In these cases, the underlying question is: “Does Rails scale? Can it support a wildly successful, large-scale application like mine?” Simply put, yes!
Over the last 15 years, Rails has grown into a mature, reliable technology stack with a passionate community of developers using and supporting it. And it hasn’t stagnated. It continues to progress and respond to the ever-changing ways in which we build web applications. Thousands of companies have used Rails to successfully build their businesses.
At the high-end, there are plenty of companies using Rails at an astronomical scale (Github, Basecamp, Shopify, to name a few). In the true Rails spirit, they’ve given back a lot of advice and resources to help other businesses that are on the road to scaling in a similar way.
Sometimes “enterprise” means “my business is currently tightly coupled to other enterprise-y solutions,” such as Tableau, Yellowfin, or DB2. This is totally fair and could definitely be a reason to choose something else if the integrations are readily available in a language other than Rails.
On the other hand, we’ve had great success integrating Rails with a wide array of technologies and have yet to hit a problem we couldn’t solve with Rails. For some thorny legacy integrations, we’ve cheated and used JRuby, a version of Ruby that can run on the JVM, but it’s awesome that using Rails affords us that flexibility!
“Where am I going to find Rails developers to take over after RTS Labs?”
Yeeeaaahhh … this is kind of fair, but this is probably more a reflection of how hard it is to find talent – no matter what your tech stack is. (Speaking of which, we’re hiring!) It’s true, there aren’t as many Rails developers as there are for other languages, but the gap is shrinking.
According to the “Stack Overflow Developer Survey,” the percentage of respondents using Ruby has increased by roughly 26% between 2015 and 2018. Ruby is also still in the Top 20 “Most Popular Technologies.” Ruby is consistently topping the “TIOBE Index Top 20” and has been for years. Meanwhile, Rails itself has over 3,500 contributors on Github. To contrast, let’s compare that to some other frameworks you might have heard of:
As you can see, Rails is not bad. There’s still plenty of activity on Stack Overflow, Reddit, at conferences, etc. Sure, Rail’s growth has leveled-off since its peak around 2011, but that was explosive, exponential growth. At this point, Rails is a stable, mature framework. It may no longer be the hot new tech, but that’s a good thing!
“I really need to get something out the door quickly, but then I need to continue building. Getting out the door is just the first step.”
Luckily, this is actually something the web development industry largely agrees on: Rails is great for quickly building a minimum viable product, or MVP. There are a lot of reasons for this – strong conventions, built-in scaffolding tools, and comparatively small amounts of code to get things done. Suffice it to say, you can move quickly on Rails.
Here’s where opinions diverge: A quick internet search will reveal a small number of people who believe that Rails is only good for quick prototypes. We assure you that’s not the case. We’ve briefly mentioned examples of large companies still using Rails today. At RTS Labs, we’ve built lasting applications on top of Rails for our clients. And we know for a fact that the Rails community is actively working to make sure that we and everyone else can continue to do so.
“What’s it going to cost me?”
The proverbial question from clients. Cost-wise, we’d put Rails up against anything! And there’s two big reasons: conventions and feature set.
A core Rails value is this idea of “convention over configuration,” meaning it’s much better to standardize something rather than waste time remaking those decisions from app to app.
What exactly are these “somethings,” you ask? All the insignificant decisions you have to make to develop an application: what do I call my primary key columns, what templating engine should I use, how should I organize the files of my app, how do I manage application secrets – the list is endless. Rails ships with an opinion on nearly every mundane decision you need to make to develop an application, letting us instead focus on the parts of your business and your new app that really matter.
That lets us skip the overhead and jump right into the parts that make your app – and your business – valuable.
“Hey, those sound great! But, out of curiosity, why do you personally like Rails?”
OK, we’ll come clean on this one. No client has actually asked us this question before. We had to throw it in here so we can tell you more about Rails – because we seriously love it so much!
Ruby is an incredibly expressive language, and it makes writing code a joyous experience. Rails gives us readily available solutions for the shared challenges that come with building web applications. Strong conventions make it easier for our developers to move between different Rails projects. It’s also easier to make code readable and self-documenting, which means we spend less time writing our own documentation.
What’s more, we like the community and the culture. In short, the values of the Rails community align with our own. A focus on pragmatic solutions, automated testing, beautiful code, strong conventions, and, above all else, programmer happiness – these are all things that resonate with us.
“So, do you think you can help me build this thing?”
Definitely! (Even if we don’t use Rails!) Time and time again, we’ve been able to help clients realize their business goals using Rails, and everyone won. However, we base the decision on what each individual client needs. If there’s an application you need help building, please get in touch. We’d love to talk with you!
If you’re working on your request for proposal, download our guide for tips.