Modern JavaScript reminds me a lot of BASIC, Pascal and other 70s and 80s languages. Even C pre-ANSI.
We’ve been blessed in recent years that either languages are fully open source and come with a reference implementation, or a standards body governs the implementation detail. Sometimes even both.
Whereas JavaScript is really more a group of languages, each with their own implementation quirks.
ECMA was intended to bring some sanity to all of this. And it’s definitely better than it was in the JScript days of IE vs Netscape. But there isn’t anything (that I’m aware of) that defines What should be a part of the JavaScript standard library.
Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.
> Wouldn’t it be great if there were a libc in the JS world. Something portable and standardised.
I mean, it’s not necessarily “in the JS world”, but WASM is basically that.
No it’s not. Problem right now is that every WASM files pulls in its own stdlib. Which is a waste once you use more than one.
Re:The Everything NPM Package
by swiftcoder on Sunday January 07, 2024 @02:50AM
(#38899386)
WASM is explicitly not that. WASM itself has no APIs, it's just an execution envionment.
You may be thinking of WASI?
When you combine those together you end up with a situation where "normal" js code not from a library can't be trusted on the front end because it won't work for x% of your users, and offers a clumsy API on the backend that you'd prefer be wrapped in a helper. Developers learnt that they should reach for a library to e.g. deal with localstorage (because on Safari in private mode the built-in calls throw an error instead of recording your data and discarding it after the tab closes) or make a HTTP request (because node doesn't support fetch yet and you don't want to use the complicated streams and callbacks API from the standard lib) and they propelled that culture forward until everyone was doing it.