5 ms·

Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer?

Do you know anything about any WASM developments that will enable pure WASM interaction with the browser's Web-APIs at no or at a low cost without the JS layer? Sometimes I look at https://github.com/WebAssembly/proposals https://github.com/WebAssembly/proposals and it's very confusing. There are the type imports proposal(years away), the almost complete GC proposal(which is apparently only for GCd languages, but not for anything browser<->wasm), the component model(which looks and sounds as something not for the browser use case), JS String Builtins (which will provide faster JS strings, but not DOM) and ECMAScript module integration (which will turn WASM modules into ES modules, but Web-APIs aren't ES modules so no luck). Sometimes I read contributor interactions and it looks as if providing such functionality isn't their priority or even in their plans, and for the majority the WASI + component model for the cloud, crypto and similar use cases are more important.

TrevorSundberg 3y ago
I really yearn for this myself. I would love to see a “pure wasm” browser where the pages are just wasm and the “browser” just provides a bunch of platform imports like WASI. I agree with you though, seems like it’s not a priority for them. One of these days…
CryZe 3y ago
Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls. The only real need for JS would be to initialize the wasm module in the first place.
- nullifidian 3y ago
  >you don't really need any (almost any?) intermediate JS anymore I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.
csjh 3y ago
I believe that's at least part of what the GC proposal is moving towards.
a1o 3y ago
The problem of pure wasm is we get a closed source web with unblockable ads.
- nullifidian 3y ago
  that ship has sailed. Minified and optionally obfuscated js is already highly annoying to decipher. The wasm spec is surprisingly high level for what should be a low level VM, and is planned to get much more high level approaching near jvm levels, and isn't any less readable than C++ compiled to asm.js.
  - wewxjfq 3y ago
    Still infinitely better than WASM blobs where everything is painted on a canvas, which is un-adblockable. The experience will also be hellish, because every website will ship a 10 MB blob of half-baked things that your browser already does a million-times better out of the box. And for what? Because people think it will be faster (it won't).
    - taway1237 3y ago
      I was sceptical WASM is ever going to be mainstream, but after reading your post I'm convinced it's the future. This sound like advertiser dream, and adds already rule the internet, so the conclusion is obvious
    - nullifidian 3y ago
      The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-language codebases. If the canvas website really was a threat we would have seen much more of it by now already, but it hasn't happened for a number of reasons -- we only see them in the dedicated desktop-app-like use cases like this one. Anything scrollable won't be viable because it would be inherently less responsive than the real deal. Fonts look different, most designers actually prefer for people to be able to select text, and be able to use browser functionality that looks native for the different OSs. Canvas websites are also more expensive in terms of blob loading and ability to cache pages. So it's not really a threat. Most adblocking happens by the means of network/URL blocking and I don't see any potential difference between WASM and JS in this regard(unless the APIs are enshittified, but JS isn't impervious to this too). If ads can't be blocked by network, and the website proxies ad contents through its own domain(as far as I know that's not prevalent, maybe I'm ignorant -- they need to track users and clicks themselves anyway), than you could get hard to block websites with JS+DOM too -- it's possible disrupt DOM based blocking by frequent randomization/obfuscation to the degree that one would need some kind of advanced AI to even hope to find the ad DOM elements. Between WEI, web bundles, Topics API push, webassembly's supposed higher indecipherability (which isn't true, chrome "disassembles" WASM into the WAT form and it's pretty readable. More readable than wasm.js) doesn't even register. >And for what? To not deal with JavaScript? To be able to develop for the web in the language you want, without floats being the fundamental numeric type and other BS? Is that too fantastical of a desire?

TrevorSundberg 3y ago

I really yearn for this myself. I would love to see a “pure wasm” browser where the pages are just wasm and the “browser” just provides a bunch of platform imports like WASI. I agree with you though, seems like it’s not a priority for them. One of these days…

CryZe 3y ago

Reference types technically already allow for calling directly into the browser APIs as reference types allow wasm to pass JavaScript objects around. So if you import all the relevant web apis, you don't really need any (almost any?) intermediate JS anymore, because you can just forward the JS objects between the individual API calls. The only real need for JS would be to initialize the wasm module in the first place.

nullifidian 3y ago
>you don't really need any (almost any?) intermediate JS anymore I don't think that's true. You still need JS glue code that would return these externrefs. A WebAssembly module loaded through ESM integration can't as far as the current proposals access Web-APIs on its own. As far as I understand there is also a number performance issues related to the wasm spec itself that limit possible optimizations, making wasm second class to JS in terms of performance of WebAPI access.

csjh 3y ago

I believe that's at least part of what the GC proposal is moving towards.

a1o 3y ago

The problem of pure wasm is we get a closed source web with unblockable ads.

nullifidian 3y ago
that ship has sailed. Minified and optionally obfuscated js is already highly annoying to decipher. The wasm spec is surprisingly high level for what should be a low level VM, and is planned to get much more high level approaching near jvm levels, and isn't any less readable than C++ compiled to asm.js.
- wewxjfq 3y ago
  Still infinitely better than WASM blobs where everything is painted on a canvas, which is un-adblockable. The experience will also be hellish, because every website will ship a 10 MB blob of half-baked things that your browser already does a million-times better out of the box. And for what? Because people think it will be faster (it won't).
  - taway1237 3y ago
    I was sceptical WASM is ever going to be mainstream, but after reading your post I'm convinced it's the future. This sound like advertiser dream, and adds already rule the internet, so the conclusion is obvious
  - nullifidian 3y ago
    The experience will probably be hellish anyway because of the Web integrity API. Javascript compiled to asm.js could produce painted-to-canvas websites too, and it won't be any less viable especially considering the growth of the CPU scores. Webassembly is prevalent in the canvas use cases because DOM manipulation with it is slower, clunky(due to the poor browser integration) and because people want to reuse native-language codebases. If the canvas website really was a threat we would have seen much more of it by now already, but it hasn't happened for a number of reasons -- we only see them in the dedicated desktop-app-like use cases like this one. Anything scrollable won't be viable because it would be inherently less responsive than the real deal. Fonts look different, most designers actually prefer for people to be able to select text, and be able to use browser functionality that looks native for the different OSs. Canvas websites are also more expensive in terms of blob loading and ability to cache pages. So it's not really a threat. Most adblocking happens by the means of network/URL blocking and I don't see any potential difference between WASM and JS in this regard(unless the APIs are enshittified, but JS isn't impervious to this too). If ads can't be blocked by network, and the website proxies ad contents through its own domain(as far as I know that's not prevalent, maybe I'm ignorant -- they need to track users and clicks themselves anyway), than you could get hard to block websites with JS+DOM too -- it's possible disrupt DOM based blocking by frequent randomization/obfuscation to the degree that one would need some kind of advanced AI to even hope to find the ad DOM elements. Between WEI, web bundles, Topics API push, webassembly's supposed higher indecipherability (which isn't true, chrome "disassembles" WASM into the WAT form and it's pretty readable. More readable than wasm.js) doesn't even register. >And for what? To not deal with JavaScript? To be able to develop for the web in the language you want, without floats being the fundamental numeric type and other BS? Is that too fantastical of a desire?