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

201–210 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#201

Post by 3cats-in-a-coat »

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

Earlier quoted context omitted.

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?

This is wasm-dom for Rust: https://crates.io/crates/wasm-dom There's also web-sys. Those are Rust centric, I'm sure there are others, but basically you only need the whim once, and then you write in your language of choice and compile to WASM, you never have to think about JS. Although... I may question the purist attitude. But you can do it.

Think of it like HTMX, the way people say it "avoids working with JS" (HTMX itself is written in JS). Same principle.

Re: When Is WebAssembly Going to Get DOM Support?

#202

Post by int_19h »

secondcoming wrote: post #46
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.

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

Because the underlying philosophy was not the same.

Java bytecode was never originally intended as a generic low-level assembly language. Its semantics are defined largely by the needs of Java the language, which means that, on one hand, it doesn't even have pointers (only object references; so you can't e.g. point into the middle of an array), and, on the other hand, it has opcodes like "call method" that map nicely to what Java does but not necessarily to what other languages do.

wasm, on the other hand, is sufficiently low-level that you can compile C into it.

Re: When Is WebAssembly Going to Get DOM Support?

#203

Post by int_19h »

flohofwoe wrote: post #26
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…

> that they are content with WASM being a second class citizen in the web world Tbh, most of the ideas so far to enable more direct access of Javascript APIs from WASM have a good chance of ruining WASM with pointless complexity. Keeping those two worlds separate, but making sure that 'raw' calls between WASM and JS are as fast as they can be (which they are) is really the best longterm solution. I think what people…

> There will always be some sort of JS glue code, it might be generated and you don't need to directly deal with it, but it will still be there, and that's simply because web APIs are first and foremost designed for usage from Javascript.

Historically, at least, web APIs were designed for usage from all kinds of languages, which is precisely why e.g. the DOM API is defined using IDL. There's no reason why we can't get back to that situation. WinRT shows how you can have a high-level object-oriented API that can be projected into different languages in ways that reflect idiomatic use in those languages (e.g. projecting promises differently to allow for async/await to work everywhere).

Re: When Is WebAssembly Going to Get DOM Support?

#204

Post by int_19h »

flohofwoe wrote: post #183
Spivak wrote: post #182

Earlier quoted context omitted.

Wouldn't the path forward be that the browser acts more like a kernel with a syscall interface which both V8 and WASM use? You wouldn't access "Web APIs" from WASM because those would be written in JS but you get access to the same primitives used to implement the JS API. Sure, probably equally a pipedream but if there was any serious effort to make WASM a first class citizen in the browser it would probably be somet…

Yeah something like that would be nice, it would probably increase the attack surface though (since each internal web api implementation now has two surfaces, one that's exposed to JS and one lower level C-like API that directly connects to the WASM import table).

The security boundary in this scenario would be the "syscall" layer. If it's secure by itself, then any higher-level wrapper on top of it is also secure.

Re: When Is WebAssembly Going to Get DOM Support?

#205

Post by int_19h »

austin-cheney wrote: post #44

This is one of those self-taught versus college educated subjects. See this for some background https://news.ycombinator.com/item?id=44599228 This subject is interesting because your typical college educated developer HATES the DOM with extreme passion, because it’s entirely outside their area of comfort. The typical college educated developer is typically educated to program in something like Java, C#, or C++ and is…

> Java, C#, or C++ and is how the world is supposed to work. The DOM doesn’t work like that. It’s a graph of nodes in the form of a tree model

This makes no sense. A graph of nodes is a very common data structure in all these languages. Not only that, but DOM was originally designed with those languages in mind (hence why it's defined via IDL). Indeed, Java actually used to have the complete DOM API in its standard library: https://docs.oracle.com/en/java/javase/17/docs/api/java.xml/...

Re: When Is WebAssembly Going to Get DOM Support?

#206

Post by immibis »

bdhcuidbebe wrote: post #200
immibis wrote: post #193

Earlier quoted context omitted.

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.

But you are changing the goalposts. Browser's couldn't ship SQL (the JavaScript feature called WebSQL) because it would tie the web ecosystem to the future of sqlite, which is a specific cathedral-type project.

Re: When Is WebAssembly Going to Get DOM Support?

#207

Post by apatheticonion »

3cats-in-a-coat wrote: post #187
apatheticonion wrote: post #68

Earlier quoted context omitted.

High performance web-based applications is pretty high on my list. Low memory usage and low CPU demand may not be a requirement for all websites because most are simple, but there are plenty of cases where JavaScript/TypeScript is objectively the wrong language to be using. Banking apps, social network sites, chat apps, spreadsheets, word processors, image processors, jira, youtube, etc Something as simple as multith…

But... we already have all that. Multithreading could've been a bit more convenient, but if you want it, you can get it. Don't tell me those revolutionaries that want to revolutionize the web give up so easily.

I use multi-threading extensively in JavaScript (it's part of my day job). I can tell you that you have to _really really_ want it and it is very hard to use it to improve performance.

Serialization/deserialization overhead is non-trivial while shared primitives like SharedArrayBuffer are mostly useless and disabled without prohibitivly restrictive security headers.

To get anything useful out of JavaScript threading, you need to implement hydration and synchronization mechanisms which are slow and unbelievably complex.

Meanwhile, multithreading is effortless and performant in Rust or Go.

If my backend is in Rust already, I could simply reuse my API types/structs.

I could use language specific serialization formats for REST endpoints (like Rust's bincode) rather than JSON or protobuf - which is faster to parse and compresses better.

If the web opens up more maybe we could gain access to raw TCP/UDP sockets and have access to highly efficient streaming from our servers - enabling use cases like usable game netcode (which is currently impossible). This benefits other realtime application use-cases too, like finance applications, chat applications and streaming services.

Don't forget the memory footprint of web applications. Imagine if the browser figured out there was no JavaScript running and it didn't spawn a JS runtime - imagine a tab consuming 15mb of RAM rather than 250mb.

...

I'm not saying JavaScript is bad and that we don't need it to evolve - I'm just saying that the ROI on a fully featured wasm runtime in the browser is massive and that browser vendors & the standards committee are sleeping on it - which is hugely frustrating.

Re: When Is WebAssembly Going to Get DOM Support?

#209

Post by yencabulator »

Fluorescence wrote: post #98
criticalfault wrote: post #91

Earlier quoted context omitted.

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 gene…

> It's meant to be language independent hence the IDL.

This in the same conversation where people are saying the DOM API is intrinsically tied to Javascript!

Re: When Is WebAssembly Going to Get DOM Support?

#210

Post by ItsHarper »

9dev wrote: post #105
austin-cheney wrote: post #59

Earlier quoted context omitted.

The biggest problem solved by WASM is runtime portability. For security reasons many users and organizations will not download or install untrusted binaries. WASM provides a safer alternative in an often temporary way. The universal nature is an unintended byproduct of a naive sandbox, though still wonderful.

Why would WASM be any less secure than JavaScript?

It's not, they're saying it's a safer alternative to traditional binaries
Post reply on HN