eqrion

5 ms·

1.
by eqrion 2mo ago
> 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. edit: Apparently it also has some sort of WebAssembly
2.
NASA SpaceWASM – A flight-compliant WebAssembly interpreter(github.com)
41 points by eqrion 2mo ago|3 comments
3.
The web is actually great: A Decade at Mozilla(eqrion.net)
3 points by eqrion 2mo ago|0 comments
4.
by eqrion 4mo ago
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 disabled, but it would be nice to have a translator.
5.
by eqrion 4mo ago
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://searchfox.org/firefox-main/source&#x2F
6.
by eqrion 4mo ago
> 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 interacting with JS than wasm. You're basically limited to sim
7.
Saying goodbye to asm.js(spidermonkey.dev)
410 points by eqrion 4mo ago|158 comments
8.
by eqrion 6mo ago
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 coordinate concurrency. For end users, they shoul
9.
by eqrion 6mo ago
> 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 of code that's not JS out there. And JS is
10.
by eqrion 6mo ago
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 are developer experience improvements we could get with n
11.
by eqrion 6mo ago
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 developers won't need to write WIT and can just use Web
12.
by eqrion 6mo ago
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 cross language interop WebIDL is the union of JS
13.
by eqrion 6mo ago
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. WebAssembly has a sandbox and was designed for unt
14.
by eqrion 11y ago
Yikes, that's embarrassing. Well that's definitely the first thing I'm going to redo lol.