Comment by simiones
2 months ago
That's not the problem. There is a cultural (and partly technical) aversion in JavaScript to large libraries - this is where the issue comes from. So, instead of having something like org.apache.commons in Java or Boost in C++ or Posix in C, larger libraries that curate a bunch of utilities missing from the standard library, you get an uncountable number of small standalone libraries.
I would bet that you'll find a third party `leftpad` implementation in org.apache.commons or in Spring or in some other collection of utils in Java. The difference isn't the need for 3rd party software to fix gaps in the standard library - it's the preference for hundreds of small dependencies instead of one or two larger ones.
Lodash is a good counterpoint, but it’s falling out of style since the JS runtimes support more basic things now.
JS apps, despite the HN narrative, have a much stronger incentive to reduce bundle/“executable” size compared to most other software, because the expectation is for your web app to “download” nearly instantly for every new user. (Compare to nearly any other type of software, client or server, where that’s not an expectation.)
JS comes with exactly zero tools out of the box to make that happen. You have to go out of your way to find a modern toolchain that will properly strip out dead code and create optimized scripts that are as small as possible.
This means the “massive JS library which includes everything” also depends on having a strong toolchain for compiling code. And while may professional web projects have that, the basic script tag approach is still the default and easiest way to get started… and pulling in a massive std library through that is just a bad idea.
This baseline — the web just simply having different requirements around runtime execution — is part of where the culture comes from.
And because the web browser traditionally didn’t include enough of a standard library for making apps, there’s a strong culture of making libraries and frameworks to solve that. Compare to native apps, where there’s always an official sdk or similar for building apps, and libraries like boost are more about specific “lower level” language features (algorithms, concurrency, data structures, etc) and less about building different types of software like full-blown interactive applications and backend services.
There are attempts to solve this (Deno is probably the best example), but buy-in at a professional level requires a huge commitment to migrate and change things, so there’s a lot of momentum working against projects like that.
1000% agree. Javascript is weak in this regard if you compare it to major programming languages. It just adds unnecessary security risks not having a language with built in imports for common things like making API calls out or parsing JSON, for example.
It does have functions for that, “fetch” and “JSON.parse,” available in most JS runtimes.