[JoshTriplett]

It should also be possible to have a <script type="application/wasm" src="something.wasm" />, and then additionally source a JavaScript polyfill that checks if wasm is supported and translates to JavaScript if not. That would remove the need to have JavaScript shims.

[buu700]

Hmm, neither one of these options (ES6 import or <script> type wasm) can quite fit in with the way we're using asm.js (including it inline with other JavaScript inside a Worker[1]).

If there were a way to flexibly invoke wasm in any scenario where asm.js currently works, I think it would be a lot friendlier and truer to the "it's just JavaScript" goal.

Furthermore, tying this to ES6 seems unnecessary to me. How does this affect those of us using Babel or TypeScript to output ES3 code? The purposes of wasm and ES6 just strike me as completely orthogonal.

---

1: There are good reasons we have to do this, but they're beyond the scope of this thread.

[JoshTriplett]

> Hmm, neither one of these options (ES6 import or <script> type wasm) can quite fit in with the way we're using asm.js (including it inline with other JavaScript inside a Worker[1]).

Could you import a module, and then call the resulting functions from within your Worker?

> If there were a way to flexibly invoke wasm in any scenario where asm.js currently works, I think it would be a lot friendlier and truer to the "it's just JavaScript" goal.

"it's just JavaScript" is a goal of asm.js; I don't see anything about WebAssembly that makes it a stated goal of wasm. "It works anywhere JavaScript works, and can call and be called by JavaScript" would be a more sensible goal.

> 1: There are good reasons we have to do this, but they're beyond the scope of this thread.

I'd be interested to hear them.

[the8472]

Not sure if the security model allows it, but maybe you could write the wasm into a blob, create an URI from the blob[1] and then use that as <script> src.

Or maybe data uris.

> How does this affect those of us using Babel or TypeScript to output ES3 code?

Well, if you're already transpiling the whole load of ES6 features then it's just one more shim to consider, no?

[1] https://developer.mozilla.org/en-US/docs/Web/API/URL/createO...

[buu700]

Any idea if wasm / ES6 modules / module loader shims work with object URLs and/or data URIs cross-browser by design?

Doing something similar for Workers, one of the problems we've had is that IE and I think Safari block that, so to make it work we have to fall back on a permanently cached shim that puts an eval statement inside self.onmessage. (Obviously no equivalent to eval exists for wasm, or I wouldn't have a problem here in the first place.)

[andhow]

I wouldn't say this is "tied" to ES6, but rather intends to integrate nicely. If a developer has no interest in being called by or calling JS, they should be able to ignore the ES6 module aspect. For workers, it should (eventually, probably not in the MVP v.1) be possible to pass a URL (which, with Blob + Object URL needn't be a remote fetch and can be explicitly cached (Cache API or IndexedDB) or dynamically generated (Blob constructor)) to a worker constructor.

[buu700]

>Could you import a module, and then call the resulting functions from within your Worker? ... I'd be interested to hear them.

I have more detail here[1], but what it comes down to is that our application's security model is dependent on the ability to pack all of its code into one file.

I'm admittedly not too familiar with the ES6 module system (we're using TypeScript modules), but it looks like importing necessarily requires pulling in an external file. Workers are problematic in a similar way, but simple enough to work around using a few different methods (that I can't think of how to apply to ES6 modules).

> For workers, it should ... to a worker constructor.

In our case, the asm.js modules aren't being used as standalone workers, but rather pulled in to a worker that does a bunch of other stuff, so that probably couldn't be applied here exactly.

If that blob URL setup worked with ES6 import, though, that could work. (It might make things messier for generated TypeScript code though, not sure.)

> I wouldn't say this is "tied" to ES6, but rather intends to integrate nicely.

When I say tied, I mean in the sense that ES6 looks to be the only method of arbitrarily executing wasm code.

To use wasm, I'd need the ability to drop it in the middle of a block of JS.

---

1: https://docs.google.com/document/d/1j5KnpVyDdIXVwEDCQpHGxbs0...

[pekk]

Almost nobody is using asm.js right now, and backward compatibility with asm.js should not be a top consideration for WebAssembly which (with agreement from multiple vendors) will achieve something much more important than asm.js backward compatibility.

[buu700]

My point is less about anything related to asm.js per se, and more that there isn't a good reason for wasm not to support this particular use case.