12 ms·

> 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 wou

by mvkel 2y ago

> 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

mattgreenrocks 2y ago
Other ecosystems usually do not have problems to the extent the author had.
- hathawsh 2y ago
  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.
  - tmpz22 2y ago
    > 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.
    - Nadya 2y ago
      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".
      - hathawsh 2y ago
        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.
      - tmpz22 2y ago
        > 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.
    - pjc50 2y ago
  - lmm 2y ago
    > 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.
  - the_mitsuhiko 2y ago
    > 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.
    - cle 2y ago
      Will uv even be around in 4+ years? No idea.
      - the_mitsuhiko 2y ago
        I don't know either, but think even if it's not, whatever will replace it, will at least have to achieve feature parity.
- Supermancho 2y ago
  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.
  - cxr 2y ago
    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.
    - deleted 2y ago
      [deleted]
    - cxr 2y ago
      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.
korkybuchek 2y ago
> Two hours of work after 4 years sounds ... perfectly acceptable? Does it, though? Node wasn't exactly new 4 years ago, and plenty of other languages would offer a better experience for even older code -- Java, C, C++ to name a few.
- mvkel 2y ago
  Define "better experience." 1.5 hours to get running again? 1? In exchange for needing to run C? How many hours would it take to build a Node app equivalent in C, I wonder.
  - regularfry 2y ago
    0 would be fine. I'd take 0. This could all have been avoided if the interpreter version had been recorded by default somewhere. That's all this needed.
- demosthanos 2y ago
  > Java 50% of Java developers are still regularly working in Java 8 [0], which is the same solution that the author could have arrived at immediately—when starting up an old project after 4 years, use the same version you ran last time, don't try to update before you even have the thing running. > C, C++ Not my experience, but maybe it depends on your operating system and distro? In my experience sorting through the C libs and versions that you need to install on your system to build a new project can easily take a few hours. [0] https://www.jetbrains.com/lp/devecosystem-2023/java/ https://www.jetbrains.com/lp/devecosystem-2023/java/
abdisalan 2y ago
You’re absolutely right. My rational brain agrees and chalks it up to poor project management. However… emotions run high when you have zero idea why something isn’t working and the process of elimination is pretty taxing. So the point for me is venting / maybe someone will read this and remember to write their node version down!
ErikAugust 2y ago
Also, Gatsby has dependencies that aren’t even Node. I have had it break too.
arp242 2y ago
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.
- jeberle 2y ago
  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 https://jeberle.github.io/jekyll-setup
  - arp242 2y ago
    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.
- pzmarzly 2y ago
  Good for you, my experience with Jekyll is closer to OP's experience with Node. I have a big website that I built in 2014, with tons of custom plugins, that is now stuck on Jekyll 2.x and Ruby 2.x, and has a ton of hidden C++ dependencies. The way I build it now is using a Dockerfile with Ubuntu 18.04. I probably could update it given enough effort, but I was rather thinking of rewriting it in Astro.js or Next.js.
  - rahoulb 2y ago
    This is the issue I have with the "build vs buy (or import)" aspect of today's programming. There are countless gems, libraries or packages out there that make your life easier and development so much faster. But software (in my experience) always lives longer than you expect it to, so you need to be sure that your dependencies will be maintained for that lifetime (or have enough time to do the maintenance or plug in the replacements yourself).
fourseventy 2y ago
Sounds like you are way too used to the javascript ecosystem if you think getting an old project to build should take hours...
- viraptor 2y ago
  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.
  - Macha 2y ago
    Even some of my Rust projects end up in this state, where updating one library ends up with needing to update interacting libraries.
    - jakimfett 2y ago
      That sounds pretty frustrating. When I find my shell scripts from 20+ years ago, they still just run as intended.
  - deleted 2y ago
    [deleted]
- Ameo 2y ago
  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.
WD-42 2y ago
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.
- authorfly 2y ago
  I sympathize with you, I had one too. Luckily it was small. It seems luck of the draw. My old React projects (old as in 2018) still work great with class components. I guess the Vue guy did say he would be more revolutionary, when he launched it.
em-bee 2y ago
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)
- DecoySalamander 2y ago
  It took 2 hours to realize that project build for a specific version of node should be run with that version of node. And even that was self inflicted since author didn't vet dependencies and used something build as a C++ node addon instead of actual JS (my bet it was to have a slightly easier time writing CSS).
- kwertyoowiyop 2y ago
  And even though it builds, there’s no guarantee it’ll work properly.
fbn79 2y ago
I would love the author to test and old java/maven project. Node is a paradise compared to that stack.
- avtolik 2y ago
  Why do you think so? I have 10+ years old Java/Maven projects that build and run fine.
  - fbn79 2y ago
    Maybe you are fortunate or I'm not because in projects I have experienced missing o changed maven repository urls and changed deps packages names or url. And was an hell to fix.
- cies 2y ago
  The only problems I've run into are related to certain package repos that went offline. So you have to track down suitable versions of certain packages on other repos. OTOH with Node I always find myself in dependency hell with dealing with old projects.
  - fbn79 2y ago
    In my experience this only happen if the project does not have a lock file and does not specify a node version (two good practice that must be followed).
    - cies 2y ago
      I'm talking about upgrading dependencies. Something that's rarely easy in a JS/TS project with lots of dependencies.
watt 2y ago
Did you read it? The author did not actually resolve the issue, only figured out that it should build with older Node version.
jonathanlydall 2y ago
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.
- nisegami 2y ago
  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.
- toyg 2y ago
  > C# devs can open decade+ old solutions without issues For some definition of "without issues"...
- thrw42A8N 2y ago
  Lol, I left C# because I couldn't solve this issue and in Node.js it's particularly easy - just keep a nvmrc file and a dependency lockfile.
- me551ah 2y ago
  Not true for the entire C# ecosystem. I tried rebooting a Xamarin project I coded a couple of years ago. Had to spend weeks upgrading it cause Microsoft decided to discontinue Xamarin and force everyone to use NET MAUI
  - neonsunset 2y ago
    This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can download regardless, it will complain that it is EOL though) but it's an otherwise simple procedure. For library code it's even easier - if you have netstandard2.0 target, it will work anywhere from .NET Framework 4.6.1 to the latest version without requiring any maintenance effort whatsoever. On Windows, Visual Studio will happily work with .NET Framework 3.0 (which is ancient) and more.
blenderob 2y ago
> Two hours of work after 4 years sounds ... perfectly acceptable? Pefectly acceptable? Perfectly? Really? I have 10 year old C and Go projects that build and run fine as if nothing has changed. I can upgrade the dependencies if I want to but that's on me. The projects themselves have no problem building and running fine.
- microtonal 2y ago
  Just to try it out, I took one of my old C projects written in 2010, last code update in 2012. It's a machine learning utility to train maximum entropy rankers. I was a bit worried because it used CMake (rather than a vanilla Makefile). It configured and built without any issues (and super-fast).
  - fennecfoxy 2y ago
    How many external dependencies/libraries does it use? Ie remote dependencies not stored on your machine? How complex is the project? I know ML utilities like that can be as simple as 50-100 lines.
- paulddraper 2y ago
  Lol, Go was notorious for breaking with its "pull from main"/lack of lockfile approach.
molszanski 2y ago
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
ivan_gammel 2y ago
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.
- demosthanos 2y ago
  Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later.
  - ivan_gammel 2y ago
    Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
    - demosthanos 2y ago
      Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability. There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point.
    - lowboy 2y ago
      Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.
      - cesarb 2y ago
        > Well, the article is about npm, a package manager for node. And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.
demosthanos 2y ago
It's also two hours that would have been completely avoided if the author were familiar enough with Node to know to pin the version and not try to install 4 years of updates in one shot. Most who are here saying that X, Y, or Z ecosystem "compiles and runs" fine after 4 years are talking about the time it takes to resume an old project in a language they're very familiar with running the same dependency versions, not the time it takes to version bump a project on a language that you don't know well without actually having it running first on the old version. I can open my 4-year-old Node projects and run them just fine, but that's because I use the tools that the ecosystem provides for ensuring that I can do so (nvm, .nvmrc, engines field in package.json).
- jorams 2y ago
  The author didn't update all dependencies, they just tried running it on a newer version of Node itself. That is definitely a use case included when most people talk about an ecosystem compiling and running fine after several years.
  - demosthanos 2y ago
    In some ecosystems, yes, backwards compatibility is a given, but not in most. Python versions behave in much the same way as Node, with you having to make sure you're using the same Python version this time as last time in order to be able to install the same dependency versions. Java has been better in recent years, but Java 8->9 can take several hours to get working on even a small project.
- kwertyoowiyop 2y ago
  Pinning versions should’ve been the default, then.
antihero 2y ago
Yep, this could have been sorted by one line in a .tool-versions file and using mise or asdf.
ericmcer 2y ago
Exactly, you would have to compare it to other package managers to make it fair. Npm at this point is probably the most used and most worked on package manager in history. If it is still one of the worst ones that is actually kind of interesting philosophically.
fennecfoxy 2y ago
Exactly, 2 hours after 4 years is perfectly fine. And all those saying "well my c project did it without a problem!" yeah that's why the entire world is mostly using c for large modern, complex and ever-changing applications; right? Most of the C stuff people are claiming compiles fine after so long have no external dependencies and are really small, simple projects... This whole thread just reeks of JS hate. I'm not perfectly happy with the language either, but nor am I perfectly happy with any other. If my employer wanted me to use C# or Go or whatever instead I'd be perfectly okay with that as well.
stuaxo 2y ago
Each to their own, I don't find it acceptable - while other platforms have updates needed, it's not to the same level.
thiht 2y ago
> Two hours of work after 4 years sounds ... perfectly acceptable? It's really not. I'm in the same situation with a Go + React project I haven't really touched in 3 years. The Go part is just `go build`, it still works after 3 years and I have a build in a fraction of a second. The React project doesn't build anymore at all. I used Parcel 2 at the time, and it turns out it's incompatible with a Mac M1 for some reason, and it's hard to update in my case. I also used Antdesign and some components (icons specifically) apparently disappeared. It should not be so hard.
- lelandfe 2y ago
  I feel like you've just proffered a second success story. It can get worse. I've worked on software whose "dusting off" involved swapping the entire dep tree because the remote that Bower was using no longer existed, or manually compiling pinned versions of dependencies that Homebrew no longer offered. Sometimes it took days to get everything working.
- LunaSea 2y ago
  Go would be much worse than Node.js in most cases since dependencies directly reference GitHub projects which could have been deleted whereas NPM has a cache and immutability guarantee which makes old NPM modules available and unchanged.
  - thiht 2y ago
    You rely way less on dependencies when writing Go code though. That’s in big parts why it doesn’t break nearly as much (or at all).
  - pipe01 2y ago
    Go also has the goproxy
signal11 2y ago
An anecdote — I recently upgraded an old NodeJS project written using v14 to 22. It used an old version of Svelte for the UI. It wasn’t too bad, took about 90 minutes to upgrade a bunch of Svelte 3 components to Svelte 5, with some assistance from Copilot. This was with zero awareness of Svelte 5 (I only knew it was released — I wanted to upgrade because Node 14 is EOL now and I’d noticed some npm audit warnings.) So I feel I also learned something in the process.

by mvkel 2y ago

mattgreenrocks 2y ago

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

hathawsh 2y ago
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.
- tmpz22 2y ago
  > 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.
  - Nadya 2y ago
    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".
    - hathawsh 2y ago
      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.
    - tmpz22 2y ago
      > 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.
  - pjc50 2y ago
- lmm 2y ago
  > 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.
- the_mitsuhiko 2y ago
  > 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.
  - cle 2y ago
    Will uv even be around in 4+ years? No idea.
    - the_mitsuhiko 2y ago
      I don't know either, but think even if it's not, whatever will replace it, will at least have to achieve feature parity.
Supermancho 2y ago
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.
- cxr 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - cxr 2y ago
    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.

korkybuchek 2y ago

> Two hours of work after 4 years sounds ... perfectly acceptable? Does it, though? Node wasn't exactly new 4 years ago, and plenty of other languages would offer a better experience for even older code -- Java, C, C++ to name a few.

mvkel 2y ago
Define "better experience." 1.5 hours to get running again? 1? In exchange for needing to run C? How many hours would it take to build a Node app equivalent in C, I wonder.
- regularfry 2y ago
  0 would be fine. I'd take 0. This could all have been avoided if the interpreter version had been recorded by default somewhere. That's all this needed.
demosthanos 2y ago
> Java 50% of Java developers are still regularly working in Java 8 [0], which is the same solution that the author could have arrived at immediately—when starting up an old project after 4 years, use the same version you ran last time, don't try to update before you even have the thing running. > C, C++ Not my experience, but maybe it depends on your operating system and distro? In my experience sorting through the C libs and versions that you need to install on your system to build a new project can easily take a few hours. [0] https://www.jetbrains.com/lp/devecosystem-2023/java/ https://www.jetbrains.com/lp/devecosystem-2023/java/

abdisalan 2y ago

You’re absolutely right. My rational brain agrees and chalks it up to poor project management. However… emotions run high when you have zero idea why something isn’t working and the process of elimination is pretty taxing. So the point for me is venting / maybe someone will read this and remember to write their node version down!

ErikAugust 2y ago

Also, Gatsby has dependencies that aren’t even Node. I have had it break too.

arp242 2y ago

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.

jeberle 2y ago
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 https://jeberle.github.io/jekyll-setup
- arp242 2y ago
  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.
pzmarzly 2y ago
Good for you, my experience with Jekyll is closer to OP's experience with Node. I have a big website that I built in 2014, with tons of custom plugins, that is now stuck on Jekyll 2.x and Ruby 2.x, and has a ton of hidden C++ dependencies. The way I build it now is using a Dockerfile with Ubuntu 18.04. I probably could update it given enough effort, but I was rather thinking of rewriting it in Astro.js or Next.js.
- rahoulb 2y ago
  This is the issue I have with the "build vs buy (or import)" aspect of today's programming. There are countless gems, libraries or packages out there that make your life easier and development so much faster. But software (in my experience) always lives longer than you expect it to, so you need to be sure that your dependencies will be maintained for that lifetime (or have enough time to do the maintenance or plug in the replacements yourself).

fourseventy 2y ago

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

viraptor 2y ago
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.
- Macha 2y ago
  Even some of my Rust projects end up in this state, where updating one library ends up with needing to update interacting libraries.
  - jakimfett 2y ago
    That sounds pretty frustrating. When I find my shell scripts from 20+ years ago, they still just run as intended.
- deleted 2y ago
  [deleted]
Ameo 2y ago
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.

WD-42 2y ago

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.

authorfly 2y ago
I sympathize with you, I had one too. Luckily it was small. It seems luck of the draw. My old React projects (old as in 2018) still work great with class components. I guess the Vue guy did say he would be more revolutionary, when he launched it.

em-bee 2y ago

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)

DecoySalamander 2y ago
It took 2 hours to realize that project build for a specific version of node should be run with that version of node. And even that was self inflicted since author didn't vet dependencies and used something build as a C++ node addon instead of actual JS (my bet it was to have a slightly easier time writing CSS).
kwertyoowiyop 2y ago
And even though it builds, there’s no guarantee it’ll work properly.

fbn79 2y ago

I would love the author to test and old java/maven project. Node is a paradise compared to that stack.

avtolik 2y ago
Why do you think so? I have 10+ years old Java/Maven projects that build and run fine.
- fbn79 2y ago
  Maybe you are fortunate or I'm not because in projects I have experienced missing o changed maven repository urls and changed deps packages names or url. And was an hell to fix.
cies 2y ago
The only problems I've run into are related to certain package repos that went offline. So you have to track down suitable versions of certain packages on other repos. OTOH with Node I always find myself in dependency hell with dealing with old projects.
- fbn79 2y ago
  In my experience this only happen if the project does not have a lock file and does not specify a node version (two good practice that must be followed).
  - cies 2y ago
    I'm talking about upgrading dependencies. Something that's rarely easy in a JS/TS project with lots of dependencies.

watt 2y ago

Did you read it? The author did not actually resolve the issue, only figured out that it should build with older Node version.

jonathanlydall 2y ago

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.

nisegami 2y ago
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.
toyg 2y ago
> C# devs can open decade+ old solutions without issues For some definition of "without issues"...
thrw42A8N 2y ago
Lol, I left C# because I couldn't solve this issue and in Node.js it's particularly easy - just keep a nvmrc file and a dependency lockfile.
me551ah 2y ago
Not true for the entire C# ecosystem. I tried rebooting a Xamarin project I coded a couple of years ago. Had to spend weeks upgrading it cause Microsoft decided to discontinue Xamarin and force everyone to use NET MAUI
- neonsunset 2y ago
  This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can download regardless, it will complain that it is EOL though) but it's an otherwise simple procedure. For library code it's even easier - if you have netstandard2.0 target, it will work anywhere from .NET Framework 4.6.1 to the latest version without requiring any maintenance effort whatsoever. On Windows, Visual Studio will happily work with .NET Framework 3.0 (which is ancient) and more.

blenderob 2y ago

> Two hours of work after 4 years sounds ... perfectly acceptable? Pefectly acceptable? Perfectly? Really? I have 10 year old C and Go projects that build and run fine as if nothing has changed. I can upgrade the dependencies if I want to but that's on me. The projects themselves have no problem building and running fine.

microtonal 2y ago
Just to try it out, I took one of my old C projects written in 2010, last code update in 2012. It's a machine learning utility to train maximum entropy rankers. I was a bit worried because it used CMake (rather than a vanilla Makefile). It configured and built without any issues (and super-fast).
- fennecfoxy 2y ago
  How many external dependencies/libraries does it use? Ie remote dependencies not stored on your machine? How complex is the project? I know ML utilities like that can be as simple as 50-100 lines.
paulddraper 2y ago
Lol, Go was notorious for breaking with its "pull from main"/lack of lockfile approach.

molszanski 2y ago

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

ivan_gammel 2y ago

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.

demosthanos 2y ago
Maven, maybe, but Gradle absolutely not. If you don't have the exact version of Gradle that you used before, you're in for the same kind of misery documented above, with the same end state: just stick to the old version and deal with the upgrade later.
- ivan_gammel 2y ago
  Well, I‘m not talking about Gradle, right? Sometimes conservative choice is what gets the job done.
  - demosthanos 2y ago
    Right, I'm just clarifying for others who may not know the difference that Node doesn't have a monopoly on instability. There are a very small number of projects that specifically make it their goal to be backwards-compatible effectively indefinitely, and Maven is one of those. It's part of what people who hate it hate about it, but for others it's the main selling point.
  - lowboy 2y ago
    Well, the article is about npm, a package manager for node. Vendoring dependencies into source is a choice, albeit one that I don't often reach for.
    - cesarb 2y ago
      > Well, the article is about npm, a package manager for node. And Maven is a package manager for Java. The main difference IMO? The usual way to do things in Maven is to always use exact versions for the dependencies. When I specify I want some dependency at version 1.2.3, Maven will use version 1.2.3 of that dependency even if 1.2.4 or later already exists.

demosthanos 2y ago

It's also two hours that would have been completely avoided if the author were familiar enough with Node to know to pin the version and not try to install 4 years of updates in one shot. Most who are here saying that X, Y, or Z ecosystem "compiles and runs" fine after 4 years are talking about the time it takes to resume an old project in a language they're very familiar with running the same dependency versions, not the time it takes to version bump a project on a language that you don't know well without actually having it running first on the old version. I can open my 4-year-old Node projects and run them just fine, but that's because I use the tools that the ecosystem provides for ensuring that I can do so (nvm, .nvmrc, engines field in package.json).

jorams 2y ago
The author didn't update all dependencies, they just tried running it on a newer version of Node itself. That is definitely a use case included when most people talk about an ecosystem compiling and running fine after several years.
- demosthanos 2y ago
  In some ecosystems, yes, backwards compatibility is a given, but not in most. Python versions behave in much the same way as Node, with you having to make sure you're using the same Python version this time as last time in order to be able to install the same dependency versions. Java has been better in recent years, but Java 8->9 can take several hours to get working on even a small project.
kwertyoowiyop 2y ago
Pinning versions should’ve been the default, then.

antihero 2y ago

Yep, this could have been sorted by one line in a .tool-versions file and using mise or asdf.

ericmcer 2y ago

Exactly, you would have to compare it to other package managers to make it fair. Npm at this point is probably the most used and most worked on package manager in history. If it is still one of the worst ones that is actually kind of interesting philosophically.

fennecfoxy 2y ago

Exactly, 2 hours after 4 years is perfectly fine. And all those saying "well my c project did it without a problem!" yeah that's why the entire world is mostly using c for large modern, complex and ever-changing applications; right? Most of the C stuff people are claiming compiles fine after so long have no external dependencies and are really small, simple projects... This whole thread just reeks of JS hate. I'm not perfectly happy with the language either, but nor am I perfectly happy with any other. If my employer wanted me to use C# or Go or whatever instead I'd be perfectly okay with that as well.

stuaxo 2y ago

Each to their own, I don't find it acceptable - while other platforms have updates needed, it's not to the same level.

thiht 2y ago

> Two hours of work after 4 years sounds ... perfectly acceptable? It's really not. I'm in the same situation with a Go + React project I haven't really touched in 3 years. The Go part is just `go build`, it still works after 3 years and I have a build in a fraction of a second. The React project doesn't build anymore at all. I used Parcel 2 at the time, and it turns out it's incompatible with a Mac M1 for some reason, and it's hard to update in my case. I also used Antdesign and some components (icons specifically) apparently disappeared. It should not be so hard.

lelandfe 2y ago
I feel like you've just proffered a second success story. It can get worse. I've worked on software whose "dusting off" involved swapping the entire dep tree because the remote that Bower was using no longer existed, or manually compiling pinned versions of dependencies that Homebrew no longer offered. Sometimes it took days to get everything working.
LunaSea 2y ago
Go would be much worse than Node.js in most cases since dependencies directly reference GitHub projects which could have been deleted whereas NPM has a cache and immutability guarantee which makes old NPM modules available and unchanged.
- thiht 2y ago
  You rely way less on dependencies when writing Go code though. That’s in big parts why it doesn’t break nearly as much (or at all).
- pipe01 2y ago
  Go also has the goproxy

signal11 2y ago

An anecdote — I recently upgraded an old NodeJS project written using v14 to 22. It used an old version of Svelte for the UI. It wasn’t too bad, took about 90 minutes to upgrade a bunch of Svelte 3 components to Svelte 5, with some assistance from Copilot. This was with zero awareness of Svelte 5 (I only knew it was released — I wanted to upgrade because Node 14 is EOL now and I’d noticed some npm audit warnings.) So I feel I also learned something in the process.