I don't mean this rhetorically, but what are the benefits of using node over something like deno now? It has been so long since I lived in the node ecosystem. I imagine it has gotten quite a bit better. Is the main benefit just ecosystem/compatibility stuff? Deno sometimes has some odd compatibility issues, but not often. The low-overhead, sane defaults, just-build kind of nature of it has become very appealing to me. Being able to build CLIs in portable binaries using a language my coworkers understand is really nice (despite that they're like 60mb, haha). I prefer Go personally, but ultimately prefer being able to collaborate.
It's funny, I would actually argue the opposite point. When Deno and Bun first came out, they promised a hard break from the Node ecosystem, like how Deno leaned heavily into browser compatibility, and Bun into framework features like Bun.App.
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.
> When Deno and Bun first came out, they promised a hard break from the Node 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
It’s purely ecosystem at this point. Deno, Bun, any runtime is more modern. It’s nice they are catching up but by the time typescript is a native citizen in node, others may take the crown. The codebase is ooof.
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.
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.
Lambda’s being pulled from storage or containers being pulled from ECR is negligible. The difference here is in the container layers. If you build a small container with alpine it’s not that bad.
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.
Maybe you didn't understand when I said "I do not want the extra hassle of containers". I don't care about start-up time, I don't care that it "isn't as bad as it used to be". I just do not want to have to create or maintain a "container" myself. That's why I chose Lambda to begin with. It's a FaaS, and that's where it ends for me.
