I like Rails, but here's why I might not reach for it for a new project

I've been using RoR/Ruby for most of my back-end development over the last 5 or so years and I've decided that it will not be something I reach for going forward.

This is less about RoR itself and more about how I'm working and the DX / productivity gains I'm getting out of the TS/Node ecosystem.

Here's a few reasons why:

I write a lot of Typescript

Swapping between Ruby + TS isn't ideal.

When you are trying to build quickly, context-switching is brutal. Even more so when moving between different languages.

I've found myself inserting semicolons into my Ruby and assuming that the last line of my TS functions will return automatically too often.

Since most of the front-end world is Typescript these days, it just makes too much sense to finally bridge the gap and write TS on the back end too.

This is especially true now that I've gotten further into the Node ecosystem and found things that I've taken granted for in RoR like Prisma (e.g Rails migrations), tRPC (e.g ruby-graphql), and BullMQ (e.g sidekiq).

Yes, there's more work to get all of this setup as you lose the opinion of a framework like Rails, but, I find the end result much more flexible and fun to work with.

Vite has really improved my DX

Builds and hot reloads are fast and easy.

The early days of Grunt/Webpack really put me off of the client-side build process and even further when I found myself working on a stack with an Express API + SSR that also used Webpack.

Waiting around for a 10-minute build is no fun, nor had I ever found an E2E hot-reload setup that worked well.

Vite changed all that for me.

Maybe a year ago I moved all of CRA (using Webpack) front-ends to Vite and it was such a painless and immediately beneficial process.

Build times went down, hot-reload was blazing fast, and the configuration was simple and transparent.

I'm addicted to E2E type safety

Compiler and runtime errors for types on the front AND back-end is a game changer for full-stack productivity.

It's funny -- I've spent a lot of time in languages that don't really use typing natively (PHP, Ruby, vanilla JS)...

Since I made the switch to TS, I haven't looked back.

It immediately made my front-end code more readable, predictable, and much less error-prone.

All good things when trying to build quickly and safely.

All glory to the monorepo

Most monorepo tooling is written for TS setups.

While polarizing, I've found monorepos to be a huge productivity and DX boon. Sure, there can be pain points with managing dependencies and wiring up your tooling to work well together, but overall, the decision to build my latest tech stack as a monorepo has paid off.

A lot of the ecosystem around the modern monorepo has its roots in JS/TS and, as such, most of the tooling to help you manage your monorepo assumes your packages and apps are all in JS/TS.

While not impossible, it's definitely a lot easier to get Nx or Turborepo to work well with everything being the same language, especially when you are just trying to build and not worry about maintaining the build.

Maintained gems are getting hard to find

Ruby isn't dead, but, the community is definitely weaker.

This is anecdotal -- it seems that well-maintained gems are hard to come by these days.

I've had to reach for a few gems that have not had contributions in years and even some of the more popular gems are lacking maintainers.

I definitely don't want to discount the work orgs like Shopify and Stripe have done for the ecosystem and Ruby/RoR is definitely not dead in the water. It is, however, not as popular or robust as the Typescript ecosystem is in its current state.

Yeah, NPM sucks and managing dependency versions can be a nightmare.

But I seem to find a well maintained solution more often than not.

Anyway. Pour one out for my usage of RoR. It served me well.