←back to thread

272 points abdisalan | 7 comments | | HN request time: 0.591s | source | bottom
Show context
binarymax ◴[] No.42175675[source]
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.
replies(2): >>42175709 #>>42175766 #
1. ramesh31 ◴[] No.42175709[source]
>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.

replies(2): >>42175791 #>>42182330 #
2. com2kid ◴[] No.42175791[source]
> 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!

replies(2): >>42176206 #>>42181678 #
3. int_19h ◴[] No.42176206[source]
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...
replies(1): >>42176518 #
4. com2kid ◴[] No.42176518{3}[source]
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. :(

5. mst ◴[] No.42181678[source]
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.

6. watt ◴[] No.42182330[source]
What is the Deno solution though? (I assume it's not sharing modules written in C++?)
replies(1): >>42182468 #
7. DecoySalamander ◴[] No.42182468[source]
Deno's solution is coming out years later when JS is fast enough that there is no need to involve C++ for most applications.