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

The tragedy of running an old Node project

abdisalan.com

Post reply on HN
Print view View original

71–80 of 412 posts

Re: The tragedy of running an old Node project

#71

Post by Macha »

swatcoder wrote: post #47
abdisalan wrote: post #18

Earlier quoted context omitted.

I’m curious, how do you measure the pulse of a project that old? Do people still talk about it? Or that not even necessary — use it until it breaks and otherwise don’t think about it?

Why do you want your building materials to have a pulse? Ideally, in adopting dependencies, you should be looking for a mature utility whose design was clear and implementation is complete. If it's open source, you should be able to read and unserstand the code yourself, and you should make an earnest effort to do so, in case it has faults you wouldn't usually allow in your own code and in case you need to fork it at…

Something like a HTTP 1.1 client is something you might expect would be a pretty stable thing that doesn't need too many updates, right?

But I would not assume that a HTTP client that has been untouched in 12 years supports SNI, for example, which means that actually it might be totally useless for a lot of modern sites (certainly Android did not support SNI 12 years ago).

Re: The tragedy of running an old Node project

#73

Post by com2kid »

int_19h wrote: post #54
com2kid wrote: post #31

Earlier quoted context omitted.

> But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native. Because the native written stuff breaks all the darn time and it creates cross-plat nightmares. My stress levels are inversely proportional to how many native packages I have to try to get building within a project, be that project in Python, Java, or JS. JS+Node runs on everything. Prepackaged C++ li…

Seamless native builds are quite doable, but the tooling needs to be very deliberately designed around that. For a good example of how far this can be taken, consider https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

I'm a huge Zig fan! Thank you for making native programming fun again! Zig is the exception to native build systems being painful.

But even a great build system doesn't help when old native libraries don't support newer hardware or OSs. At some point the high level -> native abstractions break and then builds break. :(

Re: The tragedy of running an old Node project

#74

Post by hathawsh »

Nadya wrote: post #59
tmpz22 wrote: post #52

Earlier quoted context omitted.

> 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 trad…

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 everyth…

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.

Re: The tragedy of running an old Node project

#75

Post by Ameo »

fourseventy wrote: post #62
mvkel wrote: post #23

> time to run it after not touching it for 4 years > Two hours of my life gone... Two hours of work after 4 years sounds ... perfectly acceptable? And it would have run perfectly right away if the node version was specified, so a good learning, too This feels like making a mountain out of a mole hill

Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...

What ecosystem are you comparing to?

Any C/C++ project with even mild complexity has a good chance of being extremely difficult to build due to either missing libraries that have to be installed manually, system incompatibilities, or compiler issues.

Python has like 28 competing package managers and install options, half of which are deprecated or incompatible. I can't even run `pip install` at all anymore on Debian.

Even Rust, which is usually great and has modern packaging and built-in dependency management, often has issues building old projects due to breaking changes to the compiler.

All this is to try to say that I don't think this is some problem unique to JS at all - but rather a side effect of complex interconnected systems that change often.

A big reason Docker and containers in general became so popular was because it makes this problem a lot less difficult by bundling much of the environment into the container, and Docker is very much agnostic to the language and ecosystem running inside it.

Re: The tragedy of running an old Node project

#76

Post by elzbardico »

graypegg wrote: post #43
uludag wrote: post #14

The worst part isn't just that it's nearly impossible to run/update an outdated JS project, but that this process will repeat itself ad infinitum. On the flip side, anything that uses vanilla JS without a build will most likely run just fine, probably till the end of human civilization.

I truly believe some flavour of "Javascript Classic" (some future state of JS before some big shift in syntax/mass migration to something else), C and x86 instructions will follow humanity for the rest of time. There will be javascript somewhere aboard the interstellar spaceships of the future, and we will still complain about it.

Well, even Fortran is still around us in some lapack code in numpy and in a lot of the stuff behing scipy, so, a lot closer than a lot of people can imagine.

Basically a lot of AI depends on a bunch of absurdly optimized numeric libraries writen in Fortran.

Fortran is well into the way at becoming a centenarian programing language at 74 years of age.

Re: The tragedy of running an old Node project

#77

Post by watsocd »

kamma4434 wrote: post #57
jerf wrote: post #7

Earlier quoted context omitted.

One of the things I'm intrigued by is that JS people, and the other couple of ecosystems where this is a big problem, go out to learn another language (as a good T-shaped developer does), and then start posting frantic questions to the new language's communities about how this popular library hasn't had a commit in six weeks, is it dead, oh my gosh wtf aaaaaaaaaaa. It's OK. Not every language ecosystem is so busted t…

I would expect most Java projects from 20 years ago to compile and run with zero issues.

Absolutely not. Not on the client side anyway.

I know of one application by a large multinational that requires java in the browser to run. Almost impossible to run now because of security restrictions.

Re: The tragedy of running an old Node project

#78

Post by WD-42 »

mvkel wrote: post #23

> time to run it after not touching it for 4 years > Two hours of my life gone... Two hours of work after 4 years sounds ... perfectly acceptable? And it would have run perfectly right away if the node version was specified, so a good learning, too This feels like making a mountain out of a mole hill

Which is fine until your host doesn’t support older versions of node.

I just got burned by an old js (vue 2) project. I ended up re writing it using good old ssr in Django with htmx and alpine when necessary. Now it’ll run until the end of time. It doesn’t even have a build step.

Re: The tragedy of running an old Node project

#79

Post by arp242 »

jeberle wrote: post #70
arp242 wrote: post #56

Earlier quoted context omitted.

Well, the "solution" ended up as "I gave up and just installed an old Node version and called it a day". So those 2 hours weren't even enough. I've been using Jekyll/Ruby since 2014 for my website, with a few custom plugins I wrote myself. And I've never really needed to do anything like this. It "just works". My Go and C programs are the same: "just works". I have some that are close to a decade old.

Not sure if I'd call out Jekyll as a paragon of stability. The last time I touched it, I made sure to write up detailed notes. In fairness, it's the only time I interact w/ Ruby. https://jeberle.github.io/jekyll-setup

Those mostly seem the standard Ruby/Jekyll/GitHub Pages setup instructions?

I don't love how bundler works by the way; I think it should/could be a lot better in many different ways. Same for Jekyll. But once it works, it generally keeps working.

I don't think Jekyll (or Ruby) are a paragon of stability. I'm sure some stuff has broken over the years. It just seems to break a lot less than the JS/Node ecosystems.

Re: The tragedy of running an old Node project

#80

Post by beardyw »

CognitiveLens wrote: post #60
beardyw wrote: post #25

I'm pretty sanguine about languages and frameworks, but I draw the line at node. I have seen so many horrors visited by dependencies, often to do just one thing where 2 or 3 lines of code would do the job anyway. When I was managing teams, whatever the language, I would ban any new dependencies which I didn't personally agree with. A lack of control just creates a nightmare.

Was that kind of control well-received by your teams? Out of context, it sounds like it would be pretty rough to be an engineer on a team where your manager had sole control over what tools you could use - I suppose it might make sense for junior devs or a very small codebase, but I would caution against taking that stance in a team where you want to facilitate mutual trust

Well back then there were fewer options, but the result was that completed products were easy to work with. Perhaps we live in different times.
Post reply on HN