[gherkinnn]

> In regards to the whole ecosystem: TC39 should take a look into adding a better standard library to JS itself, which would reduce the amount of one-liner packages.

I concur, the best part of working with Deno way back was its standard library [0] and overall complete dev environment. It is just so damn obvious that a runtime comes with an integrated test runner and assertion library.

0 - https://docs.deno.com/runtime/reference/std/

[WorldMaker]

To be fair, Node has `node:test` [0] and `node:assert/strict` [1] modules out of the box for several LTS versions now. `node --test` can easily replace Mocha and `node:assert/strict` is fine, but `chai` is still sometimes nicer (include ergonomics like `expect`). (Deno's @std includes an `expect` style assertion library.)

Of course, the trouble is that there are so many test runners in the Node ecosystem and many of them cannot be as easily replaced as Mocha, so the shift to the out-of-the-box test harness and assertion library will of course be painfully slow. People like the over-complicated nature of both Jest and Vitest for all sorts of reasons. Major companies thought Karma was a good idea. (I still don't understand why more developers didn't cringe at "Yo dog, I heard you like V8 for your unit tests, so we're gonna spin up a second, different copy of V8 from your existing V8 environment.")

[0] https://nodejs.org/api/test.html

[1] https://nodejs.org/api/assert.html#strict-assertion-mode

[gherkinnn]

Much came after Deno added them. I don't know what will happen to Deno, but I am glad they showed the Node world than life can be a little more pleasant

[tln]

I'm not sure any of the packages here would be part of a "better standard library".

Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does

Maybe slice.js, which just does python-style indexing with negative numbers. TC39 already made array.at() and array.slice() handle negative numbers.

[WorldMaker]

> Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does

There's also a platform feature for that now: Intl.RelativeTimeFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It asks you to do the basic time math to determine your granularity so there's still a role for a library, but also that time math gets easier with Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

(Specifically `Temporal.Now.instant().since(somePastInstant)` returns a Temporal.Duration that you can relatively easily determine the highest granularity you want and pass that to an Intl.RelativeTimeFormat instance. Also Intl.DurationFormat which is what a Temporal.Duration's `toLocaleString()` uses may also be good enough in many "x hours ago" type situations, though it is over-precise for them.)

[tln]

Thanks for that!

So, back to the GP post - TC39 should make a bigger stdlib.

Lets say timeago.js is warranted (as a polyfill and terser API) AND TC39 is taking action.

On slice.js, TC39 took action AND usage is unwarranted since the functionality is widely available. Maybe a stride.js would be needed.

There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

[WorldMaker]

> Lets say timeago.js is warranted (as a polyfill and terser API)

Though it may be useful to point out that timeago.js specifically is not a wrapper for Intl.RelativeTimeFormat. It implements its own unique internationalization beyond/instead of the platform capability. (Similarly, so do Moment, Luxon, and date-fns.)

I would argue that it is unwarranted to use such libraries, because we can do better in Vanilla with platform features now. Though yes, Safari still doesn't implement enough of Temporal today for it to be considered Baseline Widely Available. (There also are direct Temporal polyfills. Surprisingly I've found vanilla polyfilling with Date by hand isn't terrible enough to warrant a Temporal polyfill, but also my most complex Temporal math is usually server-side in Deno.)

But yeah, that's mostly quibbling outside of the point being made.

> There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

Ah, yeah, I think that is a fair call and I mostly agree with it. "The stdlib is impoverished" argument has changed a lot since the "leftpad" days. So much so it has started to feel more like "the stdlib was impoverished for too long" (and/or "Node was too slow to adopt Browser platform stdlib features and accidentally forked the stdlib for too long"). Most of the damage happened in the past, but a lot of those libraries remain in the ecosystem as developers are slow to adopt new platform features or switch away from old "comfortable" libraries (timeago.js or slice.js versus more vanilla approaches; the quibbling above wasn't entirely tangential, I suppose).

But also the proliferation of modules in npm goes far beyond that. Of course there are a lot of blockchain libraries that will never be stdlib. Of course there are client modules to proprietary APIs that will never be stdlib. The giant size of the npm ecosystem includes a lot more than just "stdlib" style libraries.

I even think the "leftpad" debacle itself did a lot to accelerate npm out of the "tiny modules" approach in general. It also may have itself been a sign that that attitude was already dying. (It was caused by one of the earliest and most prolific "tiny modules" authors leaving the ecosystem in a huff because the ecosystem was changing.)

[ireadmevs]

Worth noting that nowadays nodejs std lib keeps growing and includes the aforementioned assertion and testing support.

https://nodejs.org/api/