Live data from Hacker News

Returning to Rails in 2026

markround.com

161–170 of 254 posts

Re: Returning to Rails in 2026

#161

Earlier quoted context omitted.

And most folks getting stuff done with Rails ain't be filling out surveys to boost their stack - or maybe that's just me. So everyone just stop worrying what everyone else thinks or seems to think and just use the right tools for you and get on with it

There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)

There are two types of dichotomy: those which are autoreferring and sound, those which are absurd, and those which are really going too far.

Re: Returning to Rails in 2026

#162
Ruby and RoR is cool and all, but as these web apps got more and more complex, the need for static types became too important. What gave PHP it's edge was types and is the reason I'm still using it after nearly 20 years. PHP seems to implement those important things just in time. OOP, better OOP, types, speed boost, and next probably concurrency.

Re: Returning to Rails in 2026

#163

We've been running Rails apps in production continuously since 2007. If you treat software as anything other than completely disposable, it's been a no-brainer for the entire 19+ years I've been paying attention (not despite its age, but because of it). The premise that you get meaningful efficiencies from JavaScript on the back-end just because you have to use it on the front-end has been pretty thoroughly debunked…

> Does anyone think NPM's 3.1 million packages enable more functionality than RubyGems' 190,000 packages?

It means that there are many more people using NPM.

That means more users. More users is almost always better, for any language.

Also many of those gems on rubygems are dead since decades, literally. Probably also for NPM. We can not just compare the numbers without analysis.

Re: Returning to Rails in 2026

#164
and security.

ideally a JS frontend app won't show logic not intended for the user type in question.

in practice, really often I see a huge app covering all roles and cases, a trove of info for the red team. and even worse, the reality of software development with LLMs in 2026 is plenty of code is being shipped without security audit.

I know it's not an inherent fault of the JS frameworks. bit I share what I see on the streets, most of custom JS apps I see are way more vulnerable to hacking than a old-style MVC app.

yes it is possible to make mistakes in both styles, but in JS apps I probably see 400% more easily discovered vulnerabilities than in a common MVC (even with stimulus) app

Re: Returning to Rails in 2026

#165
post #111

Earlier quoted context omitted.

We've also been running Rails in production for 15+ years (since 2011) in two companies and it has been serving us greatly. Hiring is tough, but I definitely believe the stack makes up for it due to the productivity gains. In late 2025 we decided to migrate one of them to Inertia. Public facing pages is already done, and we're 80% through migrating the logged in area (it's a huge app). We choose Vue.js. It's amazing…

I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)

> Maybe not?

Because there are fewer and fewer ruby/rails people available.

It is the simplest explanation - and the one that makes the most sense, too.

Re: Returning to Rails in 2026

#166
I was part of building the streaming frontend for one of Sweden's largest broadcasters in Rails about 10 years ago. Handled 1M+ concurrent users on Heroku with horizontal scaling. Fun fact: someone on the team literally stayed up monitoring traffic during big live events. It worked. Rails was a great fit for that especially at the time.

I moved on, not because Rails failed me, but because the things I started building next (Streaming infra, APIs behind proxies, lots of concurrent HTTP work, infrastructure tooling, AI/ML) just fit better in other languages. I pick tools by the problem, not loyalty.

What I notice in this thread is a lot of "Rails vs X" framing when the real answer is boring: use Rails (if you like the vision and Ruby) when the complexity is in the data model and business logic. Use something else when it's in concurrency or infrastructure. The one-person-framework pitch is real, but it's for a specific shape of problem.

Also: God i miss writing Ruby, its a fantastically and beautiful language.

Also: Blast from the past: Ruby is a great DSL for Rails.

Re: Returning to Rails in 2026

#167

Earlier quoted context omitted.

I'm surprised hiring is tough. The job market is such trash rn and I feel there are a lot of Rubyists, or ex-Rubists interested in returning to it, around. Maybe not? (Edit: spelling)

> Maybe not? Because there are fewer and fewer ruby/rails people available. It is the simplest explanation - and the one that makes the most sense, too.

Well ya, I'm just saying I'm surprised considering the current job market. I moved on from Rails about 5 years ago now, but have 9 years experience under my belt and still keep up a bit with new things and play with them once in a while. And yet I've applied for several Rails positions in the past few years and always get an outright rejection.

Re: Returning to Rails in 2026

#169

I love Rails, but after working for a few places with huge Rails codebases and then several other places with .NET and other frameworks with actual typing, I just can't go back to Rails for anything that isn't a personal project. Working with a large codebase with an untyped codebase is just a nightmare, even with powerful IDEs like RubyMine that are able to cover some of the paint points. I wonder how good Sorbet is…

What is it about large untyped codebases that make it a nightmare?

Re: Returning to Rails in 2026

#170
Nothing wrong with Rails in 2026. We still use it for both internal and customer projects. I haven't yet encountered anything that made me feel like switching. I'm also not interested in changing frameworks just to have the New Hotness die in 2-5 years (our oldest currently maintained Rails project is over 10 years old, and some stuff I started working on when Rails 2 was new is still being maintained, just not by us)
Post reply on HN