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

261–270 of 412 posts

Re: The tragedy of running an old Node project

#261

Post by spacebanana7 »

peutetre wrote: post #106
graypegg wrote: post #43

Earlier quoted context omitted.

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.

JavaScript will be killed off by WebAssembly. Zombie JavaScript will be reduced to being glue code and then not even that.

Network effects are very strong for languages.

Better query languages than SQL could exist, but there's so much existing code and expertise out there that it's not worth the effort. Better backend languages than Java can & do exist but don't have the same enterprise popularity.

Developers, projects and companies have an immense incentives to target the most popular programming language.

Re: The tragedy of running an old Node project

#262

Post by yawnxyz »

gr4vityWall wrote: post #248

I recently migrated a project to Node.js 8 (!) to Node.js 14 (hopefully just the beginning), and I can relate to this post. In the JS ecosystem, I'm aware that Meteor is one major framework that takes backwards-compatibility seriously. Updating a project on an ancient version to a less-ancient version usually is not too hard. They try to keep APIs the same and introduce compatibility packages where possible. Meteor 2…

> Meteor 2.16 to Meteor 3 introduced major breaking changes

That's when I picked up the Node/React ecosystem...

> node-gyp errors > downgrade to 12.2

This is what I did until Vercel decided to not support Node 12 anymore...

Re: The tragedy of running an old Node project

#263

Post by aronhegedus »

Cool that you managed to get it running after just 2 hours. Same thing applies to python projects, a little note in README saves so much time in the future, I always try and use virtual environments and specify a specific python version so I can just nuke and reinstall everything

Re: The tragedy of running an old Node project

#264

Post by tmpz22 »

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…

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

Re: The tragedy of running an old Node project

#265

Post by [deleted] »

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

[deleted]

Re: The tragedy of running an old Node project

#266

Post by exabrial »

2020 is not "old".

"Not Invented Here" is whats going on. Developers of this age need to learn this.

A recent exmaple is the RPI Foundation nullifying thousands of internet tutorials renaming "/boot" vs "/bootfs". Ask yourself a serious question, did that actually improve anything? No it did not.

Re: The tragedy of running an old Node project

#267

Post by em-bee »

mst wrote: post #142
em-bee wrote: post #85

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…

I've been experimenting recently, with quite some success, with having a 'libs.js' file that pulls in and re-exports everything external I want, and providing a script that applies 'bun build' to just that. I haven't yet decided if/how I want to include a prebuilt version of it in the repo, I *think* I may go the approach of having a commit that modifies libs.js and/or the lockfile and then an immediately following o…

note that my websites/apps are completely free of anything to build. the source that is used for development which goes into the repo is what is being loaded into the browser without change.

saving a prebuilt version of code that needs building is of course also helpful, and much better than having to rely on keeping your build tools working. but when you want to make changes to the site you have to either deal with the build tools anyways or work with the prebuilt version which may not be as practical.

either way i would simply save the prebuilt version to a branch and if any changes are made in that branch cherrypick them over to the dev branch if they even can be use, which i am not sure about. i'd probably rather avoid making changes to the prebuilt code in the first place

how does lack of a compile step affect the code? are there things i won't be able to do if i don't compile? i haven't started yet, and my website is not very complex so i think i'll manage either way, but i am curious. can you link to an example?

Re: The tragedy of running an old Node project

#268

Post by a1o »

neonsunset wrote: post #205
me551ah wrote: post #202

Earlier quoted context omitted.

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

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

Note Microsoft still removes downloads of previous versions of Visual Studio that aren't the latest - now you can only download VS2022 unless you have some mysterious paid account that has access to those - I don't have in either my personal or my corporate so I don't know the details

Re: The tragedy of running an old Node project

#269

Post by [deleted] »

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

[deleted]

Re: The tragedy of running an old Node project

#270

Post by demosthanos »

jorams wrote: post #252
demosthanos wrote: post #198

Earlier quoted context omitted.

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 , no…

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.

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.
Post reply on HN