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.
Comments
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.
[1] https://github.com/grafana/sobek
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.
AWS Lambda supports custom runtimes so you can roll your own. All you need is a container.
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.
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.
Lambda is just a fancy CGI-BIN
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.
Use Deno compile to create a standalone executable and launch on provided.al2023 like you would a rust binary
Except nodejs is working perfectly for me, and I do not want all those extra hoops to jump through.