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

81–90 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#81

Post by flohofwoe »

wongarsu wrote: post #40
flohofwoe wrote: post #39

Earlier quoted context omitted.

> at least for the 90% of DOM APIs not using JavaScript-specific features The DOM is a Javascript API, so it uses 100% Javascript-specific features (every DOM manipulation requires accessing JS objects and their properties and lots of those properties and function args are Javascript strings) - none of those map trivially to WASM concepts. It's a bit like like asking why x86 assembly code doesn't allow "C++ stdlib ac…

I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtu…

Sure an automatically generated JS shim which marshalls between a web API and the WASM module interface is possible, but that's still not direct DOM access, it still goes through a JS shim. The detail that this JS shim was automatically generated from an IDL instead of manually written is really not that important when the question is "does WASM allow direct DOM access", the simple answer is "no".

The underlying problem is that you need to translate between a Javascript-idiomatic API and whatever is an idiomatic API in the language you compile into WASM, and idiomatic C, C++, Rust, ... APIs all look very different so there isn't a single answer. It's not WASM being relevant here, but the high level source language that's compiled into WASM, and how well the DOM JS API (and the Javascript concept it is built on) map to APIs for various 'authoring languages'.

The whole problem is really quite similar to connecting two higher level languages (e.g. Rust and C++) through a C API (since this is the common interface that both Rust and C++ can talk to - but that doesn't mean that you can simply send a Rust String to the C++ side and expect that you automatically get a std::string - this sort of magic needs to be explicitly implemented in a shim layer sitting between the two worlds) - and to use the string example, there is no such thing as a WASM string, instead how string data is represented on the WASM side depends on the source language that's compiled to WASM.

Re: When Is WebAssembly Going to Get DOM Support?

#82

Post by jffry »

MisterTea wrote: post #80

I am confused by this. If WASM is a VM then why would it understand the DOM? To me it akin to asking "When will Arm get DOM support?" Seems like the answer is "When someone writes the code that runs on WASM that interacts with the DOM." Am I missing something? (not a web dev.)

The WASM VM doesn't have any (direct) access to the DOM, so there's no code you can write in it that would affect the DOM.

There's a way to make JS functions callable by WASM, and that's how people build a bridge from WASM to the DOM, but it involves extra overhead versus some theoretical direct access.

Re: When Is WebAssembly Going to Get DOM Support?

#84

Post by adastra22 »

renox wrote: post #65
adastra22 wrote: post #43

Earlier quoted context omitted.

It should never have been web assembly. WASM is the fulfillment of the dream that started with Java VM in the 90’s but never got realized. A performant, truly universal virtual machine for write-once, run anywhere deployment. The web part is a distraction IMHO.

"Dream", well until you think about i18n and a11y..

What do you mean?

Re: When Is WebAssembly Going to Get DOM Support?

#85

Post by flohofwoe »

zihotki wrote: post #47
weinzierl wrote: post #5

Earlier quoted context omitted.

"Definitely some feeling of being rug-pulled in the shift here." Definitely feeling rug-pulled. What I think all the people that hark on the "Don't worry, going through JS is good enough for you." are missing is the subtext of their message. They might objectively be right, but in the end what they are saying is that they are content with WASM being a second class citizen in the web world. This might be fine for ever…

One could say second class, another could say that's a good separation of concerns. Having direct access would lead to additional security issues and considerations. I wish it was possible to disable WASM in browsers.

> I wish it was possible to disable WASM in browsers.

In Firefox at least: navigate to about:config and then `javascript.options.wasm => false` seems to do the job.

This causes any access to the global WebAssembly object to fail with `WebAssembly is not defined` (e.g. it won't be possible to instantiate wasm blobs).

Re: When Is WebAssembly Going to Get DOM Support?

#86

Post by adastra22 »

Aardwolf wrote: post #69
secondcoming wrote: post #46

Earlier quoted context omitted.

Why did Java fail though, and why would wasm succeed when the underlying philosophy is the same?

I'm not sure how it's for others, but for me there was a perception issue with java applets on the web in the mid 2000s: Java applets loading on a website started as a gray rectangle, which loaded very slowly, and sometimes failed to initialize with an "uninited" error. Whenever you opened a website with a java applet (like could happen with some math or physics related ones), you'd go "sigh" as your browser's UI thr…

The fact that we said “Java” and you went to thinking about “Java applets” is part of the problem. Java was meant to be a universal executable format. It ended up confined to the web (mostly, at least in the popular consciousness).

Re: When Is WebAssembly Going to Get DOM Support?

#87

Post by mananaysiempre »

pjmlp wrote: post #29
BlackFly wrote: post #4

Earlier quoted context omitted.

My reading of it is that the people furthering WASM aren't really associated with just browsers anymore and they are building a whole new VM ecosystem that the browser people aren't interested in. This is just my take since I am not internal to those organizations. But you have the whole web assembly component model and browsers just do not seem interested in picking that up at all. So on the one side you have organi…

Meanwhile the people using already established VM ecosystems, don't a value dropping several decades of IDEs, libraries and tools, for yet another VM redoing more or less the same, e.g. application servers in Kubernetes with WASM containers.

Already-established single-vendor VM ecosystems.

Re: When Is WebAssembly Going to Get DOM Support?

#88

Post by wongarsu »

Fluorescence wrote: post #77
wongarsu wrote: post #40

Earlier quoted context omitted.

I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtu…

IANABE (not a browser engineer) On the one hand, JS DOM objects are idl generated wrappers for C++. In theory we can generate more WASM friendly wrappers. On the other, the C++ code implementing the API will be tightly coupled to the entire JS type system and runtime. Not just the concept of an object but every single design decision from primitives to generators to dynamic types to prototypical inheritance to error…

Those are great points. That's the angle I was missing from the article

Re: When Is WebAssembly Going to Get DOM Support?

#89

Post by wongarsu »

flohofwoe wrote: post #81
wongarsu wrote: post #40

Earlier quoted context omitted.

I wouldn't call having objects and properties Javascript-specific. The article details how they were initially written with support by both Java and JavaScript in mind. Now WASM isn't object oriented like Java or JavaScript, but the concept of objects maps very cleanly to the concept of structs, member functions to simple functions that get the struct as first parameter (optionally with an indirection through a virtu…

Sure an automatically generated JS shim which marshalls between a web API and the WASM module interface is possible, but that's still not direct DOM access, it still goes through a JS shim. The detail that this JS shim was automatically generated from an IDL instead of manually written is really not that important when the question is "does WASM allow direct DOM access", the simple answer is "no". The underlying prob…

If you push the shim to JavaScript then it isn't direct DOM access. But you could push the shim into the C++ browser code, providing one DOM API to JavaScript and slightly smaller shimmed version to WASM. Then you cut out the JavaScript middle-man and can call it "direct DOM access".

Of course you couldn't provide idiomatic versions for every language, but the JS shims also can't really do that. Providing something close to idiomatic C would be a huge step up, the language libraries can then either offer a C-like API or choose to build new abstractions on top of it

Re: When Is WebAssembly Going to Get DOM Support?

#90

Post by flohofwoe »

wongarsu wrote: post #89
flohofwoe wrote: post #81

Earlier quoted context omitted.

Sure an automatically generated JS shim which marshalls between a web API and the WASM module interface is possible, but that's still not direct DOM access, it still goes through a JS shim. The detail that this JS shim was automatically generated from an IDL instead of manually written is really not that important when the question is "does WASM allow direct DOM access", the simple answer is "no". The underlying prob…

If you push the shim to JavaScript then it isn't direct DOM access. But you could push the shim into the C++ browser code, providing one DOM API to JavaScript and slightly smaller shimmed version to WASM. Then you cut out the JavaScript middle-man and can call it "direct DOM access". Of course you couldn't provide idiomatic versions for every language, but the JS shims also can't really do that. Providing something c…

> But you could push the shim into the C++ browser code

That's easier said than done because of details like that you can't build a JS string on the C++ side, the translation from string data on the WASM heap into a JS object needs to happen on the JS side.

But this is how all the Emscripten web API shims work, and they do this quite efficiently, and some of those shims also split their work between the JS and C/C++ side.

So to the programmer it does look like with Emscripten there's direct access to the (for instance) WebGL or WebGPU APIs, but in reality there's still quite a bit of JS code involved for each call (which isn't a problem really as long as no expensive marshalling needs to happen in such a call, since the call overhead from WASM into JS alone is really minimal).

Post reply on HN