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…
Vanilla JS is pretty good on the client side, but leaves a lot to be desired on the server side in Node.js, even if you include the standard Node.js modules.
For example, there’s no built-in way to connect to a database of any sort, nor is there a way to easily create a basic HTTP REST API - the built in HTTP module is just raw HTTP, with no URL routing, no way to automatically JSON encode responses, no standardized error handling, no middleware layer, etc.
This means that practically every Node.js app imports third-party modules, and they vary wildly in quality. Some are fantastic, some are okay, and some are absolutely horrible yet somehow get millions of downloads per week.
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.
someone at Google or Mozilla hasn’t decided to write a JavaScript Standard Library.
JS, 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.
The main issue is server-side, and neither Google nor Mozilla have a big interest in server wide 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.
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…
That’s basically how Javascript gets extended. I put off learning jQuery for so long that all the features I’d want are now standard.
Vanilla JS is pretty good on the client side, but leaves a lot to be desired on the server side in Node.js, even if you include the standard Node.js modules.
For example, there’s no built-in way to connect to a database of any sort, nor is there a way to easily create a basic HTTP REST API - the built in HTTP module is just raw HTTP, with no URL routing, no way to automatically JSON encode responses, no standardized error handling, no middleware layer, etc.
This means that practically every Node.js app imports third-party modules, and they vary wildly in quality. Some are fantastic, some are okay, and some are absolutely horrible yet somehow get millions of downloads per week.
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.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.
node now supports stripping types, which is good enough for one-off TS snippet.
(available only in nightly for now)
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.
JS, 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.
The main issue is server-side, and neither Google nor Mozilla have a big interest in server wide 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.
core-js is exactly that, but it focuses on implementing baseline features that can be polyfilled.
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”
Static? I mean for most of the web it honestly seems like the move. HTMX?
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
Let’s use Flash!
Actionscript, my beloved
Java applets 🌈
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.
Support for int64s out of the box and without jumping through hoops would be nice.