> a standard library that doesn't require import statements
I consider this a non-feature in JS. The global namespace is enormous and growing rapidly. As I recall, PHP’s global namespace is similarly enormous (and notorious for its inconsistencies and redundancies). I understand that there are ergonomic advantages to not having to import built-ins, but I think framing it as a feature deserves a healthy asterisk :)
> fibers, a way do asynchronous execution without every function in the callstack having to be aware of it
This isn’t built into JS, but there’s an implementation of it, mostly used and popularized by Meteor. Again it has some ergonomic benefits, but I think it can too easily hide/obscure deoptimizations—eg performing IO operations in sequence which would be better performed concurrently.
It’s increasingly almost the same, aside from very DOM/*ML rendering contexts, and getting more similar as time goes on. Which is good for portability but JS (ECMAScript/TC-39) is huge in itself, and the various compatible things in the JS runtime ecosystem (browsers/Node/Deno) is also huge. Node was historically more limited here but given how much the language itself is expanding they have to choose compat.
I consider this a non-feature in JS. The global namespace is enormous and growing rapidly. As I recall, PHP’s global namespace is similarly enormous (and notorious for its inconsistencies and redundancies). I understand that there are ergonomic advantages to not having to import built-ins, but I think framing it as a feature deserves a healthy asterisk :)
> fibers, a way do asynchronous execution without every function in the callstack having to be aware of it
This isn’t built into JS, but there’s an implementation of it, mostly used and popularized by Meteor. Again it has some ergonomic benefits, but I think it can too easily hide/obscure deoptimizations—eg performing IO operations in sequence which would be better performed concurrently.