At Simple Thread we have worked with a lot of different languages and stacks. We’ve worked with Ruby, Python, C#, Go, Java, JavaScript, Elixir, Objective-C, PHP, and many more. We believe strongly in using the right tool for the job. One of the tools that we feel like is often a great fit for new applications is Rails, which tends to surprise some software engineers that we interact with.
This topic became top of mind for me recently because there was another post on Hacker News about whether or not Rails was still relevant. It comes up quite frequently, and with good reason. When deciding to build a system, matching up the framework with the goals of the project are critical. Reading through the comments on HN it was, as always, a mixture of comments ranging from “Rails is the greatest of all time!” to “I worked on a Rails app, and it was terrible, Rails is terrible.”
Reading through the comments, most of the support of Rails was centered around a few topics:
- Great for development speed – full stack framework that has an ecosystem of gems that integrate with it directly.
- Ecosystem is big – ton of gems to do almost anything you need.
- Testing is first class – Rails ecosystem has always promoted testing and libraries emphasize it.
- Actively developed – Rails 7 just came out in December of 2021, before that Rails 6 came out in August of 2019.
While I agree with all of those things, these alone would never be enough to keep me in the ecosystem and certainly wouldn’t convince me to join the ecosystem. If there was a newer equivalent to Rails in a more popular ecosystem we would happily explore it and use it where it made sense, but after a lot of searching I don’t think we are there yet. You might be reading that and thinking: “you idiot, there are a ton of modern Rails equivalents in other ecosystems!”
The Four Eras of JavaScript Frameworks
But I don’t think there are, and to demonstrate this, it would be easier to show than to tell. To do so, I wanted to present another article that was also on Hacker News recently – “Four Eras of JavaScript Frameworks”.
I really enjoyed the article, and it nicely laid out the path the JavaScript ecosystem has traveled from the days of jQuery (what about script.aculo.us!?) through Backbone.js, Angular 1, Knockout.js, SproutCore, Ember.js, Meteor.js, React.js, Vue.js, Svelte, Polymer.js, Next.js, Nuxt.js, Remix, SvelteKit, Gatsby, and Astro. However, it didn’t even mention Hapi.js, Koa.js, Sails.js, Aurelia, Derby.js, AdonisJS, Marionette.js, Restify, Feathers, Blitz.js, Mercury.js, Cycle.js, Nest.js, Fastify, Redwood.js, and the dozens and dozens of other frameworks that never really got any traction.
You see where I’m going with this? There is no arguing that the Rails ecosystem is small compared to the JavaScript ecosystem. But the fragmentation within the JavaScript ecosystem on the server side (the client-side has calmed down a decent bit in the last few years) leads us to a situation where making a big bet on an important application using one of the current crop of full-stack JavaScript frameworks like Remix or Redwood feels like a crapshoot. Not because they are bad frameworks, but because we have no idea if they are going to get lasting traction. They seem incredibly promising, but the “best technology” rarely wins. Am I going to need to rewrite this in 2 or 3 years? Who knows?
Dependable, Boring, and Gets the Job Done
Now don’t get me wrong, the JavaScript ecosystem is going through a Cambrian explosion of tools and frameworks right now, and people will eventually figure out what works and things will settle down. But in the meantime lots of frameworks will pop up, get a bit of traction, and then slowly die in the ensuing years. This kind of experimentation and evolution is critical for moving software forward, but at the same time, betting on a particular framework for an important application and then having it die in a couple years is an incredibly costly mistake.
The Rails ecosystem is the exact opposite. Sure there are a few alternative frameworks to Rails, some of them with some great ideas, but there isn’t any real competition in the Ruby space. Every Ruby gem that you want to use is designed explicitly to work with Rails. No fiddling to plug this framework into that framework, or having this framework step on that framework (yes, it happens occasionally, but it is resolved quickly). Gems can count on the fact that you’ll be using ActiveRecord or ActiveJob and because of that can integrate directly into this tooling. For the most part, it all just works, and you can count on things being compatible. As long as Rails exists, it’ll continue to operate that way. The community has no incentives to break things in fundamental ways or go down paths that lead to upheaval.
That last paragraph may have sounded incredibly boring to you, but that is also what a mature software ecosystem that is built around a single tool looks like. For many organizations, applications and software engineers, the primary goal is to pragmatically build lasting software using tools that we know we can depend on.
Everything is About Tradeoffs
It’s critical to keep experimenting, to stay informed on industry trends and new technologies, to never get too complacent. We always strive to evaluate new tools that claim to solve problems in better ways. Choosing Rails or any piece of a solution should always be a decision made by evaluating the needs of the project, not just a lazy default because that’s how we’ve always done things. At the end of the day, you can build most systems in most technologies, with various tradeoffs. Choosing the right tool is about understanding the goals of a project.
For me and most of our clients, delivering working software that lasts is the only goal that matters. To do that, I need tools I can depend on, and there aren’t a ton of tools that I use which have made it into that list.
I can depend on Rails.
What tools can you truly depend on?
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
