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

301–310 of 412 posts

Re: The tragedy of running an old Node project

#301

Post by guappa »

mperham wrote: post #228
KronisLV wrote: post #217

Earlier quoted context omitted.

> I still can open my decade-old Java projects, run build with modern Maven/JDK and get working code - in a few minutes. Try any old Spring project, where anything newer than JDK 8 will be incompatible. The only saving grace is that JDK 8 is still available, but even it will eventually reach EOL. And then you look at JDK 11 projects and realize that they won't run on anything newer due to Lombok issues, so that's ano…

> I think the experience of code rot is universal and increases with the amount of dependencies you have. This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory ) and excellent backwards compatibility.

> Go is especially good because of the large stdlib

Come on… compare it with what java and python have.

Re: The tragedy of running an old Node project

#302

Post by dartos »

guappa wrote: post #301
mperham wrote: post #228

Earlier quoted context omitted.

> I think the experience of code rot is universal and increases with the amount of dependencies you have. This is true but there's also a factor from the language/framework in use. Node is especially bad because of it generates huge package dependency trees. Go is especially good because of the large stdlib (which I use to minimize deps in https://github.com/contribsys/faktory ) and excellent backwards compatibility.

> Go is especially good because of the large stdlib Come on… compare it with what java and python have.

What does Java or Python have in their stdlib that go doesn’t?

Re: The tragedy of running an old Node project

#303

Post by peutetre »

liontwist wrote: post #232
peutetre wrote: post #147

Earlier quoted context omitted.

The difference lately is the number of tools that are now in place for WebAssembly development and the new extensions to WebAssembly (WasmGC, Memory64, etc.). Despite 28 years of effort at optimization, JavaScript is outperformed by WebAssembly. There's not much coming back from that: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi... https://www.amazon.science/blog/how-prime-video-updates-its-... https:…

?? JavaScript was outperformed by every language since it was introduced. It doesn’t matter. What matters is what people put in their web pages.

But now JavaScript is no longer the privileged language in the browser.

With WebAssembly every language runs in the browser and runs better.

Re: The tragedy of running an old Node project

#304

Post by peutetre »

spacebanana7 wrote: post #261
peutetre wrote: post #106

Earlier quoted context omitted.

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.

JavaScript's one advantage was that it was the privileged language in the browser. It has lost that now.

JavaScript has entered its Walking Dead phase. It will gradually be displaced by all languages compiling to WebAssembly.

Re: The tragedy of running an old Node project

#305

Post by stall84 »

It's not just personal blogs as many of y'all know.. this is a daily struggle in any SDE mainly working in web .. I am constantly lamenting the fact I spend like 70% of my time at my main job (large financial company) just trying to get my environment , or the application's environment in a position to actually develop on the application itself .. It's insane. I f'n love javascript .. it's allowed a lot of us a doorway into software engineering where a lot of us realize how ... 'special' js and related web development are ;) .. But man it can make you really want to smash the computer some days.

Re: The tragedy of running an old Node project

#306

Post by peutetre »

yoelhacks wrote: post #297
peutetre wrote: post #147

Earlier quoted context omitted.

The difference lately is the number of tools that are now in place for WebAssembly development and the new extensions to WebAssembly (WasmGC, Memory64, etc.). Despite 28 years of effort at optimization, JavaScript is outperformed by WebAssembly. There's not much coming back from that: https://jordaneldredge.com/blog/speeding-up-winamps-music-vi... https://www.amazon.science/blog/how-prime-video-updates-its-... https:…

Javascript is outperformed by WebAssembly in the sense that it runs faster. A lot of things that bring a lot of value to a lot of people are still much, much faster to build via the JS / TS ecosystem. It absolutely makes sense that calculation-heavy workloads will be ported to WASM, but there's a lot more to building an app.

> but there's a lot more to building an app.

Like what? Visual UI designers? WebAssembly's got you covered: https://platform.uno/blog/uno-platform-studio-featuring-hot-...

Running Visual Basic in a C# application compiled to WebAssembly? Sure, why not: https://bandysc.github.io/AvaloniaVisualBasic6/

Re: The tragedy of running an old Node project

#307

Post by jvanderbot »

ivan_gammel wrote: post #179
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.

`make` works pretty well on ... everything I've written that I kept since then.

`cmake ..` otoh, tends not to.

Re: The tragedy of running an old Node project

#308

Post by forty »

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…

After node 10, things started to stabilize. These day a node upgrade is a tiny commit just changing the version number in the Dockerfile and package.json

Re: The tragedy of running an old Node project

#309

Post by jakimfett »

Macha wrote: post #68
viraptor wrote: post #65

Earlier quoted context omitted.

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.

Even some of my Rust projects end up in this state, where updating one library ends up with needing to update interacting libraries.

That sounds pretty frustrating.

When I find my shell scripts from 20+ years ago, they still just run as intended.

Re: The tragedy of running an old Node project

#310

Post by liontwist »

peutetre wrote: post #303
liontwist wrote: post #232

Earlier quoted context omitted.

?? JavaScript was outperformed by every language since it was introduced. It doesn’t matter. What matters is what people put in their web pages.

But now JavaScript is no longer the privileged language in the browser. With WebAssembly every language runs in the browser and runs better.

And what will prove that is adoption. As others have said, that has been “just around the corner” for years.
Post reply on HN