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

We've revised our doc to match the syntax you suggested (thanks!).
We've also gone with separate names instantiateStreaming + compileStreaming.

It's an interesting point that CompileError doesn't tell you more about the failure. I suppose we could expose the byte offset that fails to validate, though that might open up a bunch of subtly around how precise it should be (i.e. the position of the opcode, or the immediate). Seems like something we could add if there's a use case?

The reason we want CompileError separate from other errors is to highlight that there was a particular sort of invalid input (i.e. the bytes don't validate), as opposed to say a TypeError if you pass an unexpected input.
As we expand the format, the intention was to use validation to allow feature testing (compile a small module to check if SIMD opcodes are supported, that sort of thing).

The higher level question of if compilation itself should be user visible is tricky. 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). On the other hand, that constrains implementer flexibility.

The recent experience with asm.js, which was basically a bag of implicitly specified behavior, suggests to me, however, that if developers desperately want a particular behavior, giving them a way to ask for it is better. Without that, they'll instead figure out what each browser does, user agent detect, and tailor their input to each engine, sometimes even doing that client side (making changing the implementation very hard). 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.
There may be contexts where actual compilation may not be something we can offer, but not having the strong hint seems worse.
We have had a some discussion about adding a parameter to specify a preferred compilation strategy (lazy, AOT, shareable etc.) at some point. I think that seems like a better path if someone wants to ask for non-AOT.


-- 
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-302523905