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

91–100 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#91

Post by criticalfault »

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…

But why would it need to interact with Js or having the same API?

Maybe I misunderstood, but isn't Dom access in essence an ability to change html tree? Since this is wasm, why would it need to reimplement js API and need type mappings? Couldn't it be something different?

Re: When Is WebAssembly Going to Get DOM Support?

#92

Post by MisterTea »

jffry wrote: post #82
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.

Thanks for the clarification. So if I understand correctly - when using WASM you interface to web things through JS forcing the user to always need JS in the stack when e.g. they may want to just use Rust or Go. My first thought would be modules that are akin to a syscall interface to a DOM "device" exposed by the VM.

Re: When Is WebAssembly Going to Get DOM Support?

#93

Post by weinzierl »

CrimsonRain wrote: post #61
breve wrote: post #18

Earlier quoted context omitted.

It is happening. Leptos is an example: https://www.leptos.dev/ Dioxus is another: https://dioxuslabs.com/ C# with Avalonia for a different use case: https://avaloniaui.net/ Avalonia solitaire demo: https://solitaire.xaml.live/ Avalonia Visual Basic 6 clone: https://bandysc.github.io/AvaloniaVisualBasic6/ Blazor can run as WebAssembly on the client side if you choose that runtime mode: https://dotnet.microsoft.com/en-…

how'd you compare dioxus and leptos?

Not parent but GP: Love Leptos, I think they are on the right track. Dioxus is good too, I think it has wider scope and they also obtained funding from external sources while Leptos is completely volunteer based.

Re: When Is WebAssembly Going to Get DOM Support?

#94

Post by pjmlp »

mananaysiempre wrote: post #87
pjmlp wrote: post #29

Earlier quoted context omitted.

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.

On the contrary,

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

And looking at other bytecode based systems, enough runtimes with multiple vendors.

https://en.wikipedia.org/wiki/Bytecode

Re: When Is WebAssembly Going to Get DOM Support?

#95

Post by nothrabannosir »

chrismorgan wrote: post #11
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…

> Why create a generic bytecode execution platform and limit the use case so much? How would you make such a thing without limiting it in some such way?

By giving it dom support

Re: When Is WebAssembly Going to Get DOM Support?

#96

Post by detaro »

croes wrote: post #73
detaro wrote: post #55

Earlier quoted context omitted.

I don't think "exactly the same thing" is accurate. And WASM has put more effort into sandboxing, both in the design (very limited interfaces outside the sandbox) and implementations (partially because we've just gotten a lot better at that as an industry).

But now you can do more in the browser than back then with Java applets. Crypto miners weren’t a thing for Java applets

Only because Java Applets died before crypto mining became a thing/got turned into a "click to enable" thing because security problems.

Re: When Is WebAssembly Going to Get DOM Support?

#97

Post by AndrewDucker »

tlb wrote: post #60
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.

I use it for a web version of some robotics simulation & visualization software I wrote in C++. It normally runs on as an app on Mac or Linux, but compiling to WASM lets me show public interactive demos. Before WASM, the options were: - require everyone to install an app to see visualizations - just show canned videos of visualizations - write and maintain a parallel Javascript version Demo at https://throbol.com/she…

Works fine in Chrome for me.

Re: When Is WebAssembly Going to Get DOM Support?

#98

Post by Fluorescence »

criticalfault wrote: post #91
Fluorescence wrote: post #77

Earlier quoted context omitted.

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…

But why would it need to interact with Js or having the same API? Maybe I misunderstood, but isn't Dom access in essence an ability to change html tree? Since this is wasm, why would it need to reimplement js API and need type mappings? Couldn't it be something different?

(still not a browser engineer - others will know better).

It doesn't need to be the same API... but implementing a new DOM API that doesn't meet the w3c standard is a bit on the nose. It's meant to be language independent hence the IDL.

Looking into it, the IDL might insulate the existing API implementation from JS to a greater degree than I assumed above. Apparently there might be horrors lurking in the binding generation code though. You can poke around in blink:

https://github.com/chromium/chromium/blob/main/third_party/b...

> isn't Dom access in essence an ability to change html tree

It might be more accurate to look at it the other way: our current DOM implementations were created to implement the "DOM API Standard". The standard dictated the types and how reading/mutation works.

> need type mappings

I can't imagine how it can avoid type mappings for things like e.g. creating unattached bits of DOM or binding callbacks that receive bits of DOM.

Personally I might be happy for a tiny WASM api... but then foresee 10 years of maddening omissions, security bugs and endless moaning because they didn't just implement the standard everyone already knew.

Re: When Is WebAssembly Going to Get DOM Support?

#99

Post by Aardwolf »

adastra22 wrote: post #86
Aardwolf wrote: post #69

Earlier quoted context omitted.

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).

Well actually that was because the topic of the article was webassembly :) I have seen Java used for backends / software as well (and other than the lack of unsigned integers for e.g. crypto/hashing/compression/..., and lack operator overloading for e.g. vectors/matrices/bigints/..., it's 'fine' to me)

Re: When Is WebAssembly Going to Get DOM Support?

#100

Post by passivegains »

xeonmc wrote: post #70
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.

What would you propose if you were to rename it? Generalized Assembly? GASM?

I'd probably go with something like Open Regular Generalized ASseMembly.
Post reply on HN