The tragedy of running an old Node project

I always try to remember to put the node version in my package.json - but I do agree that the dependency chain on node-gyp has been a blight on node packages for awhile. Really wonder how that wart became such a critical tool used by so many packages.

>Really wonder how that wart became such a critical tool used by so many packages.

The original dream for Node was that it would simply be a glue wrapper around libuv that allowed for easy packaging/sharing of modules written in C++. But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native. Ryan Dahl stated this was indeed his biggest mistake/regret with Node, thus we have Deno now.

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

I run into this issue with older Node projects on ARM Mac machines (Still!), but I run into similar issues with Python projects as well. Heck some days I still find older versions of native libraries that don't have working ARM builds for MacOS!

Node used to have a lot more native modules, in newer code you typically don't see as much of that, and accordingly this is much less of an issue now days.

> I always try to remember to put the node version in my package.json

This 100x over!

> But everyone just started writing everything in JS, and the ecosystem ended up as a mish-mash of native/non-native.

Because the native written stuff breaks all the darn time and it creates cross-plat nightmares.

My stress levels are inversely proportional to how many native packages I have to try to get building within a project, be that project in Python, Java, or JS.

JS+Node runs on everything. Prepackaged C++ libraries always seem to be missing at least one target platform that I need!

> For those reading this who don't know much about node

I would prefer to remain blissfully ignorant, thank you!

Seamless native builds are quite doable, but the tooling needs to be very deliberately designed around that. For a good example of how far this can be taken, consider https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

I'm a huge Zig fan! Thank you for making native programming fun again! Zig is the exception to native build systems being painful.

But even a great build system doesn't help when old native libraries don't support newer hardware or OSs. At some point the high level -> native abstractions break and then builds break. :(

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.

Why did you click on "The tragedy of running an old Node project" then

The CPAN 'Alien' infrastructure is great for this, you have pseudo-modules that you can depend on that use vendor packages if available and build the damn thing for you if not.

It's considered ... rude ... in most cases to write a module that needs to build against a native library without also having an Alien dist to handle making sure said library is there by the time it's trying to build against it.

Opinions on perl as a *language* ... vary, let us say ... but I wish people who didn't like writing perl would at least look at how our infrastructure works and steal more of the good parts to make dealing with their preferred language less painful.

What is the Deno solution though? (I assume it's not sharing modules written in C++?)

Deno's solution is coming out years later when JS is fast enough that there is no need to involve C++ for most applications.

To take delight in node users misery perhaps?