[f311a]

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 would rather use Go with a simple framework, or even without one. With Go, it's so easy just to copy the binary over.

[sebra]

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.

[f311a]

I was talking about total deps, not direct. By installing something like Celery, you get 8-10 extra dependencies that, in turn, can also have extra deps. And yeah, extra deps can conflict with each other as well.

[louiskottmann]

I find the thought daunting but the reality surprisingly easy.

You just keep up as you go, as long as you keep things close to the framework it's fine.

[IshKebab]

> You just keep up as you go

He said "Updating a project that was started 5-6 years ago takes a lot of time."

[WJW]

Yes but GP said "In reality it's not that much".

[bryanlarsen]

Not much work every few months turns into a lot over years, especially if you skip a few of those "every few months" events.

[graemep]

It is easy, and people tend to do what is easy. It takes more effort to minimise dependencies. Your boss or your client will not even notice.

Obviously there are some dependencies that you cannot easily avoid (like the things you mention). On the other hand there is a lot off stuff used that is not that hard to avoid - things like wrappers for REST APIs are often not really necessary.

[vintagedave]

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?

[zelphirkalt]

The issue with that is, that the longer you wait to upgrade dependencies, the more pronounced the problems upgrading it will become generally speaking, because more incompatibilities accumulate. If those 5-6 year old projects were updated every now and then, then the pain to get them updated would be far less. As you point out, security is an aspect too, so you can leave the project inactive, but then you might hit that problem.

[igsomething]

Dependency hell. Usually how it goes is you have to develop a new feature, you find a library or a newer version of the framework that solves the problem but it depends on a version of another library that is incompatible with the one in your project. You update the conflicting dependency and get 3 new conflicts, and when you fix those conflicts you get 5 new conflicts, and repeat.

[vintagedave]

So churn causes more churn.

Also breaking APIs should be regarded very poorly. It isn’t. But it should be.

[comboy]

I agree, but let's say you are looking for a library to solve your problem - you see one repo updated 2 weeks ago and the other one updated 5 years ago - which one do you choose?

[9rx]

That depends. What problem do I have, exactly?

Do I need a library to sort an array? The 5 years ago option is going to be the more likely choice. A library updated 2 weeks ago is highly suspicious.

Do I need a library to provide timezone information? The 2 weeks ago option, unquestionably. The 5 years ago option will now be woefully out of date.

[vintagedave]

Perhaps some kind of ‘this code is still alive’ flag is key. Even just updating the project. Watching issues. Anything showing ‘active but done’.

[stevepike]

The real issue with Rails apps is keeping up with the framework and language versions. There are really two categories of dependencies.

One-off libraries that don't have a runtime dependency on Rails are typically very low-maintenance. You can mostly leave them alone (even a security vulnerability is unlikely to be exploitable for how you're using one of these, as often user input isn't even getting through to them). For instance a gem you install to communicate with the stripe API is not typically going to break when you upgrade Rails. Or adding httparty to make some API requests to other services.

Then there are libraries that are really framework extensions, like devise for authentication or rspec for testing. These are tightly coupled to Rails, sometimes to its private internals, and you get all sorts of nasty compatibility issues when the framework changes. You have to upgrade Rails itself because you really do need to care about security support at that level, even for a relatively small company, so you can end up in a situation where leaving these other dependencies to fester makes upgrading Rails very hard.

(I run a startup that's a software-enabled service to upgrade old Rails apps).

[jmusall]

I think you could only get around this by forcing your whole dependency chain to only add non-breaking security fixes (or backport them for all versions in existence). Otherwise small changes will propagate upwards and snowball into major updates.

[ch4s3]

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

[chrisweekly]

"Security fixes aside" is too dismissive. Transitive dependencies with real CVEs can feel like the tail wagging the dog, but ignore them at your peril.

[ncphillips]

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.

[dalemhurley]

Laravel is extremely stable and consistent.

[itsthecourier]

I have plenty of RoR in production with millions of users, yearly we upgrade the projects and it's fine, not as catastrophic as it sounds, even easier with Opus now

[BeefySwain]

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

[thedanbob]

My experience has been the opposite, especially since Rails has included more batteries over the years. You need fewer non-Rails-default dependencies than ever, and the upgrade process has gotten easier every major version.

[dmix]

Rails is way more stable and mature these days. Keeping up to date is definitely easier. Probably 10x easier than a Node/JS project which will have far more churn.

[Lukas_Skywalker]

I also think it's the opposite, since the dependencies are almost guaranteed to be compatible with each other. And I think Ruby libraries in particular are usually quite stable and maintained for a long time.

[f311a]

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.

[coffeefirst]

It really depends how they were built. I have large Django apps running for a very long time that require minimal maintenance, but it’s because we were very deliberate about dependencies.

But I learned to do that by working on codebases that were the opposite.

[the__alchemist]

Different experience with Django. I am only using a handful of deps. dj-database-url, dj-static, gunicorn, psycopg are the only "mandatory" or conserved one IMO as a baseline.

[__mharrison__]

Use UV for dep management. Make sure you have tests.

In the past month I migrated a 20 year old Python project (2.6, using the pylons library) to modern Python in 2 days. Runs 40-80 times faster too.

[nurettin]

It used to take at least a day of work. In a post-2025/11 world, it is under an hour. Maybe even 15 minutes if you've landed on a high quality LLM session.

[kshahkshah]

Complete opposite of my experience

[nikanj]

In my experience, the magic makes the easy parts easier and the hard parts harder