← Back to context

Comment by thefounder

4 days ago

It’s great we are past the “wasm is not replacing JavaScript” phase. Or “you don’t need DOM for wasm . That’s what JavaScript is for”

I don't get it why you need direct DOM access. Just wrap it in JS calls. It's not like current websites are super fast and creating a wrapper will slow it down unnecessarily.

I'm pretty sure you'll will still need a JS shim to talk to most web APIs. For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header (similar to the old 'use asm' for asm.js) as shim, but the JS shim is still there. The component model can marshal 'record types' between different WASM modules, but AFAIK not between a WASM module and a web API.

  • > For instance the Mozilla DOM experiments seems to use a special JS variant with a 'use component' header

    As per the article, that's temporary until Component Model 1.0 is implemented natively in the browser. In the meantime, jco can be used:

    > The groundwork for browser implementations is being laid today: jco’s transpile command already converts any component into equivalent core Wasm and JavaScript glue, making components runnable in any browser without native support.

    That's no longer needed once native support is there.

we still need js shim for dom access :(

  • Asking for 0% js 100% wasm website is like wanting a C-free linux distro

    • One could write a js-less DOM impl I think.. neither Chrome nor Firefox itself is written in js unlike big parts of Linux that are indeed written in C. Explorer shipped with vbscript as a language that can manipulate the DOM.

      The really big issue in this case is network effect, which is why I hope something can come out from the momentum building behind WASM.

      3 replies →