Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

When Is WebAssembly Going to Get DOM Support?

queue.acm.org

Post reply on HN
Print view View original

191–200 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#191

Post by bdhcuidbebe »

renox wrote: post #185
adastra22 wrote: post #174

Earlier quoted context omitted.

All of that exists at a way higher level. It's like saying ELF binaries don't provide good i18n or a11y. I don't even know how to interpret that.

Sure, but as a 'dream' portable executable is kind of funny when execution by itself brings you nothing (except heating the CPU), you also need portable IO, security, i18n, a11y..

Your argument goes like Sagan’s

if you want to make an omelet, you also need to create the universe.

Your points being unrelated to wasm.

Re: When Is WebAssembly Going to Get DOM Support?

#192

Post by tpm »

3cats-in-a-coat wrote: post #188
tpm wrote: post #71

Earlier quoted context omitted.

With access to DOM it could run with no (or just very little) js, no ts-to-js transpiler, no web-framework-of-the-month wobbly frontends perpetually reinventing the wheel. One could use a sane language for the frontend. That would be quite the revolution.

You already can do that. You need a tiny shim and you can forget it's JS and use all WASM.

Can you point me to a howto/tutorial?

Re: When Is WebAssembly Going to Get DOM Support?

#193

Post by immibis »

bdhcuidbebe wrote: post #189
immibis wrote: post #161

Earlier quoted context omitted.

That wouldn't be cross-platform. Browsers couldn't even ship SQL because it would inevitably tie them to sqlite, specifically, forever. They definitely can't ship something that requires a whole Linux kernel.

> Browsers couldn't even ship SQL because it would inevitably tie them to sqlite, specifically, forever. Nonsense. Chrome store their sqlite db in C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\databases And Firefox: > Why Firefox Uses SQLite > Cross-Platform Compatibility: Works seamlessly across all platforms Firefox supports. https://www.w3resource.com/sqlite/snippets/firefox-sqlite-gu...

These are not used to expose SQL to web pages though, they're used only internally by the browser.

Re: When Is WebAssembly Going to Get DOM Support?

#194

Post by ifwinterco »

sfvisser wrote: post #3

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer…

The entire DOM API is very coupled to JS, it's all designed with JS in mind, any new and future proposed changes are thought about solely through the lens of JS.

If they introduced a WASM API it would perpetually be a few months/years behind the JS one, any new features would have to be implemented in both etc.

I can see why it's not happened

(edit) And yes, I think the intention of WASM was either heavy processing, or UI elements more along the lines of what used to be done with Java applets etc. potentially using canvas and bypassing the DOM entirely, not as an alternative to JS for doing `document.createElement`

Re: When Is WebAssembly Going to Get DOM Support?

#195

Post by zeratax »

flohofwoe wrote: post #23
theSherwood wrote: post #20

I want DOM access from WASM, but I don't want WASM to have to rely on UTF-16 to do it (DOMString is a 16-bit encoding). We already have the js-string-builtins proposal which ties WASM a little closer to 16-bit string encodings and I'd rather not see any more moves in that direction. So I'd prefer to see an additional DOM interface of DOMString8 (8-bit encoding) before providing WASM access to DOM apis. But I suspect…

Tbh I would be surprised if converting between UTF-8 and JS strings is the performance bottleneck when calling into JS code snippets which manipulate the DOM. In any case, I would probably define a system which doesn't simply map the DOM API (objects and properties) into a granular set of functions on the WASM side (e.g. granular setters and getters for each DOM object property). Instead I'd move one level up and bui…

idk looking at what the creator of leptos talks about it seems to be very significant: https://youtu.be/4KtotxNAwME?si=e_xwqo5gopKDlOtK

Re: When Is WebAssembly Going to Get DOM Support?

#196

Post by vsmenon »

You can effectively try this today in Dart. When running in the browser, Dart can compile to either JavaScript or Wasm and both backends support DOM access via https://pub.dev/packages/web.

The DOM access in Wasm does trampoline through JavaScript under the hood, which introduces some overhead. Dart uses WasmGC, though, which is supported on Chrome/FF/Safari and lowers that overhead by enabling objects to be shared across the Wasm / JS boundary. In the benchmarks we've tried, the overhead is not that noticeable. But direct access (from Wasm) would be faster.

Jaspr (https://jaspr.site) is a react-style framework that sits on top of this. You can see example usage here: https://github.com/vsmenon/todomvc/

This app is too small to show benefits, but the code size is about the same across the two and similar to those at todomvc.com. We are seeing potential benefits on page load time (Wasm is faster to parse/initialize) and compute (Wasm is faster on many workloads).

Re: When Is WebAssembly Going to Get DOM Support?

#197

Post by vsmenon »

vsmenon wrote: post #196

You can effectively try this today in Dart. When running in the browser, Dart can compile to either JavaScript or Wasm and both backends support DOM access via https://pub.dev/packages/web . The DOM access in Wasm does trampoline through JavaScript under the hood, which introduces some overhead. Dart uses WasmGC, though, which is supported on Chrome/FF/Safari and lowers that overhead by enabling objects to be shared…

There is a recent YT video on Dart & Wasm: https://www.youtube.com/watch?v=vgOABOvtBT8

Re: When Is WebAssembly Going to Get DOM Support?

#198

Post by tlb »

tpm wrote: post #71
3cats-in-a-coat wrote: post #50

Earlier quoted context omitted.

Give me one thing that your theoretical WASM can "revolutionize". Aside from more efficient covert crypto mining on shady sites.

With access to DOM it could run with no (or just very little) js, no ts-to-js transpiler, no web-framework-of-the-month wobbly frontends perpetually reinventing the wheel. One could use a sane language for the frontend. That would be quite the revolution.

You can just interpolate bits of Javascript inside C++ to access the DOM, like so:

  #include 

  void sayHello()
  {
    EM_ASM(
      let foo = document.getElementById('foo')
      foo.innerHTML = 'hello';
    );
  }
See https://emscripten.org/docs/porting/connecting_cpp_and_javas...

Re: When Is WebAssembly Going to Get DOM Support?

#199

Post by sfvisser »

Muromec wrote: post #122
sfvisser wrote: post #3

We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls. But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer…

>The whole WASM story is confusing to me. Think of it as a backend and not as library and it clicks.

Yes, but that’s exactly what I’m trying to avoid.

Re: When Is WebAssembly Going to Get DOM Support?

#200

Post by bdhcuidbebe »

immibis wrote: post #193
bdhcuidbebe wrote: post #189

Earlier quoted context omitted.

> Browsers couldn't even ship SQL because it would inevitably tie them to sqlite, specifically, forever. Nonsense. Chrome store their sqlite db in C:\Users\%USERNAME%\AppData\Local\Google\Chrome\User Data\Default\databases And Firefox: > Why Firefox Uses SQLite > Cross-Platform Compatibility: Works seamlessly across all platforms Firefox supports. https://www.w3resource.com/sqlite/snippets/firefox-sqlite-gu...

These are not used to expose SQL to web pages though, they're used only internally by the browser.

You said browsers didnt ship sqlite due to lack of cross-platform.

I disproved that.

Dont change the goalpost.

Post reply on HN