6 ms·

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writin

Lack of a good batteries-included stdlib. You're either importing a ton of little dependencies (which then depend on other small libraries) or you end up writing a ton of really basic functionality yourself.

skydhash 1y ago
But why can’t we have a good library instead of those mini thingies?
- zahlman 1y ago
  Because you have to figure out what should be in it, and coordinate the distribution. It's not like there's a reference implementation of JavaScript maintained by a well-known team that you consciously install everywhere that you need it.
  - skydhash 1y ago
    Node is pretty much everywhere regarding JavaScript cli and web apps (server side). As for the web it’s hard to argue for a slim library when most sites are dumping huge analytics bundle on us. At this point, it’s just status-quo and lazyness
- eviks 1y ago
  Because a mini thing can be written in mini time by a mini number of people
  - pixl97 1y ago
    And a mini thing can be switched to another 'mini' package easy enough if the current package decides to do something dumb. If your mega package decides to drop something you need you pretty much have to follow.
    - skydhash 1y ago
      > If your mega package decides to drop something you need you pretty much have to follow. Or you can code it in. Mega packages can be very stable. Think SDL, ffmpeg, ImageMagick, Freetype...There's usually a good justification for dropping something alongside a wide deprecation windows. You don't just wake up and see the project gone. It's not like the escape codes for the unix terminal are going to change overnight.
- progbits 1y ago
  For C++ there are Boost, Folly, Absl, several more large libraries with reputable orgs behind them. I'm surprised someone doesn't make a big npm lib like that. Not hating on the author but I doubt similar compromise would happen to Facebook or Google owned package.
  - ChocolateGod 1y ago
    > doesn't make a big npm lib like that. People have done, but the ecosystem has already engrossed around the current status quo and it's very hard to get rid of habits. example https://github.com/stdlib-js/stdlib https://github.com/stdlib-js/stdlib
- mhitza 1y ago
  Because "look at how many open source packages I maintain!" At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care. In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.
- jamesnorden 1y ago
  The JS ecosystem values quantity over quality, for some bizarre reason.
rudedogg 1y ago
This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.
- imiric 1y ago
  To be fair, this is not a problem with the web itself, but with the Node ecosystem. It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them. Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users. The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.
  - palmfacehn 1y ago
    I'm often surprised at the number of JS experts who struggle with the basics of the browser API. Instead of reasoning through the problem, many will reach for a framework or library.
    - skydhash 1y ago
      Especially with the MDN, an amazing resource.
    - PeterisP 1y ago
      At least historically it used to be the case that you don't ever want to use the browser API directly for compatibility reasons but always through some library that will be a do-nothing-wrapper in some cases but do a bunch of weird stuff for older browsers. And traditions are sticky.
- mrguyorama 1y ago
  But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to. Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar. Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?
tracker1 1y ago
Worth mentioning... https://jsr.io/@std https://jsr.io/@std
- wonger_ 1y ago
  How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.
  - SahAssar 1y ago
    It's not, and a third of them are tagged as unstable. JSR also still seems to not encourage proper versioning.
    - tracker1 1y ago
      They are published as separate packages, but managed in the same repo by the Deno team. Versioning works fine with JSR. A fully-formed standard library doesn't spring into existence in a day.
      - DimmieMan 1y ago
        They seem pretty cautious with that unstable flag too. UUID v7 for example is unstable and one would be pretty confident in that not changing at this stage. Many unstable functions have less churn than a lot of other “stable” packages. It’s a standard library so it’s the right place to measure twice before cementing it forever.
  - tracker1 1y ago
    They are separate packages, curated by the Deno team[1]. The interfaces are pretty consistent and useful. 1. https://github.com/denoland/std https://github.com/denoland/std
tannhaeuser 1y ago
npmjs is the stdlib, or what emerged from it. It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL). The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way. [1]: https://wiki.commonjs.org/wiki/CommonJS https://wiki.commonjs.org/wiki/CommonJS Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them
- int_19h 1y ago
  > JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations It's not unique in this sense, yet others manage to provide a lot more in their stdlib. It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.
- spankalee 1y ago
  > TypeScripters who need big daddy MS or other monopolist to sort it all out for them What is this crap statement? So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies? Claiming this says a lot more about you than people who use TypeScript.
  - typpilol 1y ago
    One of the most bizarre attacks on typescript I've seen lol.
DrewADesign 1y ago
I just never got the argument against including things like the sort of text formatting tools and such that people always import libraries for. It’s not like an embedded system for mission-critical realtime applications where most functions people write for it get formal proofs — it’s freaking javascript. Sure it’s become a serious tool used for serious tasks for some reason, but come on.
pverheggen 1y ago
Not just a stdlib, lack of an SDK as well. Both Deno and Bun have decided to ship with tooling included, which cuts down on dev dependency bloat.
pier25 1y ago
Yes this is the fundamental problem. It started with browsers giving you basically nothing. Someone had to invent jQuery 20 years ago for sensible DOM manipulation. Somehow this ethos permeated into Node which also basically gives you nothing. Not even fundamental things like a router or db drivers which is why everyone is using Express, Fastify, etc. Bun and Deno are fixing this.

skydhash 1y ago

But why can’t we have a good library instead of those mini thingies?

zahlman 1y ago
Because you have to figure out what should be in it, and coordinate the distribution. It's not like there's a reference implementation of JavaScript maintained by a well-known team that you consciously install everywhere that you need it.
- skydhash 1y ago
  Node is pretty much everywhere regarding JavaScript cli and web apps (server side). As for the web it’s hard to argue for a slim library when most sites are dumping huge analytics bundle on us. At this point, it’s just status-quo and lazyness
eviks 1y ago
Because a mini thing can be written in mini time by a mini number of people
- pixl97 1y ago
  And a mini thing can be switched to another 'mini' package easy enough if the current package decides to do something dumb. If your mega package decides to drop something you need you pretty much have to follow.
  - skydhash 1y ago
    > If your mega package decides to drop something you need you pretty much have to follow. Or you can code it in. Mega packages can be very stable. Think SDL, ffmpeg, ImageMagick, Freetype...There's usually a good justification for dropping something alongside a wide deprecation windows. You don't just wake up and see the project gone. It's not like the escape codes for the unix terminal are going to change overnight.
progbits 1y ago
For C++ there are Boost, Folly, Absl, several more large libraries with reputable orgs behind them. I'm surprised someone doesn't make a big npm lib like that. Not hating on the author but I doubt similar compromise would happen to Facebook or Google owned package.
- ChocolateGod 1y ago
  > doesn't make a big npm lib like that. People have done, but the ecosystem has already engrossed around the current status quo and it's very hard to get rid of habits. example https://github.com/stdlib-js/stdlib https://github.com/stdlib-js/stdlib
mhitza 1y ago
Because "look at how many open source packages I maintain!" At a time small JS libraries were desired, and good library marketing approach, but nowadays simple sites ship megabytes of without a care. In particular this developer is symptomatic of the problem of the NPM ecosystem and I've used him multiple times as an example of what not to do.
jamesnorden 1y ago
The JS ecosystem values quantity over quality, for some bizarre reason.

rudedogg 1y ago

This is the answer IMO. The number of targets and noise would be a lot less if JS had a decent stdlib or if we had access to a better language in the browser. I have no hope of this ever happening and am abandoning the web as a platform for interactive applications in my own projects. I’d rather build native applications using SDL3 or anything else.

imiric 1y ago
To be fair, this is not a problem with the web itself, but with the Node ecosystem. It's perfectly possible to build web apps without relying on npm at all, or by being very selective and conservative about the packages you choose as your direct and transitive dependencies. If not by reviewing every line of code, then certainly by vendoring them. Yes, this is more inconvenient and labor intensive, but the alternative is far riskier and worse for users. The problem is with web developers themselves, who are often lazy, and prioritize their own development experience over their users'.
- palmfacehn 1y ago
  I'm often surprised at the number of JS experts who struggle with the basics of the browser API. Instead of reasoning through the problem, many will reach for a framework or library.
  - skydhash 1y ago
    Especially with the MDN, an amazing resource.
  - PeterisP 1y ago
    At least historically it used to be the case that you don't ever want to use the browser API directly for compatibility reasons but always through some library that will be a do-nothing-wrapper in some cases but do a bunch of weird stuff for older browsers. And traditions are sticky.
mrguyorama 1y ago
But this can't be the whole story. In the Java world, it's pretty common to import a couple huge libraries full of utility functions, but those are each one import, that you can track and version and pay attention to. Apache Commons helper libraries don't import sub libraries for every little thing, they collect a large toolbox into a single library/jar. Why instead do people in the javascript ecosystem insist on separating every function into it's own library that STILL has to import helper libraries? Why do they insist on making imports fractally complex for zero gain?

tracker1 1y ago

Worth mentioning... https://jsr.io/@std https://jsr.io/@std

wonger_ 1y ago
How is this different than npm? It looks like a bunch of third-party packages, just prefixed with std.
- SahAssar 1y ago
  It's not, and a third of them are tagged as unstable. JSR also still seems to not encourage proper versioning.
  - tracker1 1y ago
    They are published as separate packages, but managed in the same repo by the Deno team. Versioning works fine with JSR. A fully-formed standard library doesn't spring into existence in a day.
    - DimmieMan 1y ago
      They seem pretty cautious with that unstable flag too. UUID v7 for example is unstable and one would be pretty confident in that not changing at this stage. Many unstable functions have less churn than a lot of other “stable” packages. It’s a standard library so it’s the right place to measure twice before cementing it forever.
- tracker1 1y ago
  They are separate packages, curated by the Deno team[1]. The interfaces are pretty consistent and useful. 1. https://github.com/denoland/std https://github.com/denoland/std

tannhaeuser 1y ago

npmjs is the stdlib, or what emerged from it. It started as CommonJs ([1]) with Server-side JavaScript (SSJS) runtimes like Helma, v8cgi, etc. before node.js even existed but then was soon totally dominated by node.js. The history of Server-side JavaScript btw is even longer than Java on the server side, starting with Netscape's LifeScript in 1996 I believe. Apart from the module-loading spec, the CommonJs initiative also specified concrete modules such as the interfaces for node.js/express.js HTTP "middlewares" you can plug as routes and for things like auth handlers (JSGI itself was inspired by Ruby's easy REST DSL). The reason for is-array, left-pad, etc. is that people wanted to write idiomatic code rather than use idiosyncratic JS typechecking code everywhere and use other's people packages as good citizens in a quid pro quo way. [1]: https://wiki.commonjs.org/wiki/CommonJS https://wiki.commonjs.org/wiki/CommonJS Edit: the people crying for an "authority" to just impose a stdlib fail to understand that the JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations; this concept seems lost on TypeScripters who need big daddy MS or other monopolist to sort it all out for them

int_19h 1y ago
> JS ecosystem is a heterogeneous environment around a standardized language with multiple implementations It's not unique in this sense, yet others manage to provide a lot more in their stdlib. It's not that you need a "big daddy". It's that the ecosystem needs a community that actually cares about shit like this vulnerability.
spankalee 1y ago
> TypeScripters who need big daddy MS or other monopolist to sort it all out for them What is this crap statement? So you want type-checking because it helps you catch a class of errors in an automated way, and suddenly you have a daddy complex and like monopolies? Claiming this says a lot more about you than people who use TypeScript.
- typpilol 1y ago
  One of the most bizarre attacks on typescript I've seen lol.

DrewADesign 1y ago

I just never got the argument against including things like the sort of text formatting tools and such that people always import libraries for. It’s not like an embedded system for mission-critical realtime applications where most functions people write for it get formal proofs — it’s freaking javascript. Sure it’s become a serious tool used for serious tasks for some reason, but come on.

pverheggen 1y ago

Not just a stdlib, lack of an SDK as well. Both Deno and Bun have decided to ship with tooling included, which cuts down on dev dependency bloat.

pier25 1y ago

Yes this is the fundamental problem. It started with browsers giving you basically nothing. Someone had to invent jQuery 20 years ago for sensible DOM manipulation. Somehow this ethos permeated into Node which also basically gives you nothing. Not even fundamental things like a router or db drivers which is why everyone is using Express, Fastify, etc. Bun and Deno are fixing this.