
How WebAssembly Changes Software Distribution - ingve
https://desiatov.com/why-webassembly/
======
Rochus
Despite the author's obvious enthusiasm: WASM has a long way to go before it
is really useful. From my humble perspective there was not much progress since
the 1.0 release. As long as every access to the host (especially the GUI) is
tunneled via JavaScript, one shouldn't be surprised about the low performance
and the enormous memory consumption. See what happens behind the scenes when
you set a pixel in the SDL API when running a WASM app in the browser. And
there are plenty of good alternatives for the desktop already.

~~~
wffurr
It does feel like WebAssembly development has stalled after the initial
release. There are proposals for reference types, garbage collection, and host
bindings that would greatly expand a WebAssembly binary's capabilities, but
they haven't been implemented in any browser, much less standardized yet.

WebAssembly proposals tracker:
[https://github.com/WebAssembly/proposals](https://github.com/WebAssembly/proposals)

WebAssembly reference types ([https://github.com/WebAssembly/reference-
types/blob/master/p...](https://github.com/WebAssembly/reference-
types/blob/master/proposals/reference-types/Overview.md)) looks like the
blocker for a lot of things, and it's in the final spec phase at least.

In Chrome, it's behind a flag since 78, which went stable in Oct 22 2019:
[https://chromestatus.com/features/5166497248837632](https://chromestatus.com/features/5166497248837632)
But also under active development?
[https://bugs.chromium.org/p/v8/issues/detail?id=7581](https://bugs.chromium.org/p/v8/issues/detail?id=7581)

Supposedly implemented in Firefox two years ago:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1444925](https://bugzilla.mozilla.org/show_bug.cgi?id=1444925)

Nothing in Safari, of course.

Where is it now though?

~~~
maxgraey
> but they haven't been implemented in any browser, much less standardized
> yet.

Reference types already implemented. GC is not really needed for non-managed
languages like C++ or Rust. Interface types in progress.

See this: [https://webassembly.org/roadmap](https://webassembly.org/roadmap)

------
joshum97
I think Wasm outside the browser could benefit package managers. As far as I
know, Rust and some other compiled languages distribute their crates/packages
in source code form, which then have to be compiled before use. If packages
were distributed in Wasm (plus headers/type declarations), you could JIT or
quickly AOT compile them. Plus, you’d get safety guarantees to make sure a
package isn’t doing anything it hasn’t been permitted to do.

~~~
qppo
I dont think it would help at all for compiled languages actually. The reason
that they distribute source instead of binaries is mostly due to feature flags
and conditional compilation.

Seems a bit off track too. WASM is a very lossy compile target and that's not
acceptable for most compiles languages which need explicitness and assumptions
about the target machine for their optimizations (ones written by the
programmer, not the compiler). And the security concerns are tricky - sand
boxing is always expensive.

~~~
johncolanduoni
WASM’s memory access sandboxing is actually pretty cheap in most
implementations; all the major browser engines now use reserved virtual memory
with a segfault handler on most systems instead of range checks.

~~~
qppo
This just cements my belief that the abstraction presented by system
allocators is insufficient for modern applications. This shouldn't be done (or
necessary) in userspace.

------
MayeulC
I am wondering if it would be a huge project to create an "http server" kind
of Wasm binary. With php, rails or whatever server-side scripting a given
project is using. I guess it would still require some quite extensive changes
to the served HTML and js.

My use-case would be to create single instances of a server-side project, for
demonstration purposes, or serverless operation. Things like providing a
webapp for [https://kanboard.org](https://kanboard.org) or NextCloud.

As a bonus, this could be combined with webtorrent, or other distributed
mechanisms to let multiple "servers" interoperate seamlessly, regardless of
their server/client usage. Of course, this can already be done today, but the
Fediverse usually relies on DNS and certificates, while few server-side apps
are completely distributed. This could provide an incentive, and ultimately
make it easier to self-host (maybe even ultimately running the Wasm binaries
instead of docker containers).

~~~
joshum97
Does Lucet ([https://www.fastly.com/blog/announcing-lucet-fastly-
native-w...](https://www.fastly.com/blog/announcing-lucet-fastly-native-
webassembly-compiler-runtime)) meet those needs?

------
estrela
I have some experience with Blazor WebAssembly, and in my opinion, the
technology is promising but imature. Whenever a complex page is rendered (a
table with hundreds of entries, ...), you can definitely notice how slow and
memory consuming it is.

~~~
maxgraey
Probably Blazor is immature, but not WebAssembly? Blazor btw run in
interpreted mode for CIL modules. Full AOT compilation was planned for .NET 5
but canceled. But you could check rust's frameworks like Yew. That's real
world demo: [https://github.com/jetli/rust-yew-realworld-example-
app](https://github.com/jetli/rust-yew-realworld-example-app)

------
pmoriarty
I am interested in how WASM will affect in-browser ad blockers like uBlock
Origin that work on a finer grain than merely blocking entire domains. Will
they still be effective?

Also, how will WASM affect browser extensions that change the look and feel of
websites (like Stylish/Stylus), or the means of interacting with them (like
Vimperator)?

These questions all boil down to how much control is the end-user going to
have with WASM compared to what they had with the pre-WASM web?

~~~
7786655
It won't because WASM applications still use the DOM.

In theory it could push everything through a <canvas>, but that can be done in
JS as well and doesn't seem to be that common.

------
captn3m0
The comparision with all the "native-on-web" tech (Flash/Applets/NPAPI) is not
100% accurate. A major reason why these were used was because they let you
bypass the stupid JS sandbox - something that WASM on the browser isn't
designed to.

------
egypturnash
"It would be fair to say that these attempts failed to establish wide
adoption"

Wait what Flash spawned an _entire generation of game developers and
animators_ , it was _ubiquitous_. It had many problems and I am generally not
sad to see it gone but saying it "failed to establish wide adoption" is only a
valid thing if this person has a completely different definition of "wide
adoption" than I do.

Flash was largely constrained to games but there were definitely a lot of
people using it as the backbone, or an important part, of their interactive
web apps, too. Adobe tried to turn it into a desktop runtime but there weren't
too many people biting. I guess "actually runs tools people use on a daily
basis" is the "wide adoption" they intend?

Does "Youtube was built around a Flash video playback component" count as
"wide adoption"? Does "just about every Facebook game was built in Flash,
including the vastly profitable ones that invented and perfected the concept
of free-to-play-with-IAP" count? A hell of a lot of people exchanged a hell of
a lot of money around stuff made with Flash.

You can't compile C and other languages to it (though Adobe was working on it:
[https://web.archive.org/web/20080827114529/http://www.onflex...](https://web.archive.org/web/20080827114529/http://www.onflex.org/ted/2008/02/extending-
adobe-flash-player-and-adobe.php)) , and maybe that's the threshold they want
for "wide adoption" given that there's a whole segment later on in this blog
about how you can compile C to WASM?

(Judging by the photo at the top of this blog, it's eminently possible that
Max Desaitov is young enough that their only encounter with Flash was "those
games I was utterly obsessed with in single-digit ages and never realized were
in Flash"... god I'm old)

Perhaps WASM finally has all the right infrastructure to finally become the
One True Compiler Target, and all apps will disappear into The Cloud forever.
Perhaps. Or perhaps in about twenty-five years, Max Desaitov will be writing a
comment expressing disbelief at some doe-eyed child adding WASM to their list
of previous attempts to Change Software Distribution Forever and then going on
to rave excitedly about why the _next_ attempt to do this will _surely_ be The
One. Or perhaps Max will be too busy scrambling around in the burnt-out
remnants of a capitalist empire that finally collapsed, right now that feels
like a worrisomely possible future, who knows.

