My nodejs projects have tests that run faster and have fewer breaking dependencies.
The two things I have to do are to always annotate type imports with type (I have a script for that), and to use file extensions on imports.
That said, there’s something to be said about being the first mover and having the ecosystem so node isn’t going away anytime soon, nor is the npm/npx ecosystem.
Go has the ability to, with a goja fork [1], to execute ESM but you would still need to transpile using another go tool to run it. I have such a runtime but it’s nowhere near as fast as bun or deno. I use it mainly so I can have agents do my local bidding.
Definitely not just about ecosystem.
When AWS Lambda supports Deno, then maybe someday further down the line, I might think about trying it once for something unimportant. If that goes well, then we'll see.
https://gist.github.com/begoon/993e29f5cf9a384b9e0e96e70a71b...
But for ts/js land, lambda is node unless you want to build your own containers.
That isn't the same as AWS Lambda supporting Deno, and you should know it. No, I don't want the extra hassle of containers.
Not to try to convince otherwise. Just that it isn’t as bad as it used to be. Our Golang lambdas have 2ms more startup time than our JavaScript lambdas.
Lambda is just a fancy CGI-BIN
At some point they both decided that Node compatibility was more important than their unique features, but in the time since their release Node got type stripping, require(esm), sqlite, single executable apps, a permission system, a test runner, and basically ever other Deno/Bun feature they could port over.
So at this point why use runtimes that imitate Node when you could just use Node? You'll get most of the modern niceties, but also get 100% compatibility with the existing ecosystem.
I don't think that's true for Bun. In fact Bun was planned to NOT break from Node ecosystem as much as possible:
"Bun is designed as a drop-in replacement for your current JavaScript & TypeScript apps or scripts — on your local computer, server or on the edge. Bun natively implements hundreds of Node.js and Web APIs, including ~90% of Node-API functions (native modules), fs, path, Buffer and more." - 2022
Like C++, it could be a true superset of JS, importing JS code freely into TypeScript projects. It would also allow TypeScript to do whatever it wanted and not have to worry about transpilation. If it needs to work in the browser, it can be bundled into web assembly.
(*) with small exceptions like enums, which some think were a mistake for that reason
Also, every high-performance JS runtime already knows that you're only indexing that object with integers and already optimizes it without you telling it to.
I'm embarking on a project where the various tsconfig files are getting quite unwieldy. I'd have already jumped to Deno but it just won't work right when the actual deployment is to Cloudflare Workers.
gabrielsroka•6mo ago