Eliminating JavaScript cold starts on AWS Lambda • Hacker News Board

Re: Eliminating JavaScript cold starts on AWS Lambda

#41

Post by samwillis » Sun, Aug 17, 2025, 3:24 PM UTC

bastawhiz wrote: post #31

samwillis wrote: post #13

Oliver is doing awesome work here. A few interesting points: - Porffor can use typescript types to significantly improve the compilation. It's in many ways more exciting as a TS compiler. - There's no GC yet, and likely will be a while before it gets any. But you can get very far with no GC, particularly if you are doing something like serving web requests. You can fork a process per request and throw it away each ti…

> many of the restrictions that people associate with JS are due to VMs being designed to run untrusted code. If you compile your trusted TS/JS to native you can do many new things, such as use traditional threads, fork, and have proper low level memory access. Separating the concept of TS/JS from the runtime is long overdue. This is just outright wrong. JS limitations come from lots of things: 1. The language has al…

Web workers don't share memory (other than SAB) with the main thread, they are far from traditional threads. These APIs are designed the way they are to protect end users, stop sites from consuming resources or bad code blocking the main thread. None of that is needed to be that way on the server. There is zero reason that a JS implementation cannot implement proper threads within the same memory space. The issue is that all js engines are derived from the browser where that isn't wanted, they simply don't have support for it. Traditional threads need careful use,

Nowhere did I say that full, or even any, compatibility with Node is needed - it isn't.

We need to stop conflating JS the language with the runtimes.

A JS runtime absolutely can get by without a GC, you just never dealloc and consume indefinitely. That doesn't change any semantics of the language, if a value/object is inaccessible, it's inaccessible...

An arena allocator provides a route to say embedding a js-to-native app in a single threaded web server like Nginx, you don't need to share memory between what in effect become "isolates".

Re: Eliminating JavaScript cold starts on AWS Lambda

#42

Post by [deleted] » Sun, Aug 17, 2025, 3:27 PM UTC

austin-cheney wrote: post #7

bapak wrote: post #4

I 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…

[deleted]

Re: Eliminating JavaScript cold starts on AWS Lambda

#43

Post by ComputerGuru » Sun, Aug 17, 2025, 3:35 PM UTC

Lots of negativity in this thread; let me offer a bit of positivity to contrast!

The project homepage is awesome, it's a mix between a throwback to retro documentation (with ascii charts) and a console out of godbolt: https://porffor.dev/

The hangup on lack of GC is probably unnecessarily overwrought, WasmGC is pretty much here and there will be an entire ecosystem of libraries providing JS GC semantics for WASM compilers that this compiler can tap into (actually implementing the backend/runtime GC support is fairly trivial for baseline support).

Re: Eliminating JavaScript cold starts on AWS Lambda

#44

Post by Hamuko » Sun, Aug 17, 2025, 3:52 PM UTC

zokier wrote: post #25

breve wrote: post #15

It'd be good if AWS Lambda provided a wasm runtime option. Cold start times for WebAssembly can be sub-millisecond. It'd also be interesting to see comparisons to the Java and .NET runtimes on AWS Lambda.

Rust/C++ lambda cold starts are in the 15ms ballpark, it is very unlikely that you are going to get anything much faster than that. Spinning up firecracker vm just inherently takes some time no matter what you run inside it. https://maxday.github.io/lambda-perf/

I can't bring myself to use Rust for AWS Lambda since the runtime is still marked as "experimental".

>The Rust runtime client is an experimental package. It is subject to change and intended only for evaluation purposes.

Re: Eliminating JavaScript cold starts on AWS Lambda

#45

Post by Hamuko » Sun, Aug 17, 2025, 3:54 PM UTC

breve wrote: post #15

It'd be good if AWS Lambda provided a wasm runtime option. Cold start times for WebAssembly can be sub-millisecond. It'd also be interesting to see comparisons to the Java and .NET runtimes on AWS Lambda.

Cloudflare offers Wasm for their Workers service. Haven't tested it though.

https://developers.cloudflare.com/workers/runtime-apis/webas...

Re: Eliminating JavaScript cold starts on AWS Lambda

#46

Post by rafram » Sun, Aug 17, 2025, 4:17 PM UTC

samwillis wrote: post #38

gibolt wrote: post #33

Earlier quoted context omitted.

Based on how much imported libraries are relied upon, it makes sense to treat everything as untrusted. Unless you write every line yourself/in-house, code should be considered untrusted. I would be curious which attack vectors change or become safe after compiling though.

The point of the js engine sandbox is to protect the user in the browser - it's completely redundant on the server. Supply chain attacks are real, but only Deno has tried to fix that through permissions/rules. I don't think anything changes with compile to native on the server.

Totally disagree. A spec-compliant JS engine has to support the features that allow vulnerabilities like prototype pollution, which can be exploited through user input alone.

Re: Eliminating JavaScript cold starts on AWS Lambda

#47

Post by hinkley » Sun, Aug 17, 2025, 4:21 PM UTC

gibolt wrote: post #33

samwillis wrote: post #13

Oliver is doing awesome work here. A few interesting points: - Porffor can use typescript types to significantly improve the compilation. It's in many ways more exciting as a TS compiler. - There's no GC yet, and likely will be a while before it gets any. But you can get very far with no GC, particularly if you are doing something like serving web requests. You can fork a process per request and throw it away each ti…

Based on how much imported libraries are relied upon, it makes sense to treat everything as untrusted. Unless you write every line yourself/in-house, code should be considered untrusted. I would be curious which attack vectors change or become safe after compiling though.

Also none of the third party code will be thread safe. Hell, some of it isn’t even reentrant.

Re: Eliminating JavaScript cold starts on AWS Lambda

#48

Post by hinkley » Sun, Aug 17, 2025, 4:23 PM UTC

bastawhiz wrote: post #31

samwillis wrote: post #13

Oliver is doing awesome work here. A few interesting points: - Porffor can use typescript types to significantly improve the compilation. It's in many ways more exciting as a TS compiler. - There's no GC yet, and likely will be a while before it gets any. But you can get very far with no GC, particularly if you are doing something like serving web requests. You can fork a process per request and throw it away each ti…

> many of the restrictions that people associate with JS are due to VMs being designed to run untrusted code. If you compile your trusted TS/JS to native you can do many new things, such as use traditional threads, fork, and have proper low level memory access. Separating the concept of TS/JS from the runtime is long overdue. This is just outright wrong. JS limitations come from lots of things: 1. The language has al…

> JS has traditional threads in the form of web workers.

There is no language I’m aware of where workers behave like “traditional threads”. They’re isolates. Not threads.

Re: Eliminating JavaScript cold starts on AWS Lambda

#49

Post by [deleted] » Sun, Aug 17, 2025, 4:45 PM UTC

bapak wrote: post #4

I 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…

[deleted]

Re: Eliminating JavaScript cold starts on AWS Lambda

#50

Post by bastawhiz » Sun, Aug 17, 2025, 4:46 PM UTC

samwillis wrote: post #41

bastawhiz wrote: post #31

Earlier quoted context omitted.

> many of the restrictions that people associate with JS are due to VMs being designed to run untrusted code. If you compile your trusted TS/JS to native you can do many new things, such as use traditional threads, fork, and have proper low level memory access. Separating the concept of TS/JS from the runtime is long overdue. This is just outright wrong. JS limitations come from lots of things: 1. The language has al…

Web workers don't share memory (other than SAB) with the main thread, they are far from traditional threads. These APIs are designed the way they are to protect end users, stop sites from consuming resources or bad code blocking the main thread. None of that is needed to be that way on the server. There is zero reason that a JS implementation cannot implement proper threads within the same memory space. The issue is…

> Web workers don't share memory (other than SAB) with the main thread, they are far from traditional threads. These APIs are designed the way they are to protect end users, stop sites from consuming resources or bad code blocking the main thread. None of that is needed to be that way on the server.

It doesn't protect end users any more than it protects servers. Node could easily expose raw threading, but they don't because nearly the whole language isn't thread safe and everything would break. It has almost nothing to do with protecting users, it's a language design decision that enforces other design constraints.

> We need to stop conflating JS the language with the runtimes

If you're just sharing syntax but the standard library is different and essentially none of the code is compatible, it's not the same language. ECMAScript specifies all of the things you're talking about, and that is JavaScript, irrespective of the runtime.

> A JS runtime absolutely can get by without a GC, you just never dealloc and consume indefinitely. That doesn't change any semantics of the language, if a value/object is inaccessible, it's inaccessible...

If you throw away the whole heap on every request, now every request it's definitionally a "cold start". Which negates the singular benefit that this post is calling out. Porffor is still not faster than JITed engines at runtime, and initializing the code still has to happen.

> Nowhere did I say that full, or even any, compatibility with Node is needed - it isn't.

You have to square what you're saying with this statement. What you're describing is JavaScript in syntax only. You're talking about major departures from the formal language spec. Existing JavaScript code is likely to break. Why not just make a new language and call it something else, like Crystal is to Ruby? It works different, you're saying it doesn't care about compatibility... Why even call it JS then?