Why Rails?

Over the years, I’ve tried to dabble in a new framework and/or language once per year. I find that learning how other languages/frameworks approach problems lends insight to how my tooling works.

For example, JavaScript’s Event Loop practically encourages an Event-driven architecture, which is at the core of many micro-services architectures. Emit and event, and allow many subscribers to register against that event. It’s an approach that leads to a plugable architecture, which can be applied internally with only JavaScript.

So why have I latched onto Rails? What about Rails makes me willing to bet the farm on it? The main item which stands out is interoperability. Sane defaults for how to quickly get building. This is a part of being an “Opinionated Framework”. Rails is composed of many smaller components, each designed to work together, and battle-tested in apps around the world.

As an anti-pattern, take the Express framework. Express is a great HTTP framework for routing HTTP requests. It is not, however, an opinionated framework. This means that if you want an ORM, you can evaluate various ORM’s, decide how reliable the projects are, and then try to find documentation for how to integrate with Express. There are other frameworks (such as Feathers) which are opinionated, but raise other concerns like dependency tree depth (your project depends on Feathers, depends on Express, depends on 48 other packages). How reliable are all of those projects? But Express is also incredibly light, fast, and salable.

Is Rails immune from this deep dependency tree? Absolutely not. Rails 7.0.1 ships with 55 third-party dependencies. That is a lot of dependencies, but those encompass all of the functionality required for many web apps, until you start integrating with other API’s.

There are other full-featured, opinionated, frameworks out there. Probably the most widely known is ASP.NET MVC. Not quite as fully-features as Rails, but close.

Why do I consider an opinionated framework good? I spent 18 years working in a “framework” called [HTMLMason](https://metacpan.org/pod/HTMLMason) which had no opinions on how to develop an application. Choose your ORM, choose your session management and storage, choose, choose, choose, choose. Each of these choices imposes a limit; less documentation for your specific stack, less help when things go wrong, smaller talent pool when you want to expand your team. When working this job, almost half of my time was spent struggling with integrating various Perl modules, rather than implementing the features the business could turn into revenue.

Conclusion

So, again, why Rails? I’ve seen streamers and other developers struggle with things I consider simple in Rails. I’ve seen JavaScript developers dance around adding a database because of the complexities, or implement templates twice, in both server and client code, to facilitate SEO. Heck, just setting up asset bundling is a chore in many frameworks. Rails’ sane defaults allow me to be productive more quickly than any other framework I’ve worked with.

“So I should use Rails for everything?” Heck no! Rails is bulky, since it ships with everything. If you’re building just an API, Rails ships with an API-only mode, but other frameworks may be a better fit. If you’re building console apps or Cloud-Native tech, where shipping code, shipping containers, performance, and scaling to the moon are your concerns, other languages may be more appropriate

But if you’re trying to build a rock-solid web app on the quick, Rails should probably be on your radar.