upvote

points

by ivanjermakov4 hours ago |
comments
upvoteby johnfn3 hours ago|
next
[-]
You might remember the io.js fork of Node.js back in 2014. Node was stagnating, a bunch of people forked it into io.js, which eventually got merged back into Node and got it back on track. Or, going further back, CoffeeScript, a "fork" of JS that had its best ideas adopted back into ES5.

A small scrappy team can prove out a good idea because failure is not a catastrophic risk to them. In short, forks are part of a healthy ecosystem.

reply
upvoteby colinmcd1 hours ago|
parent|
next
[-]
I almost called it "oi" but I'm not sure anyone would have gotten the joke :P
reply
upvoteby hootz2 hours ago|
parent|
prev|
next
[-]
It is still happening, a lot of things are still being adopted by Node after being available on other runtimes. They aren't forks, but they still provide pressure towards progress.
reply
upvoteby psygn891 hours ago|
parent|
prev|
[-]
Beautifully stated reminder :)
reply
upvoteby hungryhobbit3 hours ago|
prev|
[-]
Fundamentally you can't fix a lot of things with this approach.

Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments").

When an organization digs into bad decisions, the only way to fix them is to start something new. The entire JS ecosystem will never have documentation on its config as long as everyone keeps building on top of Node.

(And there are many other issues like this in the Node ecosystem; the utter absurdity of not being able to document config is just my personal pet peeve.)

reply
upvoteby colinmcd50 minutes ago|
parent|
next
[-]
EDIT: Sorry, I understand you're talking about package.json. Would be fun to try to get the Node & package mgmt teams aligned to add support for comments in the package.json. Bun tried and failed to do this (requires ecosystem coordination).

Nub could absolutely support a config file and use it to set NODE_OPTIONS or flags in the node child process. There's no reason to throw out the baby with the bathwater due to DX concerns like this. That's a key part of the concept Nub is trying to prove. (To be clear I'm quite content to conform to Node's no-config-file policy at the moment.)

reply
upvoteby johnfn3 hours ago|
parent|
prev|
[-]
> Simple example: Node is the only serious OSS software I know of that has no way to document its config (in the config file itself). It's moronic! The Node people just adopted JSON without a thought, and then refused to consider any alternatives (even "JSON with comments").

Tangential but this also drives me absolutely nuts. If I have to see `"//": "some comment"` one more time I'm gonna lose it.

reply