I may not use Ruby on Rails on new projects again. Because of this dramatic Pull Request on Turbo: https://github.com/hotwired/turbo/pull/971

Why?

I’m seeing no legitimate processes of this “breaking change” of this library used by thousands of developers. The maintainers showed no respect for others’ inputs.

Thinking about this:

1. They are making a big announcement during the night time.

2. The whole PR description is just the link to that announcement.

3. Not willing to listen at all.

I’m totally fine with maintainers with strong opinions. However, those who pretend to be benevolent dictators are not to my liking.

If you’d like to continue to read, let me double down their internal inconsistency here.

Recently, the Rework Podcast published two episodes about writing pitches. Though the maintenance of Ruby on Rails is not about internal company affairs, their action to get rid of TypeScript is going straightly against their sprint of pitching ideas.

@dhh mentioned this,

We write all our client side code at 37signals now in pure JavaScript and the same too with any internal libraries. This is going to bring that in line.

This means nothing.

First of all, the maintainers of Ruby on Rails should listen. Being the creator of this project does not mean they can make every decision right. Rushing to merge this project only looks doggy.

Secondly, doing this inside 37signals does not mean that every Rails user should follow. Shopify and Stripe created their static analyzer for large-scale Ruby projects (Sorbet: Stripe’s type checker for Ruby and The State of Ruby Static Typing at Shopify). This is a strong proof that strong typing would help teams to scale.

A common argument from 37signals would be like “They may argue: why don’t you keep the team small? So that you don’t need strong typing?”

To be short, we don’t want the typing thing to be a bottleneck of the team size. We would keep our team small because the business does not require so many people, like being in a niche market. The inability to make code interfaces right should never be the reason to keep our teams small.

I do expect people can still succeed with Ruby on Rails. But for me, life is short, I don’t want to waste my time on fixing bugs that can be prevented by typing. I’ve spent hundreds of hours on this and that generated zero business values.

Ruby on Rails used to be the go-to for rapid project scaling, but times have changed.

In 2023, options like FastAPI offer incredible flexibility, including auto-generated frontend code, making Rails no longer a necessity for fast iteration.

Let’s keep an open mind, especially in the world of open source projects.