To WASM or not to WASM (Re: Raw data API - 6 - Encoders/decoders)

On 06/14/2018 10:55 AM, Lorenzo Miniero wrote:
> -1 on an RTP stack in JS :-P
>
> I'm strongly against all this wasm nonsense. Just because machines are
> getting more powerful, doesn't mean we should drop more efficient code
> for something that runs worse just because it's easier to move around.
> It's a trend that is happening everywhere, and I hate it, because it
> shows no regard for those who still ship machines that would atthe very
> least struggle with that. Besides, this seems to bring us back to the
> "WebRTC just for browsers" era: WebRTC is everywhere, now, and I can
> already picture my mobile phone melting down any time I open a web page
> with WebRTC on it.
Changing the subject again, since this is a different thread.

Components in WASM are a very different beast, operations-wise than
browser-built-in components.

Browser-built-in components are under the control of the browser vendor,
and updated on the browser release cycle - in Chrome, that currently
means roughly 12 weeks from code to full deployment, and iterations no
faster than on a 6-week cycle. Other browsers have different cycles.
Each iteration affects billions of people (NOT an exaggeration), and has
some degree of gurantees of interoperability with multiple applications.

Components in WASM are under the control of the Web page provider. Their
release cycle is totally under Web page control, changing them affects
only the users of that particular application (and the users the
application communicates with), and interoperability is only a concern
for the particular set of endpoints that this application communicates with.

What this means is that when we offer APIs that allow the application to
replace a particular built-in component with a WASM alternative, the
point isn't to reimplement what the built-in component does - it's to
allow the application to do something *different*, under *their*
control, not the browser's.

WASM has some advantages over Javascript (simpler programming model,
ability to use more traditional programming languages, implicit
obfuscation of source because languages are compiled) and some
disadvantages (no direct access to JS APIs). But the deployment paradigm
of WASM modules is much closer to that of Web pages and JS libraries
than it is to browser functions.

Harald





-- 
Surveillance is pervasive. Go Dark.

Received on Friday, 15 June 2018 06:56:10 UTC