4 ms·

> Since WebAssembly can't directly interact with the dom (yet) Going off at a tangent, is there a reason WebAssembly can't interact with the DOM? I would have

> Since WebAssembly can't directly interact with the dom (yet) Going off at a tangent, is there a reason WebAssembly can't interact with the DOM? I would have thought that being able to do so would be kinda useful, particularly in a web page.

codeflo 3y ago
WebAssembly can interact with JavaScript, and JavaScript can access the DOM. This was a compromise to reduce attack surface and implementation effort, to get a version 1 out the door. Allowing direct DOM access would have required implementors to harden every individual DOM API to make sure the new call path doesn’t open any security holes. The WASM-to-JS layer is comparably tiny, and the JS-to-DOM layer is already there and (hopefully) secure.
- cabalamat 3y ago
  But if WASM can call JS, and JS can then interact with the DOM, then doesn't tat allow WASM to exploit security holes in the DOM?
- xigoi 3y ago
  But doesn't it defeat the point of using WebAssembly, since you have to pass everything through JavaScript anyway (and therefore it's at the speed of JavaScript)?
  - taosx 3y ago
    In cases where you care about performance, yes. Newer webassembly frameworks (rust from what i remember) are batching operations to the DOM for that exact reason.
devjab 3y ago
Codeflo answers it from the security perspective, but I’ll add a little to it in that WebAssembly doesn’t want to replace JavaScript. At least not currently, but it wasn’t always like that and there has been a long road of getting to this point with a lot of discussions on the topic. This may be dumbing it down a little, but basically it was decided that replacing JavaScript was unrealistic. So for now you can think of it as a range of different things in the form of web development. You can view it as a sort of non-proprietary flash, where you can technically distribute your flash-like application to any browser. You can also view it like another form of virtual DOM (of sorts) the way Microsoft tries to do with Blazor, or you can view it as JavaScript “modules” where you do compute heavy stuff with C++ and implement it in your otherwise JavaScript frontend. But that’s just the web part, WebAssembly wants to be more than that, but you should go to their documentation for a better understanding of that. It would be kind of useful to have WebAssembly interact with the DOM and I’m not completely convinced that the security would be a major issue, but it’s a massive undertaking, and it’s likely going to be sort of in vain. Because JavaScript is moving forward at a much higher pace than WebAssembly. One of the primary reasons you often see listed is that the DOM is slow, but that’s not really true. Because the adding or removing a DOM node is literally a few pointer swaps, which isn't much more than setting a property on an OOP language object. What is slow is "layout". When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow. Imagine handling that, again, when we’re not even really intend on doing so in most frontend JavaScript. What I mean by this is that one or the reasons we use React (and by we I mean the global we) is that it’s much easier to not fuck-up with the virtual DOM, and while things like Blazor is valid alternatives, they aren’t remotely comparable even when backed by Microsoft. So it’s really a question of “do we want to do all that work, when all that work is already being done better by someone else?”, and for now the answer is “no”. Which is disappointing to many, but probably not the many who were going to contribute anyway.
- throwaway3245 3y ago
  Excellent overview, thank you. WebAssembly is something I have seen mentioned for maybe 10 years but I never really took time to actually figure out what it is. I suppose I still don't truly know but for a 2 minute read, it cleared up a lot of my misunderstanding.
- codeflo 3y ago
  I don't think that's the consensus opinion, and suggesting that it is might be misleading to people who are less informed than you are. You already mention Blazor, which would hugely profit from direct DOM access. Various React-like frameworks now exist for various languages that target WebAssembly, all of them would receive performance benefits from not having to go through a JavaScript layer all the time. That's the community side. On the standards side, efforts to enable direct Web IDL bindings are still underway, they just take time. Some things have been postponed because the issues are more complex than originally anticipated. But this will eventually happen.
  - devjab 3y ago
    > I don't think that's the consensus opinion Maybe, but wasn’t this the reason DOM replacement was removed from the roadmap?

codeflo 3y ago

WebAssembly can interact with JavaScript, and JavaScript can access the DOM. This was a compromise to reduce attack surface and implementation effort, to get a version 1 out the door. Allowing direct DOM access would have required implementors to harden every individual DOM API to make sure the new call path doesn’t open any security holes. The WASM-to-JS layer is comparably tiny, and the JS-to-DOM layer is already there and (hopefully) secure.

cabalamat 3y ago
But if WASM can call JS, and JS can then interact with the DOM, then doesn't tat allow WASM to exploit security holes in the DOM?
xigoi 3y ago
But doesn't it defeat the point of using WebAssembly, since you have to pass everything through JavaScript anyway (and therefore it's at the speed of JavaScript)?
- taosx 3y ago
  In cases where you care about performance, yes. Newer webassembly frameworks (rust from what i remember) are batching operations to the DOM for that exact reason.

devjab 3y ago

Codeflo answers it from the security perspective, but I’ll add a little to it in that WebAssembly doesn’t want to replace JavaScript. At least not currently, but it wasn’t always like that and there has been a long road of getting to this point with a lot of discussions on the topic. This may be dumbing it down a little, but basically it was decided that replacing JavaScript was unrealistic. So for now you can think of it as a range of different things in the form of web development. You can view it as a sort of non-proprietary flash, where you can technically distribute your flash-like application to any browser. You can also view it like another form of virtual DOM (of sorts) the way Microsoft tries to do with Blazor, or you can view it as JavaScript “modules” where you do compute heavy stuff with C++ and implement it in your otherwise JavaScript frontend. But that’s just the web part, WebAssembly wants to be more than that, but you should go to their documentation for a better understanding of that. It would be kind of useful to have WebAssembly interact with the DOM and I’m not completely convinced that the security would be a major issue, but it’s a massive undertaking, and it’s likely going to be sort of in vain. Because JavaScript is moving forward at a much higher pace than WebAssembly. One of the primary reasons you often see listed is that the DOM is slow, but that’s not really true. Because the adding or removing a DOM node is literally a few pointer swaps, which isn't much more than setting a property on an OOP language object. What is slow is "layout". When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen. The layout algorithm is quite complex and it's synchronous, which makes it stupidly easy to make thing slow. Imagine handling that, again, when we’re not even really intend on doing so in most frontend JavaScript. What I mean by this is that one or the reasons we use React (and by we I mean the global we) is that it’s much easier to not fuck-up with the virtual DOM, and while things like Blazor is valid alternatives, they aren’t remotely comparable even when backed by Microsoft. So it’s really a question of “do we want to do all that work, when all that work is already being done better by someone else?”, and for now the answer is “no”. Which is disappointing to many, but probably not the many who were going to contribute anyway.

throwaway3245 3y ago
Excellent overview, thank you. WebAssembly is something I have seen mentioned for maybe 10 years but I never really took time to actually figure out what it is. I suppose I still don't truly know but for a 2 minute read, it cleared up a lot of my misunderstanding.
codeflo 3y ago
I don't think that's the consensus opinion, and suggesting that it is might be misleading to people who are less informed than you are. You already mention Blazor, which would hugely profit from direct DOM access. Various React-like frameworks now exist for various languages that target WebAssembly, all of them would receive performance benefits from not having to go through a JavaScript layer all the time. That's the community side. On the standards side, efforts to enable direct Web IDL bindings are still underway, they just take time. Some things have been postponed because the issues are more complex than originally anticipated. But this will eventually happen.
- devjab 3y ago
  > I don't think that's the consensus opinion Maybe, but wasn’t this the reason DOM replacement was removed from the roadmap?