Hacker News Reader

Comment by mattgreenrocks | Hacker News Reader

Other ecosystems usually do not have problems to the extent the author had.

I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue. Reviving a medium-size project after 4 or more years usually means I have to catch up on a lot of new surprising deprecations. That's not because there's anything wrong with Python; it's more of an economic issue: the authors of active libraries have little or no economic incentive to support old, deprecated versions, so they just don't. That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.

> That's life in the modern world. It is a deep problem that should theoretically affect every large software ecosystem because very few library authors can predict the future with great accuracy, and very few open source library authors have any significant incentive to support old ideas.

I disagree. This is an easy problem to avoid with minimal due diligence, people just choose convenience and make unnecessary tradeoffs.

* Use the standard library (ironically not available for Node projects). It will be built with better backwards compatibility almost every time. What deprecations do occur will likely be VERY WELL documented with much quicker adaptions.

* Limit third party dependencies. Do you really need an ORM for your apps 40 sql queries? How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM? 1 hour? 5 hours? 20 hours?

* Pick technologies with better track records. Maybe don't use Beta software like Swift Data for your iOS App. Maybe choose golang for your API even though it'll take a little bit longer to build it.

And this is how you end up with rewriting the world and spending more time rewriting dozens of existing libraries to avoid adding them as dependencies and less time working on the problem you're actually trying to solve because you're fixing the same dozen bugs that the first person already went through the trouble of fixing for you had you simply used their library instead of eschewing it and having to learn everything that they had already learned for you. Often times because the problem space is deeper than you could have known before getting into the weeds and hopefully you don't get bit by sunk cost and decide to do yourself a favor and just use a library instead of continuing to work on solving problems that aren't related to what you set out to do.

There's a balance to be struck between LeftPad scenarios and "Now there are 37 competing libraries".

Exactly. The right thing to do is study each dependency and decide whether the reward of having the problem solved quickly is worth the many risks of adding dependencies.

I'll acknowledge here that there seems to be a significant difference between Python projects and Node projects: in my experience, a small Python project has a handful of dependencies and maybe a dozen sub-dependencies, while a small Node project usually has a handful of dependencies and a few hundred sub-dependencies. That's where Python's "batteries included" motto does seem to help.

> There's a balance to be struck between LeftPad scenarios and "Now there are 37 competing libraries".

I think we're actually in agreement. My assertion is that for projects which want to avoid constant maintenance, particularly small projects, you can make architectural decisions some of which could significantly improve the maintenance outcome. Of course there are trade-offs to those, and if you make the wrong architectural decisions it can cause more harm than good.

Maybe I'm glib for calling it "easy" but for many leftpad scenarios it really is a "holy crap why did you think that was ok" scenario in my experience. Lets avoid those scenarios when we can.

> How long would it take you to scaffold it with GenerativeAI then make it production-worthy without the ORM?

Having a machine do codegen to map your queries to objects is still an ORM, except now it's nondeterministic and not updateable.

(mind you, I come from C# where you simply use LINQ+EF without worry, or occasionally Dapper for smaller cases)

> Use the standard library (ironically not available for Node projects)

???

Node.js has an extensive stdlib [1].

Contrast that with Python which practically requires a 3rd party HTTP client.

Or Java that doesn't even have JSON support.

[1] https://github.com/nodejs/node/tree/main/lib

> That's not because there's anything wrong with Python

It's absolutely because there's something wrong with Python, the package management, and also the type safety. JVM languages haven't had these problems for 20+ years.

> I am deep in the Python ecosystem, and I love Python, but I have to admit that Python has the same issue.

The same problem in Python is much easier now because you can ask the uv resolver to limit itself to some earlier point in time.

You can do `uv pip install --editable . --exclude-newer=2022-01-01` and you will end up with a resolution from two years ago. Since uv can also install older python versions automatically you can easily bisect you to a newer point.

Will uv even be around in 4+ years? No idea.

I don't know either, but think even if it's not, whatever will replace it, will at least have to achieve feature parity.

Maybe they can try to get the node version into the package-lock tomorrow? This seems like an opportunity to improve the ecosystem, rather than a biting critique.

Or, instead of responding to sunk costs by getting sunk deeper into the muck, just cut your losses, ditch Node and its proprietary/non-standard APIs and unstable featureset, and use a standard runtime.

The author of the blog post is trying to run a static site generator. A static site generator doesn't need to be able to do anything that Node provides that can't be done with the World Wide Wruntime (which they're already going to use to verify the correctness of the SSG output). So use that runtime and tools that target it, not Node.

Fact: NodeJS's never-standardized APIs that change from release to release are a source of non-negligile breakage and churn for JS programmers who make the mistake of entrusting it to run their programs.

Fact: for a great many programs, NodeJS isn't even necessary to provide the operations that a given program needs in order to do its work, because there exist standardized, vendor-neutral, cross-platform, stable APIs, with broad sort by such companies as Apple, Google, Microsoft, Mozilla, etc.

Fact: the runtimes that support these APIs are already pre-installed on virtually every desktop and laptop computer.

Fact: you could write a static site generator targeting these APIs today and get a working program today and that will continue to work indefinitely, due to these vendors' commitment to backwards compatibility.

Reply on news.ycombinator.com