10 ms·

Hands-on WebAssembly

237 points by progapandist 6y ago

donatj 6y ago
Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” but since then I have grown to love TypeScript, so a lot of that early excitement has been tempered. I have done a number of experiments with Go’s WASM target, one of the earliest and silliest porting Go’s “Otto” JavaScript runtime to WASM, so you can much less efficiently run ES3 JavaScript in a browser. I have also been working on porting a number of tools I currently have that run server side with web frontends to pure WASM. I have had mixed success here however and have found interacting with web elements and JavaScript from Go an awkward, non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. On top of everything, Go’s .wasm files are frustratingly large, “Hello World” starting at 1mb and growing quickly from there. All that said though, it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes.
- the_duke 6y ago
  Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here. Same goes for most popular languages. For me Rust offers the best WASM experience and tooling at the moment. Rust has no GC and (almost) no runtime. It also has official wasm build target support out of the box, including generating Typescript definitions for Rust types. The ecosystem is somewhat well-developed: * wasm-bindgen for general interop in both directions * js-sys / web-sys for (low-level) type-safe and surprisingly efficient browser API bindings * wasm-bindgen-futures for easy Promise <-> Future interop * wasm-pack for easy building * ... Getting the code size low is still a challenge though. A Rust implementation of the Krausest frontend framework benchmark takes a top 4 spot [1]. Despite this benchmark not favouring wasm at all since it requires little computation and mostly does FFI calls. (ps: C++ is in a decent state as well) [1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
  - pjmlp 6y ago
    It is still much smaller than most SPA used to display static text.
  - amelius 6y ago
    > Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here I expect that WASM doesn't have the concurrency model required by a modern concurrent garbage collector like Go's, but perhaps I'm wrong.
    - foota 6y ago
      It's likely much slower, but it should be able to run just fine single threaded as well.
  - pansa2 6y ago
    > C++ is in a decent state as well I’d still choose Go or Rust over C++, though, because they’re memory-safe. This recent discussion shows that’s still important in the context of WebAssembly: https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764
    - the_duke 6y ago
      Sure, for new projects I choose Rust over C++ whenever feasible. But a huge amount of the worlds software is written in C++, and will remain so for decades. Getting some of that code to run well in WASM can be a big win for certain domains.
    - stjohnswarts 6y ago
      Modern C++ has a lot of memory safe operations if you use them (smart pointers, atomics, actually using RAII properly and universally), although I'm not sure how much overhead they might add to a wasm blob. Rust seems almost perfect for it though, but no reason to discourage C++ people; it can be a relatively modern language if you let it.
      - 6y ago
- maxgraey 6y ago
  Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm
  - donatj 6y ago
    I poked a similar project a while back. If I can just as easily have understandable, easily debug-able JavaScript as output target, I believe that’s preferable. Particularly where extreme performance is not a concern. Tools like GopherJS, Elm, Dart and such output JavaScript no human could reasonably interpret. WASM seems logical for them. TypeScript outputs very human readable JS (for the most part) and WASM seems to have little virtue. As someone who learned JavaScript in the late 90s / early 2000s reading websites code, outputting readable JS feels like giving back.
- thefounder 6y ago
  >> non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. That's because officially Go has not support for web APIs(as wasm has no access to web apis) so you have to callback through JavaScript. However once you build the right wrappers around JS APIs and the tools to deal with HTML the experience is pretty nice.
- pansa2 6y ago
  > it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes. Years ago, I wanted to write some code that could run both as part of a command-line app and an in-browser tool. I asked what language I should use for this shared code and was told, basically, that there was no suitable language. Now, thanks to WASM, there are lots!
  - fulafel 6y ago
    This is indeed nice but in fact you could run C/C++/Rust before too, with asm.js. Not to mention the languages that target JS and can run on Node or the browser.
  - pjmlp 6y ago
    How come? I have done that eons ago with Java.
- nikki93 6y ago
  As another poster said-- C++, C or Rust may give you better luck when compiling to WASM. You could also try TinyGo. Vanilla Go's embedding of its entire runtime and GC is ... a lot.
  - stjohnswarts 6y ago
    does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.
    - nikki93 6y ago
      I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...). You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128 https://changelog.com/gotime/128 It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.
- MaxBarraclough 6y ago
  > Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” This has been true for years, various languages can compile down to JavaScript. Kotlin and Dart, for instance. Also, doesn't WASM lack a garbage collector? I imagine porting a language to WASM is still quite a task, and presumably a GC written in WASM is going to be far inferior to one provided by the browser, as with JavaScript. (Corrections welcome if I'm wrong about that.) That's not to dismiss the potential for performance gains in situations well suited to WASM. (I see the_duke already mentioned the GC situation.)
runawaybottle 6y ago
Quite frankly, I need to see a reason why one would use WASM. Figma is a fully justified implementation. If you don’t like JavaScript, like get over yourself already. Enough is enough. It’s a a simple language, you will still have to deal with browser apis and UI development patterns no matter what language you pick, and no, type checking isn’t going to magically solve your shitty UI codebase. WebAssembly is going to be the new Tensorflow on people’s LinkedIn unfortunately, a small word to signal ‘hey, I’m more than just a web developer’. Unless you are compiling a video encoder or a video game, like please, just give a rest. Solve the fact that your simple app is more than 3-4 files and over abstracted first.
- emteycz 6y ago
  This is like suggesting PHP to C# or Java developers because "everyone uses it". Today the web (just like the server) supports any language - get over yourself, people have moved beyond JavaScript.
  - runawaybottle 6y ago
    They haven’t. This is all deferred anger coming from non-ui developers. It kills them inside that ui development is a field within software development that has it’s own nuances. They blamed the closest thing they could and that was, literally, the simplest shittiest language on planet earth (it doesn’t deserve all the hate). You will still have take time and think through your app flows, your async user interactivity, your transitions, state, templates, etc, no matter what language you pick. Type checking, compiling, the greatest language, will not solve the hard problems for you. Your all pissed UI development isn’t a ‘if I know backend, then I must surely know frontend, and if I don’t, then surely somethings wrong with frontend’. Nope. Trust me, I know a thing or two about deferred anger, I’m a serial offender when it comes to that so I can spot it easy.
    - emteycz 6y ago
      I am a TypeScript developer for the past 6 years. I am not at all angry and definitely not expecting issues I have with SPA development to be magically solved, I am simply excited about being able to use languages with type systems similar to TS but without the JS under it - not that I care much about it, but it would be nice to go a step further with the type system-language integration, which TypeScript is unwilling to do. WebAssembly is a done deal, all browsers support it, now we're waiting for reference types and GC, once that lands (ref types are already available in some browsers), the web will not be tied to JS in any way. I think it's fair to say that the world has moved beyond JS. Btw I think people doing UI apps in C# (Blazor is probably second largest Wasm community after Rust) are fully aware of the hurdles of UI development.
vanderZwan 6y ago
What holds me back from using WebAssembly is that it doesn't seem to provide any performance benefit for small functions. Well, not yet, I hope, because I really like the idea of WASM. For example, last week me and a few other users on Observable have been experimenting with various JS ports of one particular permuted congruential random number generator. Using assemblyscript I managed to write a decent-enough WASM version, and it's slower than implementing 64 bit arithmetic with four 32 bit numbers, which involves a lot more multiplications and additions: https://observablehq.com/d/ce811886e1071d69 https://observablehq.com/d/ce811886e1071d69 There are two possible explanations: either 64 bit integer arithmetic is still really slow in WASM, or the call overhead is really, really significant. This fits my earlier experience with trying to implement fast log approximation functions for data-viz purposes (since the rounding errors would not be visible at sub-pixel levels). They weren't much faster than the proper Math.log function (whereas in pure C or C++ that difference would be much larger). I suspect that if this call overhead were reduced, it would be much easier to gradually add more WASM to a Web App and reap the benefits of it.
- saagarjha 6y ago
  Calling a short function is generally a poor idea, to be honest. You want significant execution time on either side of the bridge, not constant boundary crossing.
  - vanderZwan 6y ago
    The thing is that I had expectations of why the boundary crossing was so slow. I expected a no-heap WASM function that returns a simple value to be pretty fast, but as the other comment points out the "boundary" in this case might not be the WASM/JS boundary so much as the inability to inline WASM.
  - stjohnswarts 6y ago
    Not really. Unless it's called quite often. Premature optimization is not a good thing in general. Find your bottlenecks, code for correctness and ease of understanding first and use optimization if it's basically "free" and don't worry much about it otherwise.
qppo 6y ago
I'm just excited that I'll be able to write app extension APIs defined in C and host them in a wasm runtime that doesn't have to run in a different process to keep those extensions on their best behavior and not crash the app when they segfault. Not 100% sure if that's possible with WASM runtimes now or if it's faster (IPC can be quite fast) but that's my hope.
secondWave12 6y ago
WebAssembly in the browser didn't have its breakthrough so far and probably will never have. The problems WA tries to solve are no big problems, if problems at all: - Typescript is an excellent language. - Performance of Javascript is for 99% of all the websites more than good enough. - New frameworks like Svelte are much more mobile friendly in terms of computational overhead or time to first render. Also, work on WA has pretty much stalled.
- zekrioca 6y ago
  Do not constrain yourself to today, but rather to what is to come. For instance, Iot apps running in Edge and cloud datacenters.
- sriku 6y ago
  UI in the browser isn't the right frame to think about webassembly. The right frame is wherever you can benefit from running a piece of potentially untrusted code within a sandbox. This is important for platform vendors who have to run cuatomer code that they can't trust. It is also important to run what would otherwise be unsafe code in the browser (ex: I use it for audio encoding/decoding and processing). It can serve as a "plugin" mechanism for host applications that need high performance for the plugins along with safety (ex: image proc, NN models). Environments where you need extreme granular control over what's permitted for the module (hence WASI and CloudABI).
- k__ 6y ago
  You can compile languages like C/C++ and Rust to it. Sometimes this gives a performance boost, but most of the time it gives you just more uniform performance behavior. Then you can compile stuff like Java or C# to it, but end up with huge runtime bundles. But you get much of the C# behavior from TypeScript without the huge runtime, because it compiles directly to JavaScript.
  - wtetzner 6y ago
    It also allows you to run existing code in the browser, without having to do a rewrite.
zaarn 6y ago
Fun fact: The new MS Flight Simulator 2020 uses WebAssembly to run the software for the aircrafts in game. You can check the release notes, where they do detail that webassembly is used for the SDK as well. The intention is likely that if the onboard computer emulation crashes (which it sometimes does) you can simulate the actual onboard computer restarting without it taking down the game.
- k__ 6y ago
  Fun fact: The Cloudflare Workers FaaS platform uses WebAssembly to run the software for your non-JS function in the cloud. You can check their blog, where they have a guide for Rust[1]. The intention is likely that they use V8 isolates instead of VMs which support WebAssembly. [1] https://blog.cloudflare.com/introducing-wrangler-cli/ https://blog.cloudflare.com/introducing-wrangler-cli/ SCNR :D
- flohofwoe 6y ago
  It might be more likely that WASM is used for its sandboxing qualities while providing "near-native" performance for all types of extensions (not just the aircraft computers), because new aircraft modules and extensions are often provided by third-party companies or the modding community. Traditionally, scripting languages have been used to integrate "untrusted code" (e.g. DCS World, another popular flight sim, uses Lua for its aircraft modules and also exposes a lot of other functionality through Lua scripts so that they are moddable).
  - zaarn 6y ago
    Basically, yeah, it isolates the interactive parts of the plane (animations, likely, as well as OBC and friends). The WASM Runtime used is on github, https://innative.dev/ https://innative.dev/
    - Tarq0n 6y ago
      Interesting. How does this differ from WASMtime, the focus on C compatibility?
mamcx 6y ago
I hope some of the extensions for WASM land like https://github.com/bytecodealliance/wasmtime/issues/677 https://github.com/bytecodealliance/wasmtime/issues/677. I take a look for build an interpreter to run fully on it, but still is required to have a host that understand fully the types so is not much time saving.

237 points by progapandist 6y ago

Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” but since then I have grown to love TypeScript, so a lot of that early excitement has been tempered. I have done a number of experiments with Go’s WASM target, one of the earliest and silliest porting Go’s “Otto” JavaScript runtime to WASM, so you can much less efficiently run ES3 JavaScript in a browser. I have also been working on porting a number of tools I currently have that run server side with web frontends to pure WASM. I have had mixed success here however and have found interacting with web elements and JavaScript from Go an awkward, non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. On top of everything, Go’s .wasm files are frustratingly large, “Hello World” starting at 1mb and growing quickly from there. All that said though, it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes.

the_duke 6y ago
Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here. Same goes for most popular languages. For me Rust offers the best WASM experience and tooling at the moment. Rust has no GC and (almost) no runtime. It also has official wasm build target support out of the box, including generating Typescript definitions for Rust types. The ecosystem is somewhat well-developed: * wasm-bindgen for general interop in both directions * js-sys / web-sys for (low-level) type-safe and surprisingly efficient browser API bindings * wasm-bindgen-futures for easy Promise <-> Future interop * wasm-pack for easy building * ... Getting the code size low is still a challenge though. A Rust implementation of the Krausest frontend framework benchmark takes a top 4 spot [1]. Despite this benchmark not favouring wasm at all since it requires little computation and mostly does FFI calls. (ps: C++ is in a decent state as well) [1] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- pjmlp 6y ago
  It is still much smaller than most SPA used to display static text.
- amelius 6y ago
  > Go has to embed it's runtime and GC into builds, so build size and performance will take a hit here I expect that WASM doesn't have the concurrency model required by a modern concurrent garbage collector like Go's, but perhaps I'm wrong.
  - foota 6y ago
    It's likely much slower, but it should be able to run just fine single threaded as well.
- pansa2 6y ago
  > C++ is in a decent state as well I’d still choose Go or Rust over C++, though, because they’re memory-safe. This recent discussion shows that’s still important in the context of WebAssembly: https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764
  - the_duke 6y ago
    Sure, for new projects I choose Rust over C++ whenever feasible. But a huge amount of the worlds software is written in C++, and will remain so for decades. Getting some of that code to run well in WASM can be a big win for certain domains.
  - stjohnswarts 6y ago
    Modern C++ has a lot of memory safe operations if you use them (smart pointers, atomics, actually using RAII properly and universally), although I'm not sure how much overhead they might add to a wasm blob. Rust seems almost perfect for it though, but no reason to discourage C++ people; it can be a relatively modern language if you let it.
    - 6y ago
maxgraey 6y ago
Perhaps if you like TypeScript and still want compile to WebAssembly you might be interested in AssemblyScript which stricter subset of TypeScript which compile to wasm
- donatj 6y ago
  I poked a similar project a while back. If I can just as easily have understandable, easily debug-able JavaScript as output target, I believe that’s preferable. Particularly where extreme performance is not a concern. Tools like GopherJS, Elm, Dart and such output JavaScript no human could reasonably interpret. WASM seems logical for them. TypeScript outputs very human readable JS (for the most part) and WASM seems to have little virtue. As someone who learned JavaScript in the late 90s / early 2000s reading websites code, outputting readable JS feels like giving back.
thefounder 6y ago
>> non statically validated, frustrating experience of trial-and-error that somewhat undermines the joy of a statically typed language. That's because officially Go has not support for web APIs(as wasm has no access to web apis) so you have to callback through JavaScript. However once you build the right wrappers around JS APIs and the tools to deal with HTML the experience is pretty nice.
pansa2 6y ago
> it is pretty magical seeing something written as a CLI tool running in a browser with minimal changes. Years ago, I wanted to write some code that could run both as part of a command-line app and an in-browser tool. I asked what language I should use for this shared code and was told, basically, that there was no suitable language. Now, thanks to WASM, there are lots!
- fulafel 6y ago
  This is indeed nice but in fact you could run C/C++/Rust before too, with asm.js. Not to mention the languages that target JS and can run on Node or the browser.
- pjmlp 6y ago
  How come? I have done that eons ago with Java.
nikki93 6y ago
As another poster said-- C++, C or Rust may give you better luck when compiling to WASM. You could also try TinyGo. Vanilla Go's embedding of its entire runtime and GC is ... a lot.
- stjohnswarts 6y ago
  does it matter much after it's cached locally though? I mean say for single page web apps. I could see that not being a big issue, but if you have to reload the page a lot it might, but loading 1 Mb into memory is nothing to most modern CPUs if it's pulled off the hard drive.
  - nikki93 6y ago
    I started working on a game in Go (with Ebiten-- which is an awesome engine for native!) and hit perf issues in simple scenes that just worked flawlessly with similarly trivial code in C++ with SDL. It wasn't about the size as much as the performance overhead of having a GC and just generally maybe more lax runtime overhead philosophy than Rust / C/C++. I think deterministic memory management and memory layout control is the main perf benefit you get with WASM over JS for the type of stuff I was working on-- both things there's more natural methods for in Rust and C++. I also prefer being able to monomorphize generic code and have it inline etc. (esp. with entt) vs. the vtable stuff you tend to see with Go interfaces (this is totally up to coding style / practices and both are doable in both...). You can also see this with Gio UI library in Go where they try to minimize GC overhead yet one keeps hitting GC pauses in WASM. The author talks about some of the issues with Go on WASM here: https://changelog.com/gotime/128 https://changelog.com/gotime/128 It did help that after diving back into the new stuff in 'modern C++' with auto, lambdas and move semantics I was able to write quite ergonomic code without any actual manual memory management stuff going on.
MaxBarraclough 6y ago
> Most of my early excitement for WASM circled around “Hey, I can finally use a decent language on the web” This has been true for years, various languages can compile down to JavaScript. Kotlin and Dart, for instance. Also, doesn't WASM lack a garbage collector? I imagine porting a language to WASM is still quite a task, and presumably a GC written in WASM is going to be far inferior to one provided by the browser, as with JavaScript. (Corrections welcome if I'm wrong about that.) That's not to dismiss the potential for performance gains in situations well suited to WASM. (I see the_duke already mentioned the GC situation.)

runawaybottle 6y ago

Quite frankly, I need to see a reason why one would use WASM. Figma is a fully justified implementation. If you don’t like JavaScript, like get over yourself already. Enough is enough. It’s a a simple language, you will still have to deal with browser apis and UI development patterns no matter what language you pick, and no, type checking isn’t going to magically solve your shitty UI codebase. WebAssembly is going to be the new Tensorflow on people’s LinkedIn unfortunately, a small word to signal ‘hey, I’m more than just a web developer’. Unless you are compiling a video encoder or a video game, like please, just give a rest. Solve the fact that your simple app is more than 3-4 files and over abstracted first.

emteycz 6y ago
This is like suggesting PHP to C# or Java developers because "everyone uses it". Today the web (just like the server) supports any language - get over yourself, people have moved beyond JavaScript.
- runawaybottle 6y ago
  They haven’t. This is all deferred anger coming from non-ui developers. It kills them inside that ui development is a field within software development that has it’s own nuances. They blamed the closest thing they could and that was, literally, the simplest shittiest language on planet earth (it doesn’t deserve all the hate). You will still have take time and think through your app flows, your async user interactivity, your transitions, state, templates, etc, no matter what language you pick. Type checking, compiling, the greatest language, will not solve the hard problems for you. Your all pissed UI development isn’t a ‘if I know backend, then I must surely know frontend, and if I don’t, then surely somethings wrong with frontend’. Nope. Trust me, I know a thing or two about deferred anger, I’m a serial offender when it comes to that so I can spot it easy.
  - emteycz 6y ago
    I am a TypeScript developer for the past 6 years. I am not at all angry and definitely not expecting issues I have with SPA development to be magically solved, I am simply excited about being able to use languages with type systems similar to TS but without the JS under it - not that I care much about it, but it would be nice to go a step further with the type system-language integration, which TypeScript is unwilling to do. WebAssembly is a done deal, all browsers support it, now we're waiting for reference types and GC, once that lands (ref types are already available in some browsers), the web will not be tied to JS in any way. I think it's fair to say that the world has moved beyond JS. Btw I think people doing UI apps in C# (Blazor is probably second largest Wasm community after Rust) are fully aware of the hurdles of UI development.

vanderZwan 6y ago

What holds me back from using WebAssembly is that it doesn't seem to provide any performance benefit for small functions. Well, not yet, I hope, because I really like the idea of WASM. For example, last week me and a few other users on Observable have been experimenting with various JS ports of one particular permuted congruential random number generator. Using assemblyscript I managed to write a decent-enough WASM version, and it's slower than implementing 64 bit arithmetic with four 32 bit numbers, which involves a lot more multiplications and additions: https://observablehq.com/d/ce811886e1071d69 https://observablehq.com/d/ce811886e1071d69 There are two possible explanations: either 64 bit integer arithmetic is still really slow in WASM, or the call overhead is really, really significant. This fits my earlier experience with trying to implement fast log approximation functions for data-viz purposes (since the rounding errors would not be visible at sub-pixel levels). They weren't much faster than the proper Math.log function (whereas in pure C or C++ that difference would be much larger). I suspect that if this call overhead were reduced, it would be much easier to gradually add more WASM to a Web App and reap the benefits of it.

saagarjha 6y ago
Calling a short function is generally a poor idea, to be honest. You want significant execution time on either side of the bridge, not constant boundary crossing.
- vanderZwan 6y ago
  The thing is that I had expectations of why the boundary crossing was so slow. I expected a no-heap WASM function that returns a simple value to be pretty fast, but as the other comment points out the "boundary" in this case might not be the WASM/JS boundary so much as the inability to inline WASM.
- stjohnswarts 6y ago
  Not really. Unless it's called quite often. Premature optimization is not a good thing in general. Find your bottlenecks, code for correctness and ease of understanding first and use optimization if it's basically "free" and don't worry much about it otherwise.

qppo 6y ago

I'm just excited that I'll be able to write app extension APIs defined in C and host them in a wasm runtime that doesn't have to run in a different process to keep those extensions on their best behavior and not crash the app when they segfault. Not 100% sure if that's possible with WASM runtimes now or if it's faster (IPC can be quite fast) but that's my hope.

secondWave12 6y ago

WebAssembly in the browser didn't have its breakthrough so far and probably will never have. The problems WA tries to solve are no big problems, if problems at all: - Typescript is an excellent language. - Performance of Javascript is for 99% of all the websites more than good enough. - New frameworks like Svelte are much more mobile friendly in terms of computational overhead or time to first render. Also, work on WA has pretty much stalled.

zekrioca 6y ago
Do not constrain yourself to today, but rather to what is to come. For instance, Iot apps running in Edge and cloud datacenters.
sriku 6y ago
UI in the browser isn't the right frame to think about webassembly. The right frame is wherever you can benefit from running a piece of potentially untrusted code within a sandbox. This is important for platform vendors who have to run cuatomer code that they can't trust. It is also important to run what would otherwise be unsafe code in the browser (ex: I use it for audio encoding/decoding and processing). It can serve as a "plugin" mechanism for host applications that need high performance for the plugins along with safety (ex: image proc, NN models). Environments where you need extreme granular control over what's permitted for the module (hence WASI and CloudABI).
k__ 6y ago
You can compile languages like C/C++ and Rust to it. Sometimes this gives a performance boost, but most of the time it gives you just more uniform performance behavior. Then you can compile stuff like Java or C# to it, but end up with huge runtime bundles. But you get much of the C# behavior from TypeScript without the huge runtime, because it compiles directly to JavaScript.
- wtetzner 6y ago
  It also allows you to run existing code in the browser, without having to do a rewrite.

zaarn 6y ago

Fun fact: The new MS Flight Simulator 2020 uses WebAssembly to run the software for the aircrafts in game. You can check the release notes, where they do detail that webassembly is used for the SDK as well. The intention is likely that if the onboard computer emulation crashes (which it sometimes does) you can simulate the actual onboard computer restarting without it taking down the game.

k__ 6y ago
Fun fact: The Cloudflare Workers FaaS platform uses WebAssembly to run the software for your non-JS function in the cloud. You can check their blog, where they have a guide for Rust[1]. The intention is likely that they use V8 isolates instead of VMs which support WebAssembly. [1] https://blog.cloudflare.com/introducing-wrangler-cli/ https://blog.cloudflare.com/introducing-wrangler-cli/ SCNR :D
flohofwoe 6y ago
It might be more likely that WASM is used for its sandboxing qualities while providing "near-native" performance for all types of extensions (not just the aircraft computers), because new aircraft modules and extensions are often provided by third-party companies or the modding community. Traditionally, scripting languages have been used to integrate "untrusted code" (e.g. DCS World, another popular flight sim, uses Lua for its aircraft modules and also exposes a lot of other functionality through Lua scripts so that they are moddable).
- zaarn 6y ago
  Basically, yeah, it isolates the interactive parts of the plane (animations, likely, as well as OBC and friends). The WASM Runtime used is on github, https://innative.dev/ https://innative.dev/
  - Tarq0n 6y ago
    Interesting. How does this differ from WASMtime, the focus on C compatibility?

mamcx 6y ago

I hope some of the extensions for WASM land like https://github.com/bytecodealliance/wasmtime/issues/677 https://github.com/bytecodealliance/wasmtime/issues/677. I take a look for build an interpreter to run fully on it, but still is required to have a host that understand fully the types so is not much time saving.