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”].

There are already projects that does JS-to-WASM by bundling a JS interpreter. So, it's likely to make the difference to those clearer.

Presumably the idea is that any work that causes Test262 regressions is temporary, takes place in a separate branch, and is only merged to main once the branch also contains all the necessary fixes to make the regressions go away again. A new version number would only be used once that merge happens.

At windmill.dev, when users deploy their code, we use Bun build (which is similar to esbuild) to bundle their scripts and all their dependencies into a single js file to load which improve cold start and memory usage. We store the bundle on s3 because of the size of the bundles.

If we could bundle everything to native that would completely change the game since as good as bun's cold start is, you can't beat running straight native with a small binary.

It's awesome to see how more JS runtimes try to approach Wasm. This project reminds me to Static Hermes (the JS engine from Facebook to improve the speed of React Native projects on iOS and Android).

I've spent a bit of time trying to review each, so hopefully this analysis will be useful for some readers. What are the main commonalities and differences between Static Hermes and Porffor?

  * They both aim for JS test262 conformance [1]
  * Porffor supports both Native and Wasm outputs while Static Hermes is mainly focused on Native outputs for now
  * Porffor is self-hosted (Porffor is written in pure JS and can compile itself), while Static Hermes relies on LLVM
  * Porffor currently doesn't support async/promise/await while Static Hermes does (with some limitations)
  * Static Hermes is written in C++ while Porffor is mainly JS
  * They both support TypeScript (although Static Hermes does it through transpiling the TS AST to Flow, while Porffor supports it natively)
  * Static Hermes has a fallback interpreter (to support `eval` and other hard-to-compile JS scenarios), while Porffor only supports AOT compiling (although, as I commented in other thread here, it maybe be possible to support `eval` in Porffor as well)

In general, I'm excited to see if this project can gain some traction so we can speed-up Javascript engines one the Edge! Context: I'm Syrus, from Wasmer [3]

[1] https://github.com/facebook/hermes/discussions/1137

[2] https://github.com/tc39/test262

[3] https://wasmer.io

What happens when someone calls eval?

> But since we are compiling AOT and not JIT, we cannot de-opt/undo that guess if it becomes wrong - instead we would just crash. > > But we could define the type using type annotations (TS)! > > Now we have to do 0 checks of the type of a, since we already know it at compile-time. This can allow for some big speedups :)

This comes with a big caveat that if the type assertion is wrong at runtime that the AOT'ed app will crash. Also I get the sense that the author assumes type "string" always means non-null and non-undefined but this is only true if the strictNullChecks compiler option is enabled.

Nonetheless, cool to see folks experimenting in the JS engine arena, especially around AOT!

Just a hitch found on https://porffor.goose.icu/

On running the example 'Array Reading' with an optimization level of 3 I get the following error

CompileError: WebAssembly.instantiate(): Compiling function #2 failed: local.set[0] expected type f64, found global.get of type i32 @+207

Is this expected?