Re: [w3ctag/design-reviews] WebAssembly Response API / Web Embedding (#167)

> We've offered explicit compilation because this is a domain where performance characteristics can't be abstracted away (or else we'd just be targeting JS).

The proposed design also limits what is possible in terms of performance, limits the capability to schedule the download and compilation, limits the capability to cache the data along the pipeline.

If a web browser wants to cache the compiled code resulting from a streaming compilation it helps a lot if it can describe the inputs without comparing their entire content, for example a URL and version.

If the input to the streaming compilation comes from JS code then these inputs could come from anywhere so the products could not be cached using named resources, this badly limits caching.

Further if the input comes from JS code then the web browser is not in control of when that code generation (or translation etc) is run and scheduled. It can not re-run it as it needs to, for example if it has decided to flush some data from a cache and needs to re-generate it.

> Much of the asm.js in the wild does textual search and replace + eval to "strip out" float32 use because this wasn't fast in chrome at some point.

So a transform stage is expected to be required. The proposed design does not support this use case well, it does not allow the caching of the output based on the versions of inputs, and it does not allow the web browser to schedule the translation and compilation based on what it knows (information that may not be practical to expose for security and privacy matters).

Lets say wasm is shown to be rather flawed after more research and experience. We don't want the web to be stuck here. If there is a translation stage that works well then there is a path to change.

With a good design, a cloud proxy might even pre-evaluate and cache the compilation pipeline. This could potential go a far as delivering code in a proprietary encoding for a particular client side web browser component. There are precedents for this type of optimization already.

An interface to allow a procedural JS context to control the compilation can not solve the use cases as it just can not be given the information and control needed to work well for security and privacy reasons - it should be possible to draw that conclusion now. A build manifest resource is needed.

Lets put some thought into the architecture now to set the stage for future work.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/167#issuecomment-302559901

Received on Thursday, 18 May 2017 22:34:23 UTC