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

81–90 of 412 posts

Re: The tragedy of running an old Node project

#81

Post by com2kid »

le-mark wrote: post #40
com2kid wrote: post #27

Earlier quoted context omitted.

node-gyp is a huge source of these issues for Node projects, especially older ones. For those reading this who don't know much about node - node-gyp is how you pull in native code libraries to Node projects, typically for performance reasons. You get the same sorts of build issues with it that you can get whenever you start having binary, or source, dependencies, and you need the entire toolchain to be "Just Right(tm…

> For those reading this who don't know much about node I would prefer to remain blissfully ignorant, thank you!

IMHO TypeScript is the best mainstream language to write code in right now. It is incredibly expressive and feature rich, and you can model in almost any paradigm you like. The ecosystem around it allows you to choose whatever blend of runtime vs compile time type safety you prefer. Lots of people just runtime type check at their endpoint boundaries, and use compile time for everything internal to a service, but again, the choice is yours.

The Node+Express backend ecosystem is also incredibly powerful. Node is light weight, the most naïve code can handle a thousand RPS on the cheapest of machines, and you can get an entire server up and running with CORS+Auth+JSON endpoints in just 5 or 6 lines of code, and none of that code has any DI magic or XML configuration files.

JS/TS is horrible for numeric stuff, but it is great for everything else.

Re: The tragedy of running an old Node project

#82

Post by em-bee »

watsocd wrote: post #77
kamma4434 wrote: post #57

Earlier quoted context omitted.

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.

well java on the desktop and java in the browser are two entirely different beasts. the problem here is not java but the changes that have been made in the browser.

Re: The tragedy of running an old Node project

#83

Post by em-bee »

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

it took two hours just to get the project running as it was 4 years ago. wait how much time it will take to upgrade everything to new versions.

and dare i say this is the lucky case. i had problems reactivating some older project because some dependencies were not version locked and newer versions of those were incompatible with other versioned ones. then it took forever to figure out the right versions. and i think i even had situations where the old version wasn't even available anymore (perhaps because of a linux dependency that wasn't available anymore on my newer linux system)

Re: The tragedy of running an old Node project

#84

Post by Supermancho »

mattgreenrocks wrote: post #32
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

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

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.

Re: The tragedy of running an old Node project

#85

Post by em-bee »

i could not tell from the article whether this was a site with a backend using node.js or if it was just a frontend depending on node.js for the build tools.

for the latter i get around the problem by avoiding build tools altogether. i use a frontend framework that i can load directly into the browser, and use without needing any tools to manage dependencies. the benefit from that is that it will ensure that my site will keep running for years to come, even if i leave it dormant for some time. the downside is that it is probably less optimized. but for smaller sites that aren't under continuous maintenance this is a reasonable tradeoff. i built all my recent sites that way using a prebuilt version of the aurelia framework.

incidentally just today i tried to research if i could build a site with svelte that way. well, it turns out that although it should theoretically be possible, i was unable to find a prebuilt version to do so after a few hours of searching. for vuejs i found one within minutes. i'll be learning vuejs now.

see this thread for a discussion on going buildless: https://news.ycombinator.com/item?id=41479365

Re: The tragedy of running an old Node project

#86

Post by tgv »

Macha wrote: post #69
skybrian wrote: post #30

Earlier quoted context omitted.

Go’s minimum version selection is the way and I don’t understand why other ecosystems haven’t adopted it. You’re be able to compile an old project with all the library dependencies it had at the time it was released. It might have security issues, but at least you start with a version that works and then can go about upgrading it. It also helps that if some library dependency generated Go code using a tool, the Go so…

Getting the exact dependencies it had at release is a solved problem in Node and most other languages with lock files too. It's just no guarantee that those old versions work on the new system, or with the outside world as it exists by time of installation - which can be as true for Go as any other language. If the XYZ service API client still gets you version 1.2.37, that's not actually any help if 1.2.37 calls endp…

Some time ago, I wanted to update Arch, on a server running some python project I had inherited. Long story short, it relied on something that relied on something that etc., and then it turned out certain components that were needed for the upgrade process had been taken offline. Now the system can’t be changed, unless there’s significant work done to the code, and that’s too expensive. It runs on request in a container now, while it lasts.

Re: The tragedy of running an old Node project

#87

Post by cxr »

Supermancho wrote: post #84
mattgreenrocks wrote: post #32

Earlier quoted context omitted.

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

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.

Re: The tragedy of running an old Node project

#88

Post by [deleted] »

viraptor wrote: post #65
fourseventy wrote: post #62

Earlier quoted context omitted.

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

This is not even JS specific. All of Python / Ruby / other changing runtimes will require some upkeep. Even C recently needs some attention because clang updated default errors.

[deleted]

Re: The tragedy of running an old Node project

#89

Post by cxr »

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.

> it's nearly impossible to run/update an outdated JS project

You corrected yourself, but it's worth emphasizing here: a _NodeJS_ project, you mean.

Unless you're using non-standard APIs, stuff written to run in the browser generally keeps working just as well as it did before, no matter whether it was written 2 years ago or 10.

Post reply on HN