Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Returning to Rails in 2026

markround.com

Post reply on HN
Print view View original

41–50 of 254 posts

Re: Returning to Rails in 2026

#41

Post by BeefySwain »

f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

Does batteries included somehow result in upgrading years old projects being a larger lift? I would think the opposite.

Re: Returning to Rails in 2026

#43

Post by dalemhurley »

neya wrote: post #11

One thing that is not stressed enough, is Rails enforces good code patterns early on. If you follow the docs, you will know where model code should be, helpers should be, controllers should be. After all, it is an MVC framework. However, modern day JS frameworks don't care about this at all. Most of them love flaunting about their raw performance numbers. Security? Fuck that. Not even basic form CSRF protection. A lo…

The difference between JS frameworks and RoR/Laravel is the ecosystem cohesion. RoR and Laravel ecosystems employ the RoR or Laravel way of doing things and everything works together very smoothly.

JS solutions are loosely coupled, lots of good reasons to do so, but comes at a major complexity cost.

Re: Returning to Rails in 2026

#44

Post by apsurd »

fy20 wrote: post #8
hamandcheese wrote: post #3

Earlier quoted context omitted.

> what's the difference if my agent uses fucking Next, Nuxt, Rails or Django? The claim seems quite clear to me: "convention over configuration allows coding agents to be more effective". But yes, I do agree that the main line should say what Ruby on Rails actually is, not why it's good for your agent.

There was a post last week about the best programming language for LLMs, and in the comments people loved Go, with the claim being it's very opinionated and there's really only one way of doing things. I'd say the same is mostly true for Rails apps as well. However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types. For LLMs thats important as well, the more guard rail…

TS is very AI native to the point i'd agree it's near magical in terms of contract.

However, the fact its still the js ecosystem with react, thing is even though it's super productive in churning out the code, there's too many possible ways to do something. it's unwieldy.

For example Claude is obsessed with making react context providers. it'll make tons of them to power every feature. and your app will happily hold 20 layers of russian doll'd state in memory with no way to link to anything.

you have to tell it, no don't do that. i need you to power this thing through the router, through the url. and that has to be designed cohesively. and that's very different from the context free-for-all.

Re: Returning to Rails in 2026

#45

Post by neocron »

rdevilla wrote: post #20
XYen0n wrote: post #18

Earlier quoted context omitted.

I now also believe that at least Active Record is much easier to use than Django's ORM

Doesn't matter when devs just slop out 400 lines of SQL and bypass the ORM. Frameworks and structure will save you from neither stupidity nor ignorance.

If have a different opinion on this, as I think it's 100x better to learn sql and just write it directly instead of using the dozens of leaky abstraction of some framework.

Re: Returning to Rails in 2026

#46

Post by f311a »

BeefySwain wrote: post #41
f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

Does batteries included somehow result in upgrading years old projects being a larger lift? I would think the opposite.

My medium-sized Django projects had close to 100 dependencies, and when you want to update to a new Django version, the majority of them must be updated too.

Thankfully, updating to a new Django version is usually simple. It does not require many code changes.

But finding small bugs after an update is hard, unless you have very good test coverage. New versions of middleware/Django plugins often behave slightly differently, and it's hard to keep track of all the changes when you have so many dependencies.

Re: Returning to Rails in 2026

#47

Post by ch4s3 »

vintagedave wrote: post #39
f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

Sometimes I think the issue here is churn . Security fixes aside, what is it that updated dependencies really give? Can't some of these projects just... stop?

Indeed that’s what a lot of Elixir and Erlang packages do, if it’s done then it’s done.

Re: Returning to Rails in 2026

#48

Post by sebra »

f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

I'm working on a large (at least 300k+ loc) Django code base right now and we have 32 direct dependencies. Mostly stuff like lxml, pillow and pandas. It's very easy to use all the nice Django libs out there but you don't have to.

Re: Returning to Rails in 2026

#49

Post by ncphillips »

f311a wrote: post #37

I love the batteries that RoR or Django gives you, but then I also remember how much time it takes to maintain old projects. Updating a project that was started 5-6 years ago takes a lot of time. Part of that is managing dependencies. For Django, they can easily go above 100. Some of them have to be compiled with specific versions of system libraries. Even Docker does not save you from a lot of problems. Right now, I…

I have not had this experience as badly with Laravel. Their libraries seem much more stable to me. We've gone up 5 major versions of Laravel over the last year and a half and it was pretty simple for each major version.

Re: Returning to Rails in 2026

#50

Post by axelthegerman »

louiskottmann wrote: post #35

I've been a Rails DevOps and nowadays a web one-man-show with it for over 10 years and I'd do it again. Not many frameworks have been thriving that long, and there's good reason. It packs everything, is tidy and productive, with a pleasant language to read and write. In the latest Stackoverflow survey, it's back at the "top 5 of desired stacks to use for next project" over a decade after its inception ! Give it a try…

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

Post reply on HN