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

151–160 of 213 posts

Re: When Is WebAssembly Going to Get DOM Support?

#151

Post by whywhywhywhy »

thaumasiotes wrote: post #51
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 asked a number of times on HN why wasm was good when java applets, exactly the same thing, were bad. There was a vague feeling that java applets were insecure and that this would somehow not be an issue for wasm. It's not just applets; we also had Flash, which was a huge success until it was suddenly killed. As far as I can tell, the difference between java applets and Flash is that you, the user, have to install j…

WASM doesn’t feel like an “applet” and can be either seamlessly integrated or take over the space.

Applets felt horrible, maybe if they appeared today it would be different but back then the machines were not powerful enough and the system not integrated enough to make it feel smooth.

Re: When Is WebAssembly Going to Get DOM Support?

#152

Post by jauntywundrkind »

serbuvlad wrote: post #33
boomskats wrote: post #25

Earlier quoted context omitted.

> So on the one side you have organizations that definitely don't want to easily give network/filesystem/etc. access to code and on the other side you have people wanting it to be easier to get this access I don't think this is entirely fair or accurate. This isn't how Wasm runtimes work. Making it possible for the sandbox to explicitly request specific resource access is not quite the same thing as what you're imply…

> The potential benefits to enterprise orgs that ship thousands of multi-gig docker containers a week with microservices architectures that just run simple business logic, are very substantial. What are you talking about? Alpine container image is If a service has a multi-gig container, that is for other stuff than the Docker overhead itself, so would also be a multi-gig app for WASM too. Also, Docker images get over…

> Alpine container image is

That's not the deployment model of wasm. You don't ship the runtime and the code in a container.

If you look at crun, it can detect if your container is wasm and run it automatically, without your container bundling the runtime. I don't know what crun does, but in wasmcloud for example, you're running multiple different wasm applications atop the same wam runtime. https://github.com/containers/crun/blob/main/docs/wasm-wasi-...

Re: When Is WebAssembly Going to Get DOM Support?

#153

Post by fidotron »

xg15 wrote: post #116

Is there any data on the performance cost of JS/WASM context switches? The way the architecture is described, it sounds as if the costs could be substantial, but the approaches described in the article basically hand them out like candy. This would sort of defeat the point that WASM is supposed to be for the "performance critical" parts of the application only. It doesn't seem very useful if your business logic runs…

This problem is how you spot people that have tried to do it vs those that just talk about it. Everyone ends up with batching calls back and forth because the cost is so high.

Separately the conceptual mismatch when the js has to allocate/deallocate things on the wasm side is also tedious to deal with.

Re: When Is WebAssembly Going to Get DOM Support?

#154

Post by jauntywundrkind »

hoodchatham wrote: post #9
jauntywundrkind wrote: post #2

Law of question marks on headlines holds here: no / never seems to be the answer. Article l also discussed ref types, which do exist and do provide... Something. Some ability to at least refer to host objects. It's not clear what that enables or what it's limitstions are. Definitely some feeling of being rug-pulled in the shift here. It felt like there was a plan for good integration, but fast forward half a decade+…

Reference types makes wasm/js interoperability way cleaner and easier. wasm-gc added a way to test a function pointer for whether it will trap or not. And JSPI is a standard since April and available in Chrome >= 137. I think JSPI is the greatest step forward for webassembly in the browser ever. Just need Firefox and Safari to implement it...

I'd really love a deep dive on what reference types enable and what limitations they have. Why are reference types not an end-all be-all "When is WebAssembly Going to Get DOM Support?" 'we have them now' answer?

Re: When Is WebAssembly Going to Get DOM Support?

#156

Post by Muromec »

gchamonlive wrote: post #42

I have zero experience with anything wasm, just regular old DOM with typescript, but I wonder if this is the kind of problem that could be addressed the same way that phoenix liveview addesses frontend updates, by message passing only with diff changes, and delegate the Dom manipulation to what works, effective modelling the wasm runtime as an actor.

It's one of the ways one can write the glue between WASM and JS. The actual problem is, like everything in javascript, there is no standard glue, no ABI, no expectation of what memory representation of a list or even a string looks like.

You can even compile elixir into wasm-fx and run actor model, it's super fun and mad, but what you can't do is not deal with the technicalities.

So either you buy into one of the frameworks that are (not) built on top of wasm and lock into their paradigm or roll your own, because wasm proper doesn't even have any abstractions above numbers on a stack.

Re: When Is WebAssembly Going to Get DOM Support?

#157

Post by pton_xd »

Why does WASM need to manipulate the DOM when JS already excels at that? Interfacing with JS was never really an issue; yes you do have to design reasonable module boundaries and understand how data is going to be shared. That just leads to simpler / stronger program design.

If you're writing a DOM UI heavy app, use JavaScript. Many WASM apps, like games, have no interest in the DOM. It's just more spec bloat.

Re: When Is WebAssembly Going to Get DOM Support?

#158

Post by Muromec »

Havoc wrote: post #28

> Wasm includes various JavaScript APIs that allow compiler-generated glue code One of the reasons I’m interested in wasm is to get away from the haphazardly evolved JS ecosystem…

You get more of that with wasm actually. You get the rust zoo, elixir zoo, gleam, three toolchains for c or what not. And for each of them you need a bunch of fine autogenerated javascript glue to sniff, because those people can't agree on what the string looks like in memory.

Re: When Is WebAssembly Going to Get DOM Support?

#160

Post by jazzypants »

flakiness wrote: post #123

Tangent: ACM queue this months seems to be dedicated to Wasm. Nice! https://queue.acm.org/issuedetail.cfm?issue=3747201

Yeah, the concurrency article is quite excellent as well. I definitely recommend it!

I also don't think it has been posted here, so feel free to do so.

Post reply on HN