I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.
I’m not opposed to NPM, because dumb shit like this happens everywhere. If such a package is used millions of times a day, perhaps it would make sense to standardise it and have it as part of the fucking browser or node runtime…
someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.
Core APIs (including data types like strings, collection types like Map, Set, and arrays), Browser, and DOM APIs are pretty good these days. Much better than they used to be, with more features and consistent behaviour across all major browsers. It’s uncommon to need browser-specific hacks for those any more, except sometimes in Safari which acts weird at times.
The main issue is server-side, and neither Google nor Mozilla have a big interest in server side JS. Google mostly uses Python and Java for their server-side code, and Mozilla mostly uses Rust.
Having said that, there’s definitely some improvements that could be made in client-side JS too.
There’s a js runtime called bun that is 90-something% feature equivalent to node and also has built in alternatives to many packages like express and bcrypt. I haven’t used it myself so I can’t speak to its quality but it’s always nice to see a little competition
For starting new projects i absolut agree. At work we have a legacy react app that just will not run on bun and for deno we would probably have to rewrite some stuff.
I’ve updated some legacy nodejs to Deno recently and it’s actually not bad! If you’re using serverless Denoflare is super convenient and DTN is a tool for building Deno to NPM (both esm and commonjs) so you can have easy backwards compatibility if needed, it even shims all of the Deno standard lib.
It’s really impressive what Deno and Bun people have done - for the first time I actually somewhat enjoy server side JS!
That sounds neat. For our nodejs server this could be done without too much effort.
Will keep that in mind, thanks.
But I also have to check for the cra app we’re having a lot of issues with.
Sometimes it’s hard to detach It, specially dealing with web dev.
The browser expects JS, since JS was made for the browser, so you make a front in JS. But now you need a back, and hey, you already have all models and repos in JS, might as well make the back with JS.
It’s a vicious cycle. Honestly, JS is fine for either if you are component enough (ie. not using stuff like “is-number”), don’t get the hate on It.
No, JS is for scripts, it should have never been a whole framework for a frontend. But we can’t get away from it now, because it’s the only thing we have for browsers.
This picture honestly looks more like C++ than JS, and before you yell at me, JS doesn’t have any standards let alone competing standards so ¯\_(ツ)_/¯
I’ve honestly never understood why someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.
I’m not opposed to NPM, because dumb shit like this happens everywhere. If such a package is used millions of times a day, perhaps it would make sense to standardise it and have it as part of the fucking browser or node runtime…
Core APIs (including data types like strings, collection types like Map, Set, and arrays), Browser, and DOM APIs are pretty good these days. Much better than they used to be, with more features and consistent behaviour across all major browsers. It’s uncommon to need browser-specific hacks for those any more, except sometimes in Safari which acts weird at times.
The main issue is server-side, and neither Google nor Mozilla have a big interest in server side JS. Google mostly uses Python and Java for their server-side code, and Mozilla mostly uses Rust.
Having said that, there’s definitely some improvements that could be made in client-side JS too.
Support for int64s out of the box and without jumping through hoops would be nice.
There’s a js runtime called bun that is 90-something% feature equivalent to node and also has built in alternatives to many packages like express and bcrypt. I haven’t used it myself so I can’t speak to its quality but it’s always nice to see a little competition
So is Deno! You can easily import
npm:andnode:packages and run typescript without transpiling. With Bun and Deno there’s no reason to use Node tbh.node now supports stripping types, which is good enough for one-off TS snippet.
(available only in nightly for now)
For starting new projects i absolut agree. At work we have a legacy react app that just will not run on bun and for deno we would probably have to rewrite some stuff.
I’ve updated some legacy nodejs to Deno recently and it’s actually not bad! If you’re using serverless Denoflare is super convenient and DTN is a tool for building Deno to NPM (both esm and commonjs) so you can have easy backwards compatibility if needed, it even shims all of the Deno standard lib.
It’s really impressive what Deno and Bun people have done - for the first time I actually somewhat enjoy server side JS!
That sounds neat. For our nodejs server this could be done without too much effort. Will keep that in mind, thanks. But I also have to check for the cra app we’re having a lot of issues with.
Bun is used by us in production, in dev, everywhere. It’s great. We don’t even use (p)npm to build js packages on our docker images for apps anymore.
I wish they would replace JavaScript with something that was made for what it’s used for. JavaScript should have died years ago.
I’m still waiting for webassembly to take off
Sometimes it’s hard to detach It, specially dealing with web dev.
The browser expects JS, since JS was made for the browser, so you make a front in JS. But now you need a back, and hey, you already have all models and repos in JS, might as well make the back with JS.
It’s a vicious cycle. Honestly, JS is fine for either if you are component enough (ie. not using stuff like “is-number”), don’t get the hate on It.
No, JS is for scripts, it should have never been a whole framework for a frontend. But we can’t get away from it now, because it’s the only thing we have for browsers.
What do you want to use for frontend framework then?
python, ruby, java, C? Invent a new language?
you will see me screaming “X is for Y, it should have never been a whole framework for a frontend”
Anything, as long as it’s not a bunch of scripts which form a framework after you downloaded a terabyte of shady dependencies.
React it is then 😄. It only has 2 dependencies:
- react - loose-envify - js-tokenshttps://www.npmjs.com/package/react?activeTab=dependencies
Static? I mean for most of the web it honestly seems like the move. HTMX?
Let’s use Flash!
Actionscript, my beloved
Java applets 🌈
core-js is exactly that, but it focuses on implementing baseline features that can be polyfilled.
This picture honestly looks more like C++ than JS, and before you yell at me, JS doesn’t have any standards let alone competing standards so ¯\_(ツ)_/¯
ECMAScript would like to have a word with you.
If however by “doesn’t have any standards” you meant it’s willing to sink to new low grounds every day, you would be correct.
The latter, and the underutilization of the fact that the standard library exists, and consequently the existence of so many micro dependencies.