20 ms·

A world to win: WebAssembly for the rest of us

297 points by nsm 4y ago

DeathArrow 4y ago
Blazor had to ship the whole .NET runtime to have support for garbage collector and threads.
- qclibre22 4y ago
  How big is it?
  - HideousKojima 4y ago
    I think it's currently around 2 MB, they've been working on shrinking the download with each new .NET release
    - nirav72 4y ago
      It's great that they're trying to reduce the .net browser runtime size. But I'm really hoping this works out well: https://www.youtube.com/watch?v=48G_CEGXZZM https://www.youtube.com/watch?v=48G_CEGXZZM One of the biggest pain points of blazor wasm is the initial load times. So if as described in the above video works, then devs can use blazor server pages for initially rendering layout, while the blazor wasm part is downloading in the background.
deleted 4y ago
[deleted]
tjoff 4y ago
>the initial version of WebAssembly is a terrible target if your language relies on the presence of a garbage collector. Lack of GC was one of the appealing parts of WASM to me. Keep it simple. It is good to be careful about utilizing memory on your visitors machines, so you better spend a lot of thought on memory management.
- wahern 4y ago
  If the WASM module has no GC'able objects, then there'd be no reason for the GC to run. At least in theory. Certainly the 0 GC'able object case seems like an easy optimization.
  - tjoff 4y ago
    Yeah, but once GC is an option 99% of the sites you are going to visit will utilize it and use as much resources that they could ever "get away" with.
    - remexre 4y ago
      Isn't it more likely that if there never was first-party GC, everyone who wants GC is just going to bundle a bad one instead, making those sites _slower_?
      - evntdrvn 4y ago
        That’s already happening with .NET, yeah
    - wahern 4y ago
      Maybe. Everybody assumes that once WASM gets a GC framework that their favorite language, e.g. Python, will become a first-class citizen. But I suspect this won't come to pass for two related reasons: 1) There's no such thing as a universal GC. GC semantics differ across languages because the semantics matter; language developers make different choices. For example, some GCs support finalizers, others don't. Some with finalizers support resurrection, some don't; likewise, some languages specify a well-defined order for finalization (e.g. Lua defines it as the reverse order of allocation). 2) Similar to GC, there are other aspects that will prevent popular languages with complex runtimes from being compiled directly to WASM without altering language semantics or the runtime behavior relative to the standard, native environment. For example, eval. So even with GC, the choices will likely remain the same as they are now: if you want the full experience of your favorite, rapid-development language within the WASM virtual machine, you must incur runtime overhead, up to and including double virtualization. Or, alternatively, you must contend with a bifurcation in a language ecosystem--native semantics vs WASM semantics. This will all be compounded by how programmers typically treat even the slightest differences, compromises, or concessions in behavior or performance as ritual impurities to be shunned. Ultimately, I don't expect the current status quo changing--languages other than statically compiled, strongly typed, non-GC'd languages like C, C++, Rust, or similar seeing much more usage in WASM environments than they already do, either browser-side or server-side.
FpUser 4y ago
>" Where are the F#, the Elixir, the Haskell compilers? " I think it makes a lot of sense sense to target WebAssembly with high performance "native" languages like C/C++/Rust/Zig/etc for certain types of apps looking for high performance computations. As for the rest it is simpler to just use JavaScript as the browser already makes a great platform for it.
- chrisco255 4y ago
  WASM isn't just for the browser though.
  - buzzerbetrayed 4y ago
    Where else is WASM being run? Is WASM the eventual holy grail solution to writing cross platform desktop applications?
    - genjii931 4y ago
      On the server, of course.
    - flohofwoe 4y ago
      The "only" thing missing for this is to extend WASI beyond POSIX APIs (e.g. you'd need at least 3D rendering, audio and input APIs), but don't hold your breath I guess ;)
- RobotToaster 4y ago
  Haskell already transpiles to C or JS anyway.
- genjii931 4y ago
  What about them? Ask the maintainers why they don't support targeting wasm, cuz that who's responsible for that part of it. That isn't in the browser or wasm itself.
syrusakbary 4y ago
This is awesome, always great to read Andy Wingo blogposts. Eager to see what the future of Scheme in Wasm looks like! Here's a bit more or info on the Spritely side on why they want Scheme in Wasm (it's both funny and great to see how the money on decentralized/web3 projects is leaking back to the real world!) https://spritely.institute/news/guile-on-web-assembly-project-underway.html https://spritely.institute/news/guile-on-web-assembly-projec...
Aleklart 4y ago
TIL assembler for web will have garbage collector and can’t access web.
AtNightWeCode 4y ago
WASM was cool but then all the trouble came. I am more reluctant to use WASM in production today than a couple of years ago. Seems like the biz agrees...
eachro 4y ago
Sorry for the noob question but what can you do with web assembly that you wouldnt otherwise do with other web frameworks? What are people using web assembly for generally?
- ultra_nick 4y ago
  You can't compile existing C++ or Rust programs to React or other frameworks. It's used to compile your app in a format that can run on any machine with a web browser.
- vbezhenar 4y ago
  WebAssembly brings absolutely zero new features to web. You can get predictable performance for some code and that's about it. Think about it as an optimisation. There's much more hype than essence there. You could compile C++ or Java to JavaScript 10 years ago. Bellard's jslinux was implemented with JavaScript originally and it was enough to emulate x86 in the browser.
  - flohofwoe 4y ago
    > You could compile C++ ... to JavaScript 10 years ago. That's true, but to get any sort of 'near-native' performance out of that approach, browsers had to add special support for asm.js, running asm.js as regular Javascript would loose 3..10x performance compared to 'special cased' asm.js (if I remember right - for instance iOS Safari never added this special asm.js support, and once it supported WASM the performance jump from asm.js to WASM was dramatic and much bigger than desktop browsers which already had added special asm.js support before). Compared to an asm.js special case in a Javascript engine, the WASM approach just makes a lot more sense, because Javascript can now focus again on being a programming language and not also being a good compile target.
  - kevingadd 4y ago
    It's hard to overstate how much faster WebAssembly is compared to what we had before the advent of asm.js. It's so much faster that it really does enable you to do things you couldn't do before because it was too slow. Also, WASM does expose things that (afaik) aren't available in JS, like int64, SIMD, atomics, etc.
oneplane 4y ago
A place where this is relevant that hasn't been mentioned so far is in proxies using the ProxyWASM spec. Instead of loading random libraries into the main code of say, Envoy, you instead load it as a WASM module (so you must target WASI or wasm32-unknown) and all you're allowed to do is specify a set of pre-determined entry points for when traffic connects, sends headers, sends body, and on the return path responds with headers, then body and then disconnects. This means that you can do practically all the things you need to do in a pretty portable way, without breaking into the actual program.
pipeline_peak 4y ago
> What about Haskell, Ocaml, Scheme, F#, and so on – what about us? I think the industry will get by…
doomleika 4y ago
I would refer to Kelsey Hightower's random twitter space[1]. The last 15 min will do. On paper it's nice and all but it's just not there yet. I've seen so many hype around WASM since 20 but the promised vision is always "any time soon", this triggers my hype alarm a lot. Say what you will about Frontend/js ecosystem, at least most js project tells you exactly what value it will bring within 3 screen scrolls. I believe it's better for rest of the SWE community take a page or two from js. [1]: https://twitter.com/kelseyhightower/status/1636786572673814528 https://twitter.com/kelseyhightower/status/16367865726738145...
- flohofwoe 4y ago
  WASM delivers, the only problem is that it is unreasonably hyped by people who either don't quite know what it actually is, or who want to push their WASM startup.
rr808 4y ago
Can we bring back java applets? It was unsafe back in the day, but if we can do wasm surely we can do applets? Lots of good languages and libraries for jvm.
- jillesvangurp 4y ago
  If you need that, you can: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ Can't vouch for their solution but looks like they do what you ask for.
- yuri91 4y ago
  There you go: https://chrome.google.com/webstore/detail/cheerpj-applet-runner/bbmolahhldcbngedljfadjlognfaaein?hl=en https://chrome.google.com/webstore/detail/cheerpj-applet-run...
nsteel 4y ago
How do browser standards work w.r.t ensuring things like wasm are still here and functional in 10 years time? What if our friends at Google, controllers of the most popular browser, decide they can't be bothered with WebAssemnly anymore? I'm extremely wary to invest resources in things they control. I know they don't technically have control here, but is there any cause for concern?
- flohofwoe 4y ago
  Well, ultimately if Google decides that Chrome won't support WASM anymore than it's over, same as Apple decided that Flash is over (or Google decided that NaCl would be over and they put their effort into supporting WASM instead). But: WebGL1 is much more niche than WASM and it's still around and well supported after 12 years. WASM was announced in 2015 and released in 2017, so it's also not exactly "new" anymore. WASM is such a small part of browsers (for instance compared to a JS engine) that dropping it would really not be worth it. It just delivers too much bang for the buck.
- kevingadd 4y ago
  WebAssembly is so widely used at this point that it would need a replacement first. Once that replacement shows up and becomes adopted widely you can start worrying. "Just use JavaScript and WebGL/Canvas" was a big part of the justification for why it was OK to shoot Flash and Unity in the head.
phendrenad2 4y ago
It's been so long since webassembly was announced, I don't remember why I was ever excited about it. I don't think it serves much of a purpose in 2023, as Javascript JITs are quite fast.
sinistersnare 4y ago
Andy Wingo's blog is awesome. A great resource for those interested in PL design and development. I learned a bunch of stuff about delimited control from this blog, among other things. Also, Andy implements delimited control in this post! What a legend
Animats 4y ago
Rust targets WebAssembly, which apparently works well because Rust is not garbage-collected. When will WebAssembly get real threads, not just shared memory between processes? I've seen articles from years ago talking about it as a future feature. Current status?
- AtNightWeCode 4y ago
  When time skews and you get sent back a decade or two.
- nine_k 4y ago
  What do you need for "real" threads functionality, beside shared memory? Shared mutexes? Fair; Rust somehow implements them, but I don't know how. Shared file descriptors, sockets, etc? They don't seem to exist, and if they did, I think sending (moving) them between threads in a message would do the trick. What else am I missing?
  - Animats 4y ago
    More compute power, for games. I need about a half dozen CPUs running flat out.
- vbezhenar 4y ago
  What's the difference between real threads and shared memory between processes? I don't really follow. Memory object is all you have in webassembly for your process. If it's shared between multiple workers, you basically get threads.
  - kevingadd 4y ago
    Among other problems, each worker has to instantiate all the host javascript objects and instantiate its own copy of the wasm module, which has its own unique copy of the imports and the function pointer table. It's definitely way less elegant than real threads and potentially creates performance and stability issues. You also now have fun thread affinity problems, like if you call setTimeout your timer IDs now have thread affinity, which is nonsense.
kumarski 4y ago
cloudflare did a piece on how WASM supports it. ~18% of all websites on the web run through cloudflare. https://blog.cloudflare.com/big-pineapple-intro/ https://blog.cloudflare.com/big-pineapple-intro/ (I'm not a software developer)
RjQoLCOSwiIKfpm 4y ago
All I hear when someone writes "WebAssembly is coming" is "more RCE exploits are coming - via the thousands of lines of new code I have to hook up to the Internet by using a browser". The industry has barely finished debugging the monstrosity that was browsers before - XML, JavaScript, CSS, WebGL, WebRTC, ... so now let's add another giant source of security issues to them! When will this madness stop? When will browsers actually be capable of doing enough and be moved into maintenance-only mode where only security issues are fixed and no new code is added? Surely some will say "well, WebAssembly will deliver that precisely - browsers now can run all the code". But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML? Anyway, to deliver some value by this comment: To disable WASM in Firefox, set "javascript.options.wasm = false" in about:config. Some websites say you also need to set "javascript.options.wasm_baselinejit = false" and "javascript.options.wasm_ionjit = false" but I don't understand what the point of disabling JIT would be if the whole of WASM is disabled anyway?
- shortrounddev 4y ago
  > But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML? The problem is javascript sucks. We want to be able to write any kind of application, but we don't want to have to do it in javascript. Ideally, this would mean that you pick Java or C# instead and use one of several cross-platform UI frameworks, but I've never found a native UI framework that was as easy to work with as HTML. If C# would just let us write native UI with HTML and CSS (and not just using electron), then I would never write a webapp again
  - tijsvd 4y ago
    Would it not be feasible to turn electron inside out, and have chromium as a library, with bindings for various languages?
    - deathanatos 4y ago
      I don't think so, no, or rather, I think you might lose out on "the web" part of it. That is, that the web really is a bunch of stuff, all accessible in one "thing", and stuff can and does "link" to various other stuff. E.g., consider an OIDC log in. It's really one app (the relying party), redirecting to a whole different app (your SSO of choice). You can't exactly do that in another app without, I think, really running into issues of "is it my SSO, or a phish?". The browser provides that trusted layer of "I am look at this app" (via the URL bar). And even then … that's fraught with absolutely immense tons of peril. It's also a distribution mechanism: I don't have to download Slack, Discord, Postman, etc. — I just go to a URL, and the browser downloads the code needed. (I can and do download some of these, and there are some advantages to do so. But then extend it to every app I use on the web: my bank, Turbotax, my email, my three different loan payment sites, my landlord's payment site … that'd be far too many downloads.)
DeathArrow 4y ago
My question is when will web assembly able to access the DOM without the need to call Javascript to jump back and forth.
- flohofwoe 4y ago
  That's how all browser APIs are accessed from WASM, the DOM is nothing special in that regard. The only way for WASM to interact with the 'outside world' is through import and export function tables, and at least in the browser all functions in the import table will be Javascript functions. The only alternative would be for all browser Javascript APIs to get a separate "native C-like API" which could be plugged into the WASM import table and circumvent Javascript. That's basically how NaCl worked, with the downside that it only exposed a very small slice of browser APIs, for everything else one had to interact with Javascript via messaging, and this was a massively royal PITA. WASM does everything right in that regard.
- kitkat_new 4y ago
  it's less important than you probably think: https://news.ycombinator.com/edit?id=35240914 https://news.ycombinator.com/edit?id=35240914
- moffkalast 4y ago
  Isn't Wasm just stuff transpiled to javascript and then pre-interpreted to bytecode anyway? The ole' Emscripten console port.
  - deathanatos 4y ago
    No. WASM is its own byte-code, which can be either interpreted directly, or JIT'd to machine code. There's no transpile to JS step. (There's a text representation too.)
    - moffkalast 4y ago
      Wait was that asm.js then? It's so confusing, I swear that each time I check I find people claiming different things about this.
mrbonner 4y ago
One question that really bugs me the the sandbox security model. I'm sure the model protects us from memory and IO hazards. But, what about CPU-time sharing protection? I have yet to know if WebAss (or any abstract machine out there) could provide protection from a rouge module, running at 100% CPU in an infinite loop. I'm sure a true virtual machine could limit such thing. Edit: spelling
- pphysch 4y ago
  What's the difference between <script>WebAssembly.instantiateStreaming(fetch("cpu_waster.wasm")...</script> and <script>while (true){};</script> ?
  - kevingadd 4y ago
    The former is asynchronous.
    - pphysch 4y ago
      It's still gonna waste a whole CPU (at least)
- flohofwoe 4y ago
  It's the same as running a Javascript infinite loop. The browser will kill the tab if a WASM module doesn't yield back to the browser's event loop after a few seconds.
- deathanatos 4y ago
  Yes, they can. You instrument the module/byte code/JIT'd code to consume a virtual "gas", and when it's consumed, execution returns to the host. E.g., in wasmtime: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#... (I presume the browsers implement something similar, but I've not tested it to see.)
  - kevingadd 4y ago
acqq 4y ago
It seems this is the current doc about the GC: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... Looking at the "instructions" section... is it going to be slow again, bringing back the speed of interpreted code to the WASM?
- jillesvangurp 4y ago
  The new Kotlin WASM compiler uses this. You currently have to set some feature flags to unlock this in browsers: https://kotlinlang.org/docs/whatsnew-eap.html#how-to-enable-kotlin-wasm https://kotlinlang.org/docs/whatsnew-eap.html#how-to-enable-...

297 points by nsm 4y ago

DeathArrow 4y ago

Blazor had to ship the whole .NET runtime to have support for garbage collector and threads.

qclibre22 4y ago
How big is it?
- HideousKojima 4y ago
  I think it's currently around 2 MB, they've been working on shrinking the download with each new .NET release
  - nirav72 4y ago
    It's great that they're trying to reduce the .net browser runtime size. But I'm really hoping this works out well: https://www.youtube.com/watch?v=48G_CEGXZZM https://www.youtube.com/watch?v=48G_CEGXZZM One of the biggest pain points of blazor wasm is the initial load times. So if as described in the above video works, then devs can use blazor server pages for initially rendering layout, while the blazor wasm part is downloading in the background.

deleted 4y ago

[deleted]

tjoff 4y ago

>the initial version of WebAssembly is a terrible target if your language relies on the presence of a garbage collector. Lack of GC was one of the appealing parts of WASM to me. Keep it simple. It is good to be careful about utilizing memory on your visitors machines, so you better spend a lot of thought on memory management.

wahern 4y ago
If the WASM module has no GC'able objects, then there'd be no reason for the GC to run. At least in theory. Certainly the 0 GC'able object case seems like an easy optimization.
- tjoff 4y ago
  Yeah, but once GC is an option 99% of the sites you are going to visit will utilize it and use as much resources that they could ever "get away" with.
  - remexre 4y ago
    Isn't it more likely that if there never was first-party GC, everyone who wants GC is just going to bundle a bad one instead, making those sites _slower_?
    - evntdrvn 4y ago
      That’s already happening with .NET, yeah
  - wahern 4y ago
    Maybe. Everybody assumes that once WASM gets a GC framework that their favorite language, e.g. Python, will become a first-class citizen. But I suspect this won't come to pass for two related reasons: 1) There's no such thing as a universal GC. GC semantics differ across languages because the semantics matter; language developers make different choices. For example, some GCs support finalizers, others don't. Some with finalizers support resurrection, some don't; likewise, some languages specify a well-defined order for finalization (e.g. Lua defines it as the reverse order of allocation). 2) Similar to GC, there are other aspects that will prevent popular languages with complex runtimes from being compiled directly to WASM without altering language semantics or the runtime behavior relative to the standard, native environment. For example, eval. So even with GC, the choices will likely remain the same as they are now: if you want the full experience of your favorite, rapid-development language within the WASM virtual machine, you must incur runtime overhead, up to and including double virtualization. Or, alternatively, you must contend with a bifurcation in a language ecosystem--native semantics vs WASM semantics. This will all be compounded by how programmers typically treat even the slightest differences, compromises, or concessions in behavior or performance as ritual impurities to be shunned. Ultimately, I don't expect the current status quo changing--languages other than statically compiled, strongly typed, non-GC'd languages like C, C++, Rust, or similar seeing much more usage in WASM environments than they already do, either browser-side or server-side.

FpUser 4y ago

>" Where are the F#, the Elixir, the Haskell compilers? " I think it makes a lot of sense sense to target WebAssembly with high performance "native" languages like C/C++/Rust/Zig/etc for certain types of apps looking for high performance computations. As for the rest it is simpler to just use JavaScript as the browser already makes a great platform for it.

chrisco255 4y ago
WASM isn't just for the browser though.
- buzzerbetrayed 4y ago
  Where else is WASM being run? Is WASM the eventual holy grail solution to writing cross platform desktop applications?
  - genjii931 4y ago
    On the server, of course.
  - flohofwoe 4y ago
    The "only" thing missing for this is to extend WASI beyond POSIX APIs (e.g. you'd need at least 3D rendering, audio and input APIs), but don't hold your breath I guess ;)
RobotToaster 4y ago
Haskell already transpiles to C or JS anyway.
genjii931 4y ago
What about them? Ask the maintainers why they don't support targeting wasm, cuz that who's responsible for that part of it. That isn't in the browser or wasm itself.

syrusakbary 4y ago

This is awesome, always great to read Andy Wingo blogposts. Eager to see what the future of Scheme in Wasm looks like! Here's a bit more or info on the Spritely side on why they want Scheme in Wasm (it's both funny and great to see how the money on decentralized/web3 projects is leaking back to the real world!) https://spritely.institute/news/guile-on-web-assembly-project-underway.html https://spritely.institute/news/guile-on-web-assembly-projec...

Aleklart 4y ago

TIL assembler for web will have garbage collector and can’t access web.

AtNightWeCode 4y ago

WASM was cool but then all the trouble came. I am more reluctant to use WASM in production today than a couple of years ago. Seems like the biz agrees...

eachro 4y ago

Sorry for the noob question but what can you do with web assembly that you wouldnt otherwise do with other web frameworks? What are people using web assembly for generally?

ultra_nick 4y ago
You can't compile existing C++ or Rust programs to React or other frameworks. It's used to compile your app in a format that can run on any machine with a web browser.
vbezhenar 4y ago
WebAssembly brings absolutely zero new features to web. You can get predictable performance for some code and that's about it. Think about it as an optimisation. There's much more hype than essence there. You could compile C++ or Java to JavaScript 10 years ago. Bellard's jslinux was implemented with JavaScript originally and it was enough to emulate x86 in the browser.
- flohofwoe 4y ago
  > You could compile C++ ... to JavaScript 10 years ago. That's true, but to get any sort of 'near-native' performance out of that approach, browsers had to add special support for asm.js, running asm.js as regular Javascript would loose 3..10x performance compared to 'special cased' asm.js (if I remember right - for instance iOS Safari never added this special asm.js support, and once it supported WASM the performance jump from asm.js to WASM was dramatic and much bigger than desktop browsers which already had added special asm.js support before). Compared to an asm.js special case in a Javascript engine, the WASM approach just makes a lot more sense, because Javascript can now focus again on being a programming language and not also being a good compile target.
- kevingadd 4y ago
  It's hard to overstate how much faster WebAssembly is compared to what we had before the advent of asm.js. It's so much faster that it really does enable you to do things you couldn't do before because it was too slow. Also, WASM does expose things that (afaik) aren't available in JS, like int64, SIMD, atomics, etc.

oneplane 4y ago

A place where this is relevant that hasn't been mentioned so far is in proxies using the ProxyWASM spec. Instead of loading random libraries into the main code of say, Envoy, you instead load it as a WASM module (so you must target WASI or wasm32-unknown) and all you're allowed to do is specify a set of pre-determined entry points for when traffic connects, sends headers, sends body, and on the return path responds with headers, then body and then disconnects. This means that you can do practically all the things you need to do in a pretty portable way, without breaking into the actual program.

pipeline_peak 4y ago

> What about Haskell, Ocaml, Scheme, F#, and so on – what about us? I think the industry will get by…

doomleika 4y ago

I would refer to Kelsey Hightower's random twitter space[1]. The last 15 min will do. On paper it's nice and all but it's just not there yet. I've seen so many hype around WASM since 20 but the promised vision is always "any time soon", this triggers my hype alarm a lot. Say what you will about Frontend/js ecosystem, at least most js project tells you exactly what value it will bring within 3 screen scrolls. I believe it's better for rest of the SWE community take a page or two from js. [1]: https://twitter.com/kelseyhightower/status/1636786572673814528 https://twitter.com/kelseyhightower/status/16367865726738145...

flohofwoe 4y ago
WASM delivers, the only problem is that it is unreasonably hyped by people who either don't quite know what it actually is, or who want to push their WASM startup.

rr808 4y ago

Can we bring back java applets? It was unsafe back in the day, but if we can do wasm surely we can do applets? Lots of good languages and libraries for jvm.

jillesvangurp 4y ago
If you need that, you can: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ Can't vouch for their solution but looks like they do what you ask for.
yuri91 4y ago
There you go: https://chrome.google.com/webstore/detail/cheerpj-applet-runner/bbmolahhldcbngedljfadjlognfaaein?hl=en https://chrome.google.com/webstore/detail/cheerpj-applet-run...

nsteel 4y ago

How do browser standards work w.r.t ensuring things like wasm are still here and functional in 10 years time? What if our friends at Google, controllers of the most popular browser, decide they can't be bothered with WebAssemnly anymore? I'm extremely wary to invest resources in things they control. I know they don't technically have control here, but is there any cause for concern?

flohofwoe 4y ago
Well, ultimately if Google decides that Chrome won't support WASM anymore than it's over, same as Apple decided that Flash is over (or Google decided that NaCl would be over and they put their effort into supporting WASM instead). But: WebGL1 is much more niche than WASM and it's still around and well supported after 12 years. WASM was announced in 2015 and released in 2017, so it's also not exactly "new" anymore. WASM is such a small part of browsers (for instance compared to a JS engine) that dropping it would really not be worth it. It just delivers too much bang for the buck.
kevingadd 4y ago
WebAssembly is so widely used at this point that it would need a replacement first. Once that replacement shows up and becomes adopted widely you can start worrying. "Just use JavaScript and WebGL/Canvas" was a big part of the justification for why it was OK to shoot Flash and Unity in the head.

phendrenad2 4y ago

It's been so long since webassembly was announced, I don't remember why I was ever excited about it. I don't think it serves much of a purpose in 2023, as Javascript JITs are quite fast.

sinistersnare 4y ago

Andy Wingo's blog is awesome. A great resource for those interested in PL design and development. I learned a bunch of stuff about delimited control from this blog, among other things. Also, Andy implements delimited control in this post! What a legend

Animats 4y ago

Rust targets WebAssembly, which apparently works well because Rust is not garbage-collected. When will WebAssembly get real threads, not just shared memory between processes? I've seen articles from years ago talking about it as a future feature. Current status?

AtNightWeCode 4y ago
When time skews and you get sent back a decade or two.
nine_k 4y ago
What do you need for "real" threads functionality, beside shared memory? Shared mutexes? Fair; Rust somehow implements them, but I don't know how. Shared file descriptors, sockets, etc? They don't seem to exist, and if they did, I think sending (moving) them between threads in a message would do the trick. What else am I missing?
- Animats 4y ago
  More compute power, for games. I need about a half dozen CPUs running flat out.
vbezhenar 4y ago
What's the difference between real threads and shared memory between processes? I don't really follow. Memory object is all you have in webassembly for your process. If it's shared between multiple workers, you basically get threads.
- kevingadd 4y ago
  Among other problems, each worker has to instantiate all the host javascript objects and instantiate its own copy of the wasm module, which has its own unique copy of the imports and the function pointer table. It's definitely way less elegant than real threads and potentially creates performance and stability issues. You also now have fun thread affinity problems, like if you call setTimeout your timer IDs now have thread affinity, which is nonsense.

kumarski 4y ago

cloudflare did a piece on how WASM supports it. ~18% of all websites on the web run through cloudflare. https://blog.cloudflare.com/big-pineapple-intro/ https://blog.cloudflare.com/big-pineapple-intro/ (I'm not a software developer)

RjQoLCOSwiIKfpm 4y ago

All I hear when someone writes "WebAssembly is coming" is "more RCE exploits are coming - via the thousands of lines of new code I have to hook up to the Internet by using a browser". The industry has barely finished debugging the monstrosity that was browsers before - XML, JavaScript, CSS, WebGL, WebRTC, ... so now let's add another giant source of security issues to them! When will this madness stop? When will browsers actually be capable of doing enough and be moved into maintenance-only mode where only security issues are fixed and no new code is added? Surely some will say "well, WebAssembly will deliver that precisely - browsers now can run all the code". But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML? Anyway, to deliver some value by this comment: To disable WASM in Firefox, set "javascript.options.wasm = false" in about:config. Some websites say you also need to set "javascript.options.wasm_baselinejit = false" and "javascript.options.wasm_ionjit = false" but I don't understand what the point of disabling JIT would be if the whole of WASM is disabled anyway?

shortrounddev 4y ago
> But wasn't this the promise with JavaScript already, a Turing-complete language in the browser to end the need for more features of HTML? The problem is javascript sucks. We want to be able to write any kind of application, but we don't want to have to do it in javascript. Ideally, this would mean that you pick Java or C# instead and use one of several cross-platform UI frameworks, but I've never found a native UI framework that was as easy to work with as HTML. If C# would just let us write native UI with HTML and CSS (and not just using electron), then I would never write a webapp again
- tijsvd 4y ago
  Would it not be feasible to turn electron inside out, and have chromium as a library, with bindings for various languages?
  - deathanatos 4y ago
    I don't think so, no, or rather, I think you might lose out on "the web" part of it. That is, that the web really is a bunch of stuff, all accessible in one "thing", and stuff can and does "link" to various other stuff. E.g., consider an OIDC log in. It's really one app (the relying party), redirecting to a whole different app (your SSO of choice). You can't exactly do that in another app without, I think, really running into issues of "is it my SSO, or a phish?". The browser provides that trusted layer of "I am look at this app" (via the URL bar). And even then … that's fraught with absolutely immense tons of peril. It's also a distribution mechanism: I don't have to download Slack, Discord, Postman, etc. — I just go to a URL, and the browser downloads the code needed. (I can and do download some of these, and there are some advantages to do so. But then extend it to every app I use on the web: my bank, Turbotax, my email, my three different loan payment sites, my landlord's payment site … that'd be far too many downloads.)

DeathArrow 4y ago

My question is when will web assembly able to access the DOM without the need to call Javascript to jump back and forth.

flohofwoe 4y ago
That's how all browser APIs are accessed from WASM, the DOM is nothing special in that regard. The only way for WASM to interact with the 'outside world' is through import and export function tables, and at least in the browser all functions in the import table will be Javascript functions. The only alternative would be for all browser Javascript APIs to get a separate "native C-like API" which could be plugged into the WASM import table and circumvent Javascript. That's basically how NaCl worked, with the downside that it only exposed a very small slice of browser APIs, for everything else one had to interact with Javascript via messaging, and this was a massively royal PITA. WASM does everything right in that regard.
kitkat_new 4y ago
it's less important than you probably think: https://news.ycombinator.com/edit?id=35240914 https://news.ycombinator.com/edit?id=35240914
moffkalast 4y ago
Isn't Wasm just stuff transpiled to javascript and then pre-interpreted to bytecode anyway? The ole' Emscripten console port.
- deathanatos 4y ago
  No. WASM is its own byte-code, which can be either interpreted directly, or JIT'd to machine code. There's no transpile to JS step. (There's a text representation too.)
  - moffkalast 4y ago
    Wait was that asm.js then? It's so confusing, I swear that each time I check I find people claiming different things about this.

mrbonner 4y ago

One question that really bugs me the the sandbox security model. I'm sure the model protects us from memory and IO hazards. But, what about CPU-time sharing protection? I have yet to know if WebAss (or any abstract machine out there) could provide protection from a rouge module, running at 100% CPU in an infinite loop. I'm sure a true virtual machine could limit such thing. Edit: spelling

pphysch 4y ago
What's the difference between <script>WebAssembly.instantiateStreaming(fetch("cpu_waster.wasm")...</script> and <script>while (true){};</script> ?
- kevingadd 4y ago
  The former is asynchronous.
  - pphysch 4y ago
    It's still gonna waste a whole CPU (at least)
flohofwoe 4y ago
It's the same as running a Javascript infinite loop. The browser will kill the tab if a WASM module doesn't yield back to the browser's event loop after a few seconds.
deathanatos 4y ago
Yes, they can. You instrument the module/byte code/JIT'd code to consume a virtual "gas", and when it's consumed, execution returns to the host. E.g., in wasmtime: https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.consume_fuel https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#... (I presume the browsers implement something similar, but I've not tested it to see.)
- kevingadd 4y ago

acqq 4y ago

It seems this is the current doc about the GC: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP... Looking at the "instructions" section... is it going to be slow again, bringing back the speed of interpreted code to the WASM?

jillesvangurp 4y ago
The new Kotlin WASM compiler uses this. You currently have to set some feature flags to unlock this in browsers: https://kotlinlang.org/docs/whatsnew-eap.html#how-to-enable-kotlin-wasm https://kotlinlang.org/docs/whatsnew-eap.html#how-to-enable-...