5 ms·

'WebAssembly Is Finally Usable, Almost'

20 points by MilnerRoute 2y ago

mcint 2y ago
A forbes article on this? Perhaps it's the contributor '/sites/' that I'm not familiar with.
- pzmarzly 2y ago
  AFAIK /sites subpath is mostly for articles made by "Forbes Contributors". How does one become one? You need to be invited by one of employees[0], but then it seems you can publish whatever with little editorial oversight[1]. You get paid, starting at $250 a month[2]. Personally, I find the idea nice, but a lot of these contributor articles seem to be poorly written anyways, so I try not to bother with them. But I guess that compared to a lot of other places in modern internet, especially medium.com and a ton of blogspammy wordpress sites, these must still look like Shakespeare in comparison. [0] https://joshsteimle.com/writing/who-do-i-contact-at-forbes-to-become-a-contributor.html https://joshsteimle.com/writing/who-do-i-contact-at-forbes-t... [1] https://getonforbes.com/forbes-contributor-guest-posting/ https://getonforbes.com/forbes-contributor-guest-posting/ [2] https://www.forbes.com/sites/randalllane/2018/02/14/why-forbes-is-investing-big-money-in-its-contributor-network/ https://www.forbes.com/sites/randalllane/2018/02/14/why-forb...
  - mcint 2y ago
    Once I noticed the surprisingly consistent, legibly distanced branding, I imagined something -- actually more like contributors paying. Thank you for the research & explanation!
flohofwoe 2y ago
WebAssembly has been working just fine since 2017. This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from second-system effect at best, or Rust people ruining a perfectly fine standard (WASI 0.1) at worst.
- dxhdr 2y ago
  What problems is WASI 0.2 and the Component Model solving? I've read the project goals but I still don't quite understand. I mean, I guess having some defined interface between languages might be useful for some specific usecases, I just don't see what that has to do with WASM and I also don't understand how this complexity would be a net benefit to the broader ecosystem.
  - leucippe 2y ago
    For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems. WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language. HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together. Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests. Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces: But if a function takes or returns anything besides numbers, things get complicated. You can either: - Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user. - Add glue code for every single environment you want this module to run in… making life hard for the module’s developer. Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings. The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things". [1]: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...
drozycki 2y ago
Figma has been using wasm in production since 2017. Wasm in the browser has its niches, but JS remains the best choice when considering load time and transfer size. JS is not the pinnacle of dev experience, but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code. All browsers have JS batteries included, for better and for worse.
- flohofwoe 2y ago
  > but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code. It's really not that bad for languages that allow an embedded-programming style (C, Rust, C++, Zig, ...). For instance this C64 emulator written in C has a 97.5 KBytes compressed WASM blob (and this includes 20 KBytes of dense ROM data which is barely reduced in size when compressed), plus 14 KBytes for the JS shim: https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html By comparison, the minified and compressed main.js file of JS Beeb (which I assume contains the bulk of the emulation code) is 119 KBytes download size: https://bbc.xania.org/ https://bbc.xania.org/
- josephg 2y ago
  > JS remains the best choice when considering load time and transfer size. Wasm often has a larger transfer size (although wasmgc might go a long way toward alleviating this). But it also often has a smaller load time. Web browsers can load equivalently sized wasm bundles much faster than they can load JavaScript.
  - drozycki 2y ago
    Where can I learn more about this?
- pjmlp 2y ago
  Additionally if computation performance is a bottleneck, just write some shader code, much easier than dealing with WebAssembly toolchains.
pjmlp 2y ago
Says interview with a startup that promotes WebAssembly.
- nilslice 2y ago
  and not even standard Wasm, but a problematic, unfinished abstraction layer…
andrewstuart 2y ago
When I looked into Web Assembly I was surprised to find it doesn't drive the DOM.
- flohofwoe 2y ago
  I really wonder why the DOM always comes up. The DOM is just one browser API among many, and WASM is a virtual instruction set. Browser APIs have been designed for Javascript (for better or worse) meaning they work with Javascript objects and properties. WASM isn't Javascript, and it only works with floats and integers, so it needs an FFI layer to talk to browser APIs. In the end, calling from WASM into JS isn't all that different than calling from native machine code into a virtual machine like .NET or the JVM.
  - pjmlp 2y ago
    For me the best way to think about WebAssembly, is to use the same approach as to keep a sane NDK experience on Android, write the code in a way that is always called from the host, instead of a interweb from down and upcalls.
  - kreetx 2y ago
    But WASM is a virtual instruction set for the browser, so wouldn't it be convenient (and maybe fast) to control DOM from it? I guess one can run WASM on servers, too, but aren't there plenty of ways there to do it already?
    - flohofwoe 2y ago
      > But WASM is a virtual instruction set for the browser Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind. You can manipulate the DOM from WASM by calling through a Javascript shim with very little overhead, same as it works for calling into other browser APIs like WebGL, WebGPU or WebAudio. It just doesn't make all that much sense since WASM doesn't bring any benefit compared to manipulating the DOM via Javascript. Any theoretical performance advantage is pointless because the entire architecture of the DOM is slow by design. But if you still want to do it, there are helpers like the Rust web_sys crate: https://rustwasm.github.io/wasm-bindgen/api/web_sys/ https://rustwasm.github.io/wasm-bindgen/api/web_sys/ Here's a simple DOM hello world: https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html
aitchnyu 2y ago
Cross platform apps with declarative UI; universal document format; filesystem permissions; cross platform, secure, C-speed VM; web has scooped OSes yet again.
singularity2001 2y ago
HN has obligatory tags for articles from previous years, maybe after (almost) two months this warrants an "old / repeat / April" tag too? I'm certain this was discussed before.

20 points by MilnerRoute 2y ago

mcint 2y ago

A forbes article on this? Perhaps it's the contributor '/sites/' that I'm not familiar with.

pzmarzly 2y ago
AFAIK /sites subpath is mostly for articles made by "Forbes Contributors". How does one become one? You need to be invited by one of employees[0], but then it seems you can publish whatever with little editorial oversight[1]. You get paid, starting at $250 a month[2]. Personally, I find the idea nice, but a lot of these contributor articles seem to be poorly written anyways, so I try not to bother with them. But I guess that compared to a lot of other places in modern internet, especially medium.com and a ton of blogspammy wordpress sites, these must still look like Shakespeare in comparison. [0] https://joshsteimle.com/writing/who-do-i-contact-at-forbes-to-become-a-contributor.html https://joshsteimle.com/writing/who-do-i-contact-at-forbes-t... [1] https://getonforbes.com/forbes-contributor-guest-posting/ https://getonforbes.com/forbes-contributor-guest-posting/ [2] https://www.forbes.com/sites/randalllane/2018/02/14/why-forbes-is-investing-big-money-in-its-contributor-network/ https://www.forbes.com/sites/randalllane/2018/02/14/why-forb...
- mcint 2y ago
  Once I noticed the surprisingly consistent, legibly distanced branding, I imagined something -- actually more like contributors paying. Thank you for the research & explanation!

flohofwoe 2y ago

WebAssembly has been working just fine since 2017. This article is just hype for WASI 0.2 and the Component Model, which at closer look seems to suffer from second-system effect at best, or Rust people ruining a perfectly fine standard (WASI 0.1) at worst.

dxhdr 2y ago
What problems is WASI 0.2 and the Component Model solving? I've read the project goals but I still don't quite understand. I mean, I guess having some defined interface between languages might be useful for some specific usecases, I just don't see what that has to do with WASM and I also don't understand how this complexity would be a net benefit to the broader ecosystem.
- leucippe 2y ago
  For background, WASI 0.1 is one interface: a smaller POSIX. Translating POSIX's low-level ABI concepts into WASM is enough for this. WASI came out of WASM's goal of portability, and 0.1 makes WASM portable across POSIX systems. WASM and WASI aim to support other embeddings. WASI 0.2 introduces an interface for HTTP servers and clients, aimed at cloud/edge. Currently Docker images (on an OS) get used here, but POSIX, even small POSIX, is bloat. WASI 0.2 plans a range of other interfaces for embedding WASM e.g. IOT, so that even without POSIX, you still have portable standards, in your preferred language. HTTP is a high-level idea. HTTP libraries in any language are never about writing binary to TCP sockets, they're about requests and responses. Depending on sockets would miss the point of leaving POSIX behind. A smaller, loosely-coupled API surface gives both sides more freedom. The runtime can work with the system, the language can work with its users, and the tooling can generate minimal glue that links them together. Why define WASI APIs with an abstract interface rather than a rigid binary one? Because it follows the spirit of WASM's existing goals: low-level when needed for performance, and high-level whenever it makes WASM simpler to target, embed or reason about. That's why WASM has low-level assembly instructions yet high-level structured control-flow. It's also why WASI uses types appropriate for the API in question (e.g. files in the POSIX interface, responses in HTTP) yet translates them to binary glue when linking real hosts and guests. Lin Clark's 2019 article[1] raises an issue that comes with low-level interfaces: But if a function takes or returns anything besides numbers, things get complicated. You can either: - Ship one module that has a really hard-to-use API that only speaks in numbers… making life hard for the module’s user. - Add glue code for every single environment you want this module to run in… making life hard for the module’s developer. Clark argues WebAssembly is the right abstraction level to solve this issue in an efficient yet ergonomic way. Frankly, if your WASM module written in Go wants to talk to your host in Java, I don't see why that needs to involve C bindings. The Component Model falls out of WASI as a bonus. WASI needs to interoperate modules with their embeddings. From there WASI may as well (Lin Clark puts it) "interoperate all the things". [1]: https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...

drozycki 2y ago

Figma has been using wasm in production since 2017. Wasm in the browser has its niches, but JS remains the best choice when considering load time and transfer size. JS is not the pinnacle of dev experience, but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code. All browsers have JS batteries included, for better and for worse.

flohofwoe 2y ago
> but any other language has megabytes of runtime or libraries which need to be fetched and loaded before your application code. It's really not that bad for languages that allow an embedded-programming style (C, Rust, C++, Zig, ...). For instance this C64 emulator written in C has a 97.5 KBytes compressed WASM blob (and this includes 20 KBytes of dense ROM data which is barely reduced in size when compressed), plus 14 KBytes for the JS shim: https://floooh.github.io/tiny8bit/c64.html https://floooh.github.io/tiny8bit/c64.html By comparison, the minified and compressed main.js file of JS Beeb (which I assume contains the bulk of the emulation code) is 119 KBytes download size: https://bbc.xania.org/ https://bbc.xania.org/
josephg 2y ago
> JS remains the best choice when considering load time and transfer size. Wasm often has a larger transfer size (although wasmgc might go a long way toward alleviating this). But it also often has a smaller load time. Web browsers can load equivalently sized wasm bundles much faster than they can load JavaScript.
- drozycki 2y ago
  Where can I learn more about this?
pjmlp 2y ago
Additionally if computation performance is a bottleneck, just write some shader code, much easier than dealing with WebAssembly toolchains.

pjmlp 2y ago

Says interview with a startup that promotes WebAssembly.

nilslice 2y ago
and not even standard Wasm, but a problematic, unfinished abstraction layer…

andrewstuart 2y ago

When I looked into Web Assembly I was surprised to find it doesn't drive the DOM.

flohofwoe 2y ago
I really wonder why the DOM always comes up. The DOM is just one browser API among many, and WASM is a virtual instruction set. Browser APIs have been designed for Javascript (for better or worse) meaning they work with Javascript objects and properties. WASM isn't Javascript, and it only works with floats and integers, so it needs an FFI layer to talk to browser APIs. In the end, calling from WASM into JS isn't all that different than calling from native machine code into a virtual machine like .NET or the JVM.
- pjmlp 2y ago
  For me the best way to think about WebAssembly, is to use the same approach as to keep a sane NDK experience on Android, write the code in a way that is always called from the host, instead of a interweb from down and upcalls.
- kreetx 2y ago
  But WASM is a virtual instruction set for the browser, so wouldn't it be convenient (and maybe fast) to control DOM from it? I guess one can run WASM on servers, too, but aren't there plenty of ways there to do it already?
  - flohofwoe 2y ago
    > But WASM is a virtual instruction set for the browser Depends on how you look at it. WASM itself doesn't have any browser specific features (and on purpose), it's a universal bytecode VM designed with strict sandboxing in mind. You can manipulate the DOM from WASM by calling through a Javascript shim with very little overhead, same as it works for calling into other browser APIs like WebGL, WebGPU or WebAudio. It just doesn't make all that much sense since WASM doesn't bring any benefit compared to manipulating the DOM via Javascript. Any theoretical performance advantage is pointless because the entire architecture of the DOM is slow by design. But if you still want to do it, there are helpers like the Rust web_sys crate: https://rustwasm.github.io/wasm-bindgen/api/web_sys/ https://rustwasm.github.io/wasm-bindgen/api/web_sys/ Here's a simple DOM hello world: https://rustwasm.github.io/wasm-bindgen/examples/dom.html https://rustwasm.github.io/wasm-bindgen/examples/dom.html

aitchnyu 2y ago

Cross platform apps with declarative UI; universal document format; filesystem permissions; cross platform, secure, C-speed VM; web has scooped OSes yet again.

singularity2001 2y ago

HN has obligatory tags for articles from previous years, maybe after (almost) two months this warrants an "old / repeat / April" tag too? I'm certain this was discussed before.