Eliminating JavaScript cold starts on AWS Lambda
1–10 of 72 posts
Re: Eliminating JavaScript cold starts on AWS Lambda
#2This is seriously snappy, and impressive work.
Re: Eliminating JavaScript cold starts on AWS Lambda
#3It’s a TS/JS to wasm to C tool chain, that runs the same JS a dozen times faster than on node. Very cool approach, and lambda cold starts are definitely where it ought to shine.
That said I wonder if it could ever go mainstream – JS is not a trivial language anymore. Matching all of its quirks to the point of being stable seems like a monstrous task. And then Node and all of its APIs are the gorilla in the room too. Even Deno had to acquiesce and replicate those with bugs and all, and it’s just based on V8 too.
Re: Eliminating JavaScript cold starts on AWS Lambda
#4I seriously dislike this kind of comparisons.
We're faster! (please disregard the fact that we're barely more than a demo)
Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does.
Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill the project (I'm unable to use Biome 2)
This happens over and over and over. The exceptions are very, very few (Bun is one example)
Re: Eliminating JavaScript cold starts on AWS Lambda
#5It’s a TS/JS to wasm to C tool chain, that runs the same JS a dozen times faster than on node. Very cool approach, and lambda cold starts are definitely where it ought to shine. That said I wonder if it could ever go mainstream – JS is not a trivial language anymore. Matching all of its quirks to the point of being stable seems like a monstrous task. And then Node and all of its APIs are the gorilla in the room too.…
Hopefully Oliver, the creator of the project, is here to better answer, but something worth bearing in mind is that a significant part of conventional JS engines are all JIT tricks. And Porffor is AOT, so can lean on WASM and the C compiler for compilation optimisations. The author did a quick comparison of lines of code for some of the popular JS engines: https://goose.icu/js-engine-sizes
Re: Eliminating JavaScript cold starts on AWS Lambda
#6It looks similar to GraalVM for Java, right?
It would be amazing if they pull this off. Being able to compile JS to produce minimal binaries for CLIs or just to make slim containers would be nice.
Re: Eliminating JavaScript cold starts on AWS Lambda
#7I seriously dislike this kind of comparisons. We're faster! (please disregard the fact that we're barely more than a demo) Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does. Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill…
I really find it annoying when JavaScript people complain about performance. If you think something is slow then make it faster and open a pull request.
It’s great when those PRs do come, but most of the time there is just empty whining while a developer contributes nothing. This is because most JavaScript developers are deathly afraid to write original software, as that would be reinventing a wheel.
Most JavaScript developers are absolutely incapable of measuring things, so they have no idea when something else is actually faster until else runs the numbers for them. Let’s take your Bun example. Bun is great but Bun is also written in Zig which is faster than C++. Bun claims to be 3x faster at WebSockets than Nodes popular WS package, because Bun can achieve a send rate of 700,000 messages per second (numbers from 5 years ago). Bun is good at measuring things. What they don’t say is that WS is just slow. I wrote my own WebSocket library for Node in TypeScript about 5 years ago that can achieve a send rate of just under 500,000 messages per second. What they also don’t tell you is that WebSockets are 11x faster to send than to receive due to frame header interpretation. I say not to disparage Bun but to show your empty worship is misplaced if you aren’t part of the solution.
Re: Eliminating JavaScript cold starts on AWS Lambda
#8I seriously dislike this kind of comparisons. We're faster! (please disregard the fact that we're barely more than a demo) Everyone knows about 80:20, the slowdowns will come after you start doing everything your competition does. Look at Biome. We're 15x as fast as ESLint (but disregard the fact that we don't do typeaware linting). Then comes typeaware linting and suddenly they have huge performance issues that kill…
I really find it annoying when JavaScript people complain about performance. If you think something is slow then make it faster and open a pull request. It’s great when those PRs do come, but most of the time there is just empty whining while a developer contributes nothing. This is because most JavaScript developers are deathly afraid to write original software, as that would be reinventing a wheel. Most JavaScript…
> If you think something is slow then make it faster and open a pull request.
But I want someone else to make it faster without me having to do anything.
Re: Eliminating JavaScript cold starts on AWS Lambda
#9Earlier quoted context omitted.
I really find it annoying when JavaScript people complain about performance. If you think something is slow then make it faster and open a pull request. It’s great when those PRs do come, but most of the time there is just empty whining while a developer contributes nothing. This is because most JavaScript developers are deathly afraid to write original software, as that would be reinventing a wheel. Most JavaScript…
> If you think something is slow then make it faster and open a pull request. But I want someone else to make it faster without me having to do anything.
In my experience the type of developer using JS for their Web apps rarely overlaps with someone comfortable doing high performance C++ runtime work.
Re: Eliminating JavaScript cold starts on AWS Lambda
#10Nice we haven’t faced this cold start problem. We like the idea of Lambdas being offered in a simple runtime platform where you can store and run the code as needed.
And chain it with other stuff as well which is where workflow engines like n8n or Unmeshed.io works better. You can mix up lambdas in different languages as well.