Contributor to Porffor here! I actually disagree, there's quite a lot that can be improved in JS during compile time. There's been a lot of work creating static type analysis tools for JS, that can do very very thorough analysis, an example that comes to mind is [TAJS](https://www.brics.dk/TAJS/) although its somewhat old.

> there's quite a lot that can be improved in JS during compile time

I wonder how much performance gain you expect to achieve. For simple CPU-bounded tasks, C/Rust/etc is roughly three times as fast as v8 and Julia, which compiles full scripts and has good type analysis, is about twice as fast. There is not much room left. C/Rust/etc can be much faster with SIMD, multi-threading and fine control of memory layout but an AOT JS compiler might not gain much from these.

In my mind, the big room for improvement is eliminating the cost to call from JS into other native languages. In node/V8 you pay a memcopy when you pass or return a string from C++ land. If an ahead of time compiler for JS can use escape analysis or other lifetime analysis for string or byte array data, you could make I/0 or at least writes from JavaScript to, for example, sqlite, about twice as fast.

Honestly, I’m fine with only some speed up compared to V8, it’s already pretty fast… My issue with desktop/mobile apps using web tech (JS) is mostly the install size and RAM hunger.

[raises hand] I'd be fine with no speedup at all if I can get more reasonable RAM usage and an easily linkable .so out of the deal.

The "node" binary on my laptop is 45MB in size. I guess the browser component may take more disk space than JS runtime. Similarly, I am not sure whether JS runtime or webpage rendering takes more RAM. If it is the latter, an AOT compiler won't help much.

Contributor for Porffor here! I think this is a great comparison, but Porffor does technically support promises, albeit synchronously. It's a similar approach to Kiesel, https://kiesel.dev/.

Not sure where you mean by synchronously but if you mean what I think you mean then that is not correct behaviour. This is important to ensure predicatibility.

Eg.

    Promise.then(() => console.log(“a”));
    console.log(“b”)

must log [“b”, “a”] and not [“a”, “b”].

This type of test does work as expected. The "sync" means that it does not feature a full event loop (yet) so cannot easily support async I/O or some more "advanced" use cases.

There's a WASI async functions proposal I think? Are you looking at supporting that so you don't have to bring your own event loop?

Yes, it does. Promise continuations always run in the micro task queue per the standard. I guess if someone mutates the promise prototype it’s not guaranteed, but the spec does guarantee this order

What do you mean? Does JavaScript allow the `then` of a promise to execute before the contents of the promise?