10 ms·

WebAssembly adoption: Is slow and steady winning the race?

96 points by qclibre22 2y ago

throwaway63467 2y ago
It’s just not very useful as you can’t interface with the external world much (yet). System calls are still very limited and even things like opening a UDP socket are highly experimental. So I’m excited for it but there’s a ton of stuff missing to actually make it useful for most real world use cases.
DarkNova6 2y ago
> “WASI preview two is a checkpoint of stable interfaces,” Spencer said. “The instability of preview one, [which] may have scared or prevented you from using Wasm in production, is now past us.” I wasn't aware a new version of WASI was out. I've been following it for years and its potential is still exciting. Some quotes: > WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal. > The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.
aquova 2y ago
> “While obviously C/C++ and Rust came to the ecosystem early on, other languages seemed to slowly put a ‘toe in the water’, first having limited support and then gradually investing more as usage takes off.” This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it's not necessarily worth diving into.
- HdS84 2y ago
  What about dotnet? Irc it was even there before rust?
  - useerup 2y ago
    The first .NET Blazor "webassembly" was the .NET runtime ported to Webassembly, but where developer code would actually be the same type of IL (Microsoft's Intermediate Labguage) as .NET runs on Windows and Linux. Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM. To this day this is still the default, but now you can use a compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.
    - orra 2y ago
      Just to add to this answer, here's [1] how to do .NET with AOT compilation, without needing Blazor. [1] https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav... Such an app needs to download a megabyte of runtime. This isn't tiny. Yet, for corporate apps I think it's okay? Apps start reasonably quickly, although not instantly, maybe 2 seconds.
- azakai 2y ago
  The good news in that area is that WasmGC (shipping in Chrome and Firefox today) has allowed very good Wasm support to be shipped for many more languages, including Java, Kotlin, Dart, Scheme, OCaml, and more.
JohnFen 2y ago
WASM doesn't interest me for my development because it comes with what I consider large downsides without giving me any substantial benefits. That's not to say that I don't see any benefit in it. I can see use cases for it, they just aren't use cases that I have.
austin-cheney 2y ago
Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times. There are absolutely valid business cases behind Web Assembly though, here are some: * circumventing iphone restrictions * desktop application portability * security * partial docker alternative * promoting adoption and access of applications written lesser popular languages
- durandal1 2y ago
  You are not wrong, but it solves another really hard business problem: Hiring and retaining good engineers.
- DarkNova6 2y ago
  But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.
  - pjmlp 2y ago
    Blazor is doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen. On my job I have zero reasons to suggest it, given the split between FE and BE teams.
iwillsayit 2y ago
The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.
- 01HNNWZ0MV43FF 2y ago
  I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.
  - Traubenfuchs 2y ago
    > VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind you the Hello World example executable is 80mb and takes 6 seconds to start, but I feel like with the garbage we are used to in regards to desktop applications, this totally holds up -doesn't everything else usually bundle all of chrome? I have also read there are simple command line options to reduce the size to about 50mb. * https://github.com/mjparme/javafx-template https://github.com/mjparme/javafx-template
    - eviks 2y ago
      But all of Chrome doesn't take 6 seconds to start
azakai 2y ago
This quote from the end of the article is good: > With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis. I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it's already succeeded.
- LunaSea 2y ago
  Really? I can't think of a mainstream (as in used daily) site that uses WASM. Do you have some in mind?
  - hermanradtke 2y ago
    https://madewithwebassembly.com/ https://madewithwebassembly.com/ I see a few major sites and some major plugins. The definition of "mainstream (as in used daily) site" may differ between groups.
  - callahad 2y ago
    Figma has been powered by WebAssembly for the past 7 years.
    - kamikazeturtles 2y ago
      What parts of Figma though? Is it just used for cpu intensive operations like triangulation of svgs to render in webgl or is the site's core logic all done is wasm? I'm sorry, I don't use Figma but I'm really curious about its tech stack
      - azakai 2y ago
        They have a bunch of nice blogposts about that: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... The main part of the app is in wasm, I believe (it's in C++ that they compile).
6510 2y ago
The assumption is that javascript is bad and that the solution is to not fix it. asm.js was another example.
- lxgr 2y ago
  asm.js was the opposite of an alternative to JavaScript: It was a performant JavaScript dialect used as a compilation target for various languages otherwise targeting emscripten. WASM is the spiritual successor to that, getting rid of the (in retrospect quite hilarious) "embedded backwards compatibility layer".
  - 6510 2y ago
    You don't compile to js because js is slow. edit: for the record, I think having only one doc type (html) and only one scripting language (js) in the browser is a terrible idea. I don't know what the other doc types and programming languages should be but performance alone seems like a poor idea. A compile target seems even worse. :)
pjmlp 2y ago
I really don't see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven't had enough since UNCOL (1958). The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony. And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser. At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.
- lxgr 2y ago
  > if one needs performance it is better served with GPU code than WebAssembly What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too? WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM. > At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations. Couldn't disagree more. Flash, ActiveX and Java were unpopular because they all came with their own weird/non-native-feeling GUI toolkits and UI paradigms (e.g. breaking right clicks and text selection, Ctrl+F etc.). Flash and ActiveX were also closed source and only available on some platforms. ActiveX was also very badly sandboxed on top of all of that. WASM is none of that. The only thing you'd notice e.g. about a site bringing its own media codec, game engine etc. in WASM instead of JavaScript is better performance.
  - pjmlp 2y ago
    Linux kernel isn't supposed to run in the browser. Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".
    - lxgr 2y ago
      I think many people like the idea of bytecode, but not the implementation of Java/the JVM (especially if they have an existing codebase or don't want to start a new one in Java), and I think that's pretty fair.
justahuman74 2y ago
I haven't been keeping up, can I write webpages that replace all javascript with wasm yet?

96 points by qclibre22 2y ago

It’s just not very useful as you can’t interface with the external world much (yet). System calls are still very limited and even things like opening a UDP socket are highly experimental. So I’m excited for it but there’s a ton of stuff missing to actually make it useful for most real world use cases.

DarkNova6 2y ago

> “WASI preview two is a checkpoint of stable interfaces,” Spencer said. “The instability of preview one, [which] may have scared or prevented you from using Wasm in production, is now past us.” I wasn't aware a new version of WASI was out. I've been following it for years and its potential is still exciting. Some quotes: > WASI 0.2 also introduces two distinct “worlds,” which describe different kinds of hosts that WebAssembly can run on. The first of these worlds is the “command” world, resembling a traditional POSIX command-line application with access to the file system, socket and terminal. > The second of these worlds is the “HTTP proxy,” which characterizes platforms, like Fastly, that can send and receive streaming HTTP requests and responses, serving as forward or reverse proxies. These worlds represent the beginning of a broader ecosystem, offering developers multiple avenues to explore and innovate, and more worlds will be added to WASI in the future.

aquova 2y ago

> “While obviously C/C++ and Rust came to the ecosystem early on, other languages seemed to slowly put a ‘toe in the water’, first having limited support and then gradually investing more as usage takes off.” This is the biggest limitation for me. I like WASM fine, but anytime I want to use it I have to turn back to Rust. I like Rust fine, but without support in other languages, it's not necessarily worth diving into.

HdS84 2y ago
What about dotnet? Irc it was even there before rust?
- useerup 2y ago
  The first .NET Blazor "webassembly" was the .NET runtime ported to Webassembly, but where developer code would actually be the same type of IL (Microsoft's Intermediate Labguage) as .NET runs on Windows and Linux. Unlike those platforms however, the IL was actually interpreted by the ported .NET runtime. Only the runtime was actually running as WASM. To this day this is still the default, but now you can use a compiler to compile from IL to WASM, and then run full WASM code in the browser. This toolchain is a bit slower on build, but the code will run much faster.
  - orra 2y ago
    Just to add to this answer, here's [1] how to do .NET with AOT compilation, without needing Blazor. [1] https://devblogs.microsoft.com/dotnet/use-net-7-from-any-javascript-app-in-net-7/ https://devblogs.microsoft.com/dotnet/use-net-7-from-any-jav... Such an app needs to download a megabyte of runtime. This isn't tiny. Yet, for corporate apps I think it's okay? Apps start reasonably quickly, although not instantly, maybe 2 seconds.
azakai 2y ago
The good news in that area is that WasmGC (shipping in Chrome and Firefox today) has allowed very good Wasm support to be shipped for many more languages, including Java, Kotlin, Dart, Scheme, OCaml, and more.

JohnFen 2y ago

WASM doesn't interest me for my development because it comes with what I consider large downsides without giving me any substantial benefits. That's not to say that I don't see any benefit in it. I can see use cases for it, they just aren't use cases that I have.

austin-cheney 2y ago

Web Assembly has (at least in the past) a business problem. In the past in nearly all prior discussions on this the greatest proponents for Web Assembly were developers who wanted to bring their technologies into the browser because they hate JavaScript. That is a horrible business case that is more effort than any value returned and no user will ever care about. Worse, it won't ever work if you intended it to be a JavaScript replacement because it cannot integrate into the interaction of the surrounding page, because it is a sandbox without compromise. This line of wishful thinking instills false hope and just pisses off everyone else, which slows adoption among other languages. The Web Assembly effort has been very clear about this from the very beginning, but people believe what they want to believe even after this has been clarified dozens of times. There are absolutely valid business cases behind Web Assembly though, here are some: * circumventing iphone restrictions * desktop application portability * security * partial docker alternative * promoting adoption and access of applications written lesser popular languages

durandal1 2y ago
You are not wrong, but it solves another really hard business problem: Hiring and retaining good engineers.
DarkNova6 2y ago
But Blazor seems to do a fine job replacing JS with C#? If you really want go to all-native JS because it has advantages, sure you can do. But what I see are bloated SPAs written in a language not designed for large software, based on an environment that likes to change and break things. It's abstractions upon abstractions get a hold of this mess. I don't see why WASM couldn't compete.
- pjmlp 2y ago
  Blazor is doing a fine job being a home for WebForms and Silverlight refugees, how far it will stay relevant remains to be seen. On my job I have zero reasons to suggest it, given the split between FE and BE teams.

iwillsayit 2y ago

The real value in Wasm is in the Web use case: bring to the most popular platform software that was impossible (or very difficult) to bring before. Just look at Ruffle (Flash Player reimplementation), V86 (x86 virtual machine), Google Earth, ... Wasm on the Server is a fad, and sadly it's hijacking resources and design space from the real thing. WASI being a prime example: because of the "Component model", any attempt at tighter integration with the Browser API stopped in the hope for a magical solution to all computing problems.

01HNNWZ0MV43FF 2y ago
I have high hopes for wasm on the desktop for app plugins. Loading a whole binary DLL/SO is such a risk. VMs like Lua don't give you enough performance. VMs like Python and Java require huge effort to embed. Once the SIMD stuff is in, it may even have enough performance for music plugins. wasm codecs would be real cool too. Nobody likes having to build and install ffmpeg. `ffmpeg-4.0.wasm`... just imagine.
- Traubenfuchs 2y ago
  > VMs like Python and Java require huge effort to embed. As a (backend) Java dev, I couldn't let that stand. And indeed I found out java now offers a tool called jlink with first class support, that will create a system native (e.g. .dmg on my macbook) executable with the JRE embedded. The javafx example project* I found could be downloaded, built and run from its native release all within less than 5 minutes. Mind you the Hello World example executable is 80mb and takes 6 seconds to start, but I feel like with the garbage we are used to in regards to desktop applications, this totally holds up -doesn't everything else usually bundle all of chrome? I have also read there are simple command line options to reduce the size to about 50mb. * https://github.com/mjparme/javafx-template https://github.com/mjparme/javafx-template
  - eviks 2y ago
    But all of Chrome doesn't take 6 seconds to start

azakai 2y ago

This quote from the end of the article is good: > With this in mind, maybe Wasm is mainstream. Spencer notes, for instance, that anyone who browses the web is likely to be interacting with WebAssembly on a daily basis. I think that's correct. Non-Web usecases are a more complicated story (that the article focuses on), but the Web side is largely complete and successful, and that was the original purpose of Wasm. In that sense it's already succeeded.

LunaSea 2y ago
Really? I can't think of a mainstream (as in used daily) site that uses WASM. Do you have some in mind?
- hermanradtke 2y ago
  https://madewithwebassembly.com/ https://madewithwebassembly.com/ I see a few major sites and some major plugins. The definition of "mainstream (as in used daily) site" may differ between groups.
- callahad 2y ago
  Figma has been powered by WebAssembly for the past 7 years.
  - kamikazeturtles 2y ago
    What parts of Figma though? Is it just used for cpu intensive operations like triangulation of svgs to render in webgl or is the site's core logic all done is wasm? I'm sorry, I don't use Figma but I'm really curious about its tech stack
    - azakai 2y ago
      They have a bunch of nice blogposts about that: https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-... The main part of the app is in wasm, I believe (it's in C++ that they compile).

6510 2y ago

The assumption is that javascript is bad and that the solution is to not fix it. asm.js was another example.

lxgr 2y ago
asm.js was the opposite of an alternative to JavaScript: It was a performant JavaScript dialect used as a compilation target for various languages otherwise targeting emscripten. WASM is the spiritual successor to that, getting rid of the (in retrospect quite hilarious) "embedded backwards compatibility layer".
- 6510 2y ago
  You don't compile to js because js is slow. edit: for the record, I think having only one doc type (html) and only one scripting language (js) in the browser is a terrible idea. I don't know what the other doc types and programming languages should be but performance alone seems like a poor idea. A compile target seems even worse. :)

pjmlp 2y ago

I really don't see much of a value outside the browser, other than an avenue for startups to resell yet another bytecode based platform, as if we haven't had enough since UNCOL (1958). The ongoing attempts to bring back application servers, but with Kubernetes, WASM and plenty of YAML, is a kind of tragic irony. And on the browser, if one needs performance it is better served with GPU code than WebAssembly, other than bringing existing libraries into the browser. At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations.

lxgr 2y ago
> if one needs performance it is better served with GPU code than WebAssembly What? No! Would you suggest replacing e.g. the Linux kernel (parts of which are very performance critical) with GPU code too? WebGPU is great for, well, GPU-like compute! That's not nearly all performance-critical compute. One example: Stockfish, a top chess engine, is exclusively CPU-based, and runs perfectly in WASM. > At least we got the revenge of plugins, Flash, ActiveX and Java applets, running back on the browser thanks to WebAssembly based implementations. Couldn't disagree more. Flash, ActiveX and Java were unpopular because they all came with their own weird/non-native-feeling GUI toolkits and UI paradigms (e.g. breaking right clicks and text selection, Ctrl+F etc.). Flash and ActiveX were also closed source and only available on some platforms. ActiveX was also very badly sandboxed on top of all of that. WASM is none of that. The only thing you'd notice e.g. about a site bringing its own media codec, game engine etc. in WASM instead of JavaScript is better performance.
- pjmlp 2y ago
  Linux kernel isn't supposed to run in the browser. Indeed WASM is nothing like yet bytecode being capitalised by startups, in search of the next Java goldmine, by folks that enjoy bashing about it. /s App servers bad, Kubernetes with WASM, "oh boy that is soooo cool!".
  - lxgr 2y ago
    I think many people like the idea of bytecode, but not the implementation of Java/the JVM (especially if they have an existing codebase or don't want to start a new one in Java), and I think that's pretty fair.

justahuman74 2y ago

I haven't been keeping up, can I write webpages that replace all javascript with wasm yet?