Viewing profile — eqrion

> There is a novel WASM->JS JIT for experimental site speedup I would love to see the details for this. SpiderMonkey had an attempted wasm32 JIT backend, but it was never finished.…

Binaryen used to have an asm2wasm tool, but I believe it has been deprecated. I couldn't find any other equivalent. At least the asm.js code will keep working even with asm.js opts…

Generating wasm code at runtime is pretty easy (I'd imagine easier than generating valid asm.js code). We have a little library for our tests that handles a lot of it: https://sear…

> But wasm is too isolated from javascript. From my limited use of it, I was considering trying to compile to asmjs instead asmjs is going to be strictly more limited in interactin…

The concurrency part of the C-M is complicated (I think for inherent reasons), but won't be exposed to end users. It's basically defining an API that language toolchains can use to…

> If you compile them to GC wasm instead of running directly in JS then you're just adding unnecessary overheads for no upside Language portability is a big feature. There's a lot …

I agree there are some cases that won't see a huge boost, but also DOM performance is a big deal and bottleneck for a lot of applications. And besides performance, I think there ar…

I agree that a lot of the tooling is still early days. There has also been a lot of churn as the wasm component spec has changed. We personally have a goal that in most cases web d…

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cro…

I'm not sure I follow this. > WebAssembly is the wrong abstraction for running untrusted apps in a browser WebAssembly is a better fit for a platform running untrusted apps than JS…

Yikes, that's embarrassing. Well that's definitely the first thing I'm going to redo lol.