On: Node.js 16 Available Now

[capableweb]

The question is, why bloat the standard library with something that would take a couple of lines to implement yourself or as a library? More languages should release new features as libraries instead of forcing it into the "global" space of the standard library.

[geewee → capableweb]

I think this is the only "Javascript has too few third party libraries" take I've ever heard.

[capableweb → geewee]

Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.

[hn_throwaway_99 → capableweb]

I think what you are arguing (which I agree with) is that the Node ecosystem would benefit from a set of "core" libraries that could just be installed as a separate NPM module, that are blessed by the Node core maintainers, but aren't part of a specific Node version.

Deno basically does this with the Deno standard library, e.g. https://deno.land/std@0.93.0, and I agree that I think it's the right approach.

There is nothing "special" about wrapping setTimeout as a Promise, indeed pretty much everyone has done it at some point, so would be nice if there was a single, blessed standard version that I could just add as @node/standard in my package.json as long as I was on any supported Node version.

[throwanem → capableweb]

The core team does release a library. It comes with every install, and that's why we call it "standard".

[capableweb → throwanem]

The original point was that not everyone want all these syntactic sugar "features" shipped with the core runtime...

[jakelazaroff → capableweb]

What’s the syntactic sugar feature here? Top-level await is part of the language spec.

[throwanem → jakelazaroff]

One into which you have to opt in, yet.

[eyelidlessness → throwanem]

I don’t think that’s true. It’s supported in any ESM module, per the ESM standard, without any config or runtime flags. If you mean using ESM to be the opt-in mechanism, that’s not a meaningful distinction. CJS modules and require have always been synchronous and likely always will be. Changing that would break too many things.

[fny → capableweb]

Because I don't want to have to download some yahoos library just to have a timeout that behaves like a promise.

I prefer my batteries included. Also importing from "timers/promises" isn't a global namespace.

[cipher_system → capableweb]

I can never remember if i'm using promise-sleep, sleep-promise or any of the other available packages. Or if they stop working on a node upgrade. Also nice if people use and do the same simple things across projects.

The most common stuff I like to be part of the standard lib, either node or javascript, but it works fairly well now I guess so no biggie.

[megous → capableweb]

This one is not that bad. At least it takes AbortSignal, so it can be cancelled. Bonus points for that.

That said, I'll probably spend more time searching the node docs for how to import/use it than just implementing it myself.

OTOH I use promisified timer in almost all of my web scraping scripts, to reduce the load on the server, so I'm glad I'll be able to drop this thing from my utility library.

[RedShift1 → capableweb]

That kind of reasoning got us into the whole pad-left misery.

[capableweb → RedShift1]

No, mutable package management is the main reason, together with "humanness" as the author pulled the package from the registry. The core team would hardly pull a package like that.

[ReptileMan → capableweb]

Like left pad

[w-j-w → capableweb]

Large standard libraries are good. The more things are in the standard library for a language, the more likely it is that other 3rd party libraries play nice together.