Javascript has a standard library. What Javascript doesn't have is a robust kitchen-sink library akin to other more complex general purpose programming languages, because Javascript was designed to be used in the context of a browser to script webpages, and its actual standard library reflects that.
Unsurprisingly, because we've apparently decided Javascript needs to replace all existing languages in all current and future forms of application and system development, its actual standard library is no longer sufficient for many peoples' requirements. But they would rather claim the language "has no standard library" in order to justify the insane complexity of the JS ecosystem than admit that perhaps it just isn't the right tool for every job.
JavaScript has a very weak standard library. The language & standard library lacks essentials like structural equality, until 2015 or so very weak class-based object-oriented programming, and to this day has numerous footguns that are tricky to remove without breaking the web, like `==`, `this` scoping, and Array.prototype.sort() being in-place.
JavaScript is turning complete and I prefer it’s semantics to the lawless land of Perl, but it ultimately does not serve its users as a general purpose programming language for getting things done - it serves the web foremost, and as a distant second there’s specialized programming environments like Node and Bun with priorities like “asynchronous” that struggle with POSIX/system scripting basics like fork(2), execve(2), working with files in simple ways. Don’t even get me started on FFI/calling into dynamic libraries, which is the bread and butter of scientific computing. FFI is in the stdlib in Ruby; but requires writing or compiling C++ for Node, or a monstrous stack of compilers for the web.
JavaScript is interesting because there are so many healthy alternative runtimes, but when it comes to getting things done with data, both Python and Ruby are much more straightforward and prioritize developer happiness & utility, instead of standardized web compatibility.
If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
Javascript has a perfectly decent standard library for its intended use case - scripting webpages. It was never meant to be a general purpose application or systems programming language. It was never meant to be used outside of the browser, much less to replace C++ and other languages in their respective domains.
The "current programming environment" is the problem, and it doesn't exist because Javascript is superior to other languages, and should be used everywhere, but only because web developers are easier to find and cheaper to hire.
And in any case, you could ship a "standard library" for javascript that covers most common use cases in a single static file. We used to do that, it was called JQuery. Even assuming for the sake of argument that Javascript's standard library is lacking, that doesn't justify the mess that is Node's micropackages.
Is there actually a decent alternative to JS for front end stuff? Another part of the solution to this language turning into the blob monster from the end of Akira surely has to be making those with an interest in the language's success less complacent.
I mean, why argue for _not_ having a standard library?
JavaScript has a ton built in but developers get in a habit of using libraries that introduce their own api and polyfills on top. I blame awful browser support of years past. Today most new features are available pretty quickly across all the major versions.
Yes, I've been developing websites since before JS existed, so it does in fact make me happy that JS has made some progress related to developer productivity in 20 years. Are they adding other baggage? It seems so, but the addition of a standard library is a things well past its time.
But what features does JS have that no other language has, other than the ubiquity of the browser as a platform? JS has been mostly frozen ever since it was created in the mid 90s and you also don't have much to work with when it comes to the standard library.
No JavaScript framework is on the same level of confusion that DEC by itself with it multiple weird languages and semantics inflicted upon programmers. Never mind the other vendors. JavaScript actually has a standards document.
Evolving toolchain? JavaScript is 20 years old and has made nearly no improvement in terms of peductivity, highlighted by the complete lack of a standard library and the still horrid browser debugging. We should be very suspect of a language that for whatever reason can't get the basics required for a first class language right in the course of 20 years.
It's not a coincidence that Underscore looks like Ruby, its creator has a Ruby background and similarly developed CoffeeScript along those lines. (Both of which are perfect for me as someone who uses Rails on the back-end.)
Yes, JavaScript never had anything resembling a decent utils library, so an elegant and popular implementation like underscore was heaven when it arrived. It's the usual problem of browsers evolving too slowly and fragmenting too much for something like Java's collections to emerge as a standard.
The situation has gotten better now, with even IE moving towards auto-upgrade, but it's still not feasible for JS core to ship with large, frequently-updated, JS libs. The closest thing is Node's standard library, but that's not going to be ubiquitous in browser's anytime soon.
"what should be a part of the language and what shouldn't"
In the absence of a standard library, you end up with a dozen competing libraries trying to fill the void, and that stifles end-user applications.
We saw that a few years ago with the DOM. For the first ~8 years of JS, there was no significant DOM library, so app developers had to suck up the unfriendly raw DOM API. Then the toolkits started to emerge, giving way to huge fragmentation between jQuery, Prototype, MooTools, Dojo, and YUI. Suddenly libraries were jQuery plugins or MooTools plugins and your app was using the jQuery stack or MooTools stack. So the next 8 years of JS saw vast effort duplicated as developers built parallel libraries for each toolkit.
So I think the answer is to launch a language without the kitchen sink, but watch the community and gradually standardise useful functionality as the need emerges and adapt popular open source libraries as they becomes popular. Java did this well in its heyday. In JS's case, a lot of the DOM conveniences are now becoming core JS, but the nature of JS means libraries move slower than other languages.
That’s not a definition for scripting language I’ve ever heard before and it’s neither true nor desirable. Even JavaScript has a standard library - think about things like Set, Map, Regexp, Promise, etc. – because they’re universally useful, as opposed to the runtime environment where things like the DOM are less relevant to many use cases. JSON is a great example of something crossing over as an increasingly high percentage of projects will use it.
Not having a standard library on par with other scripting languages just added overhead and incompatibility for years as people invented ad hoc alternatives, often buggy. The accelerated core language growth has been hugely helpful for that but you still have issues with things as basic as the module system which exist for understandable reasons but are just a waste of developer time.
JavaScript is the only possible standard. Here's why:
Apparently, the world need a Turing complete Web, so it can be used for things totally out of its original scope (publishing).
Technically, it makes little sense. It often wastes bandwidth, CPU, and efficiency of interaction. (Gmail is cool, but a native version of it could be better in all three ways.)
But, because people are idiots who don't know how to install a program on their machine, we need to give them a way to use such programs without even having to point or grunt before they get started. (Well, it's not a need, actually. That's a choice. Idiots can be educated. And they will be, eventually.)
To this day, the only Turing complete thing that is installed by default on every computer on this planet (meaning Windows PC and Macs) is JavaScript. Unless we displace it, and until "average users" educate themselves, I think we're stuck with JavaScript.
JavaScript is a small language because it needs browser support and backwards compatibility. A small language that can't change much over time can't afford to have opinions on how to build dynamic interfaces.
Therefore, all the complexity of building interfaces will be in the libraries and because opinions on such complex issues vary, there are many libraries to do the same thing.
Eventually the interior ones are recognized and culled. They typically are supported for quite some time after becoming uncool, it's just that no one wants to work with lame, obsolete tehnology for good reasons.
The solution I see to this are compile-to-JS languages that make it possible to use a different ecosystem of libraries than te JS one, like Scala.js. However, those tools are also still evolving, so one way or another you're dealing with a lot of library churn in frontend development right now, so learn to pick winners and stick to them until it's as weird to use them as jquery for complex UI was in 2012.
Javascript is still missing simplicity, consistency and a unified core set of ideas. It will always be that way too.
Javascript will always be something grudgingly accepted or used with some misgiving. ES6 has some very nice features and the good parts of javascript stand out as much as the unfortunate inconsistencies lurking inside the language. People know how to use it. Some use it quite well but I always get the feeling I have to step around carefully and not make a dumb mistake in js which is easier to do than almost any other language except say PHP. Web assembly should open up some badly needed possibilities. All we really need is a consistent API. A world without js? I hope so.
reply