51–60 of 106 posts
Earlier quoted context omitted.
> Other webassembly runtimes are JIT based, rather than being interpreters. Do none of the notable ones do normal compilation?
I worked on one as an undergrad: https://github.com/gwsystems/aWsm Full AoT compilation, C programs run within 10% of native
I'm a newer dev so pardon my ignorance. Is webassembly the new, more open JVM? Feels like that write once, run everywhere but this time with any(most) mainstream language.
It seems like it's headed that way. At the moment, it's only really practical to generate WASM from compiled languages, or really small languages, like Lua. And your interfaces to the browser (and thus, the outside world) itself are pretty limited, so still lots of javascript involved.
Earlier quoted context omitted.
Good question, still a "green" technology but I have had great successes with it for the past 4-5 years in production (ASM.JS before widespread WASM compatibility). "promising that we'll be able to build web apps in any language" is not how I see WASM, nor is it really used in this way outside of transpiling Unity3D/Unreal games (this may be the one area there is an exception). I use it to transpile C++ to WASM libra…
In general I agree with your points, but: > What WASM will never be good at is being used for the whole experience. The Flutter team would disagree. They are leaning on WASM for browser builds of Flutter apps, with the whole app rendering in a canvas. They do accessibility via separately created accessibility trees. The experience far from great at the moment, but give it a few years and I think it will get there. (b…
What is the state of the world with wasm at this point? It seems like it's been this huge tease for 10 years now, promising that we'll be able to build web apps in any language. But as far as I'm aware, garbage collection and DOM access is still nonexistent.
There's no garbage collection in WASM. Why do you think that there is garbage collection in WASM? And WASM has been around since 2017, which is only 4 years, not 10 years... Bitcoin has been around much longer (~12 years), for example.
So if wasm is the spiritual successor to Emscripten's "Compile C to JavaScript and run C in a browser" then it's only 8 years.
Earlier quoted context omitted.
An AOT compiler would do a one-time translation to a platform-specific binary. If the environment you run on doesn’t support JIT compilation (iOS for example), AOT compiling WASM is useful.
At that point, what's the purpose of using WASM at all?
https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...
> The core implementation idea behind wasm sandboxing is that you can compile C/C++ into wasm code, and then you can compile that wasm code into native code for the machine your program actually runs on. These steps are similar to what you’d do to run C/C++ applications in the browser, but we’re performing the wasm to native code translation ahead of time, when Firefox itself is built.
It's a middle ground between sandboxing with subprocesses (which adds all the overhead of IPC) and switching to a fully memory-safe language (Rust, JS, etc.)
Earlier quoted context omitted.
It seems like it's headed that way. At the moment, it's only really practical to generate WASM from compiled languages, or really small languages, like Lua. And your interfaces to the browser (and thus, the outside world) itself are pretty limited, so still lots of javascript involved.
If your language is supported by LLVM, then Emscripten can compile it to WASM.
For those wondering, Wasm3 describes itself as "the fastest WebAssembly interpreter". Other webassembly runtimes are JIT based, rather than being interpreters. The project's readme ( https://github.com/wasm3/wasm3 ) talks more about this decision. For more on the difference, and an explanation of what JIT is, check out this section of the book Crafting Interpreters ( https://craftinginterpreters.com/a-map-of-the-terr…
It is heavily based around tail calls. I recently wrote a blog article about how we applied a similar tail-call-oriented strategy to accelerate protobuf parsing to 2+GB/s: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
I also recently landed a change in Clang trunk that offers guaranteed tail calls, so that this tail call design is safe in non-opt builds: https://reviews.llvm.org/D99517 I think wasm3 could benefit from using this attribute when it is available.
What is the state of the world with wasm at this point? It seems like it's been this huge tease for 10 years now, promising that we'll be able to build web apps in any language. But as far as I'm aware, garbage collection and DOM access is still nonexistent.
Ideally WASM would expose lower level APIs and then we can start treating the browser as the app sandbox that it is (in the case of buildign apps).
Earlier quoted context omitted.
Good question, still a "green" technology but I have had great successes with it for the past 4-5 years in production (ASM.JS before widespread WASM compatibility). "promising that we'll be able to build web apps in any language" is not how I see WASM, nor is it really used in this way outside of transpiling Unity3D/Unreal games (this may be the one area there is an exception). I use it to transpile C++ to WASM libra…
In general I agree with your points, but: > What WASM will never be good at is being used for the whole experience. The Flutter team would disagree. They are leaning on WASM for browser builds of Flutter apps, with the whole app rendering in a canvas. They do accessibility via separately created accessibility trees. The experience far from great at the moment, but give it a few years and I think it will get there. (b…
For some use-cases, this is a nonstarter. (Sadly, not to as many as I'd like! But let's simply not regress, to start.)
What is the state of the world with wasm at this point? It seems like it's been this huge tease for 10 years now, promising that we'll be able to build web apps in any language. But as far as I'm aware, garbage collection and DOM access is still nonexistent.