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

171–180 of 412 posts

Re: The tragedy of running an old Node project

#171

Post by fredrikholm »

regularfry wrote: post #124
vessenes wrote: post #6

This will always be an issue for the node community - it’s endemic to the JavaScript shipping / speed culture and the package management philosophy. Go is much, much better on these terms, although not perfect. I’d venture a guess that Perl 5 is outstanding here, although it’s been a few years since I tried to run an old Perl project. CPAN was dog slow, but other than that, everything worked first try. I’d also bet T…

Clojure too, by all accounts. I'd say Common Lisp but they're in the weird position of code itself being rampantly portable across time but the ecosystem around it being astonishingly immature.

Things have improved a lot with the introduction of Quicklisp, but I'd have to agree when compared to others.

CL is still one of the nicest languages there is, and the only language that skirts the line between being some combination of dynamic and interpreted yet typed and compiled.

It is showing its age though, particularly around the edges like what you're saying.

Re: The tragedy of running an old Node project

#172

Post by tomgp »

baq wrote: post #95
melbourne_mat wrote: post #41

First thing I would have done is upgrade the version of Gatsby to latest. Did the author try that? If upgrading is difficult because of 4 years of breaking changes, blame Gatsby for not being backwards compatible. Also blame your original choice of going with a hokey framework. Speaking of hokey framework: 167 dependencies and 3000 versions of Gatsby in npm.

blaming anything or anyone gets you exactly zero seconds closer to getting the job done.

You could perhaps reframe "blame" as identifying the source of the problem and iunderstand why it can be a useful excercise (aslo none of us here are trying to solve the problem really, just wasting time on the internet). In this case Node and it's atendant ecosystem are certainly a part of the problem but I would agree that Gatsby is a bigger part of the issue as they don't seem to have any interest in taming the Node dependecy management beast. I've had to dig into Gatsby projects mere months old and it really was like opening a can of worms.

Re: The tragedy of running an old Node project

#173

Post by nisegami »

jonathanlydall wrote: post #164
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

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

I wish I lived in the world you described but trying to onboard a new dev onto an existing (edit: ancient) C# project at my job is frequently a multi-day endeavor.

Re: The tragedy of running an old Node project

#174

Post by toyg »

jonathanlydall wrote: post #164
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

C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way.

> C# devs can open decade+ old solutions without issues

For some definition of "without issues"...

Re: The tragedy of running an old Node project

#175

Post by zbentley »

vessenes wrote: post #6

This will always be an issue for the node community - it’s endemic to the JavaScript shipping / speed culture and the package management philosophy. Go is much, much better on these terms, although not perfect. I’d venture a guess that Perl 5 is outstanding here, although it’s been a few years since I tried to run an old Perl project. CPAN was dog slow, but other than that, everything worked first try. I’d also bet T…

I've had a fair amount of trouble with Perl/cpan simply because of the sheer number of XS (compiled C extension) modules in the ecosystem. For even a medium sized perl project that e.g. talks to databases or whatnot, building it after a long time requires you to spend tedious hours getting the right development headers/libraries for the compiled components, fussing with compiler flags, dealing with C ABI symbols that were deprecated in the interim, etc.

To be fair, Python and Ruby also have this problem (for newer Pythons, popular extension modules at recent versions are more likely to Just Work due to wheels, but if you're building old code for the first time in 3+ years, all the old problems come back with a vengeance). It's more of a "scripting language that got popular enough that ordinary projects have a deep tree of transitives, many of which are compiled on-site" issue than a Perl specific problem.

Re: The tragedy of running an old Node project

#176

Post by molszanski »

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

I agree. It is not weird if you try to run old code through new env / vm / framework / compiler it can break.

Locking env version is important.

Double points for using experimental / POC technology like gatsby or nextjs. They are expected to burn and fail

Re: The tragedy of running an old Node project

#178

Post by LamaOfRuin »

elashri wrote: post #117
Ameo wrote: post #112

Earlier quoted context omitted.

No that does not work either. You get an error like this: » pip3 install supervisor error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. As far as I can understand, they did this on purpose to dissuade users from installing packages globally to avoid conflicts with oth…

I understand that, you can use `--break-system-packages` or change configuration `python3 -m pip config set global.break-system-packages true`. Python is different here because in many linux distributions, there are many tools that rely on you system python. Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful. So while I understand you are using this as an examp…

>Python unlike node is not limited (in practice) to web applications. that's why you have to be more careful.

They may or may not be running Node.js specifically, but I believe that many Linux distributions, as well as Windows, include JavaScript code in core applications. I don't see this as particularly different, except that they might choose to assume a single standard system Python that is able to be modified by standard Python development, whereas I would rarely expect that to be the case with however each component chooses to execute JavaScript.

Re: The tragedy of running an old Node project

#179

Post by ivan_gammel »

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

I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Two hours of dancing with a drum doesn’t feel acceptable to me.

Re: The tragedy of running an old Node project

#180

Post by ivan_gammel »

wink wrote: post #154
treflop wrote: post #114

Earlier quoted context omitted.

Java has a great ecosystem. It’s well thought out and I can compile and run 10 year old projects no problem. In fact, I wish everyone had just copied Java’s model instead of inventing their own worse model. I love Python but it has a terrible package ecosystem with mediocre tooling that has only gotten worse with time. JavaScript has gotten better but it seems they are just re-learning things that were long figured o…

I am not sure you should put ant or maven as shining examples here, but I am kinda warming up to Gradle, at least without Groovy being involved.

What do you get from Gradle that Maven cannot offer?
Post reply on HN