4 ms·

Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web developmen

by xvilka 8y ago

Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.

swsieber 8y ago
That overhead has been greatly reduced in Firefox recently.
- PaulBGD_ 8y ago
  Can you explain more what changed? Super interested in this.
  - steveklabnik 8y ago
    https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
- snek 8y ago
  Same with V8, since they added the liftoff compiler back in august
  - swsieber 8y ago
    At least on my android phone, Firefox is still an order of magnitude faster in some benchmarks.
BinaryIdiot 8y ago
While I agree that access will eventually come. I love seeing the experiments thus far and can't wait until WASM hits the same amount of capability via DOM access that JS has. That day will change the web forever, IMO.
austincheney 8y ago
That is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a stated project design goal of WASM. You have to understand that Web Assembly is there to fill the proprietary application add-in void of things like Flash using open standards safely in a way that is technology agnostic. Web Assembly is not there to serve as a crutch for people afraid of web technologies. Secondly, there will never be direct DOM access from WebAssembly for security reasons. While that is the nail in the coffin on this matter there is the more practical consideration that developers, even those who write JavaScript full time for a living, tend to be deathly afraid of touching the DOM. If this were a reality the inevitable overhead (think of all the dependencies, frameworks, and abstractions developers cannot live without because the DOM is scary) would likely be just as high, or higher, than writing your own DOM library embedded within your WARM instance. Thirdly, you can have a DOM interface in a WASM instance. This is part of the web components API, but DOM trees created for the WASM instances are islands to the WASM instance created from external JavaScript - https://medium.com/coinmonks/develop-w3c-web-components-with-webassembly-d65938284255 https://medium.com/coinmonks/develop-w3c-web-components-with...
- steveklabnik 8y ago
  Direct DOM access is certainly happening; it’s the thing that the wasm people are working on next. (Well, its prerequisites...) I agree with you that that doesn’t mean anything with regards to “killing JS” or anything.
- kristiandupont 8y ago
  >there will never be direct DOM access from WebAssembly for security reasons You should contribute this knowledge: https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 >developers, [...], tend to be deathly afraid of touching the DOM I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile. I am writing JS in the entire stack at the moment and I am mostly happy with it. I don't think that ability will go away but I look forward to the day where I can do the same in Rust or F# or whatever. And it doesn't seem unlikely to me that one day we will see wasm becoming the foundation in browsers, with JS running on top of it like any other language.
bayesian_horse 8y ago
As far as I have understood it, interfacing with JS is quite efficient now. DOM access isn't that bad either.

by xvilka 8y ago

Until there is direct DOM access within WebAssembly, the overhead of calling back and forth to JS will prevent wider adoption and ditching JS for Web development.

swsieber 8y ago

That overhead has been greatly reduced in Firefox recently.

PaulBGD_ 8y ago
Can you explain more what changed? Super interested in this.
- steveklabnik 8y ago
  https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
snek 8y ago
Same with V8, since they added the liftoff compiler back in august
- swsieber 8y ago
  At least on my android phone, Firefox is still an order of magnitude faster in some benchmarks.

BinaryIdiot 8y ago

While I agree that access will eventually come. I love seeing the experiments thus far and can't wait until WASM hits the same amount of capability via DOM access that JS has. That day will change the web forever, IMO.

austincheney 8y ago

That is never going to happen. This is a constant theme on Reddit at r/programming. It is based upon nothing but fear of web technologies (yes, I literally mean fear as a raw and savage emotion) and a lack of understanding what WASM is. It is best to think of WASM as an embeddedable VM for JavaScript rather than opposed to JavaScript. https://webassembly.org/ https://webassembly.org/ First of all JS cannot ever be replaced by WASM. This is a stated project design goal of WASM. You have to understand that Web Assembly is there to fill the proprietary application add-in void of things like Flash using open standards safely in a way that is technology agnostic. Web Assembly is not there to serve as a crutch for people afraid of web technologies. Secondly, there will never be direct DOM access from WebAssembly for security reasons. While that is the nail in the coffin on this matter there is the more practical consideration that developers, even those who write JavaScript full time for a living, tend to be deathly afraid of touching the DOM. If this were a reality the inevitable overhead (think of all the dependencies, frameworks, and abstractions developers cannot live without because the DOM is scary) would likely be just as high, or higher, than writing your own DOM library embedded within your WARM instance. Thirdly, you can have a DOM interface in a WASM instance. This is part of the web components API, but DOM trees created for the WASM instances are islands to the WASM instance created from external JavaScript - https://medium.com/coinmonks/develop-w3c-web-components-with-webassembly-d65938284255 https://medium.com/coinmonks/develop-w3c-web-components-with...

steveklabnik 8y ago
Direct DOM access is certainly happening; it’s the thing that the wasm people are working on next. (Well, its prerequisites...) I agree with you that that doesn’t mean anything with regards to “killing JS” or anything.
kristiandupont 8y ago
>there will never be direct DOM access from WebAssembly for security reasons You should contribute this knowledge: https://github.com/WebAssembly/proposals/issues/16 https://github.com/WebAssembly/proposals/issues/16 >developers, [...], tend to be deathly afraid of touching the DOM I truly have never seen this. In fact, I'd say I often see a rather careless culture of doing DOM manipulation here and there because it solves an immediate problem, albeit by short-circuiting the abstractions that may be in place and are now a bit more fragile. I am writing JS in the entire stack at the moment and I am mostly happy with it. I don't think that ability will go away but I look forward to the day where I can do the same in Rust or F# or whatever. And it doesn't seem unlikely to me that one day we will see wasm becoming the foundation in browsers, with JS running on top of it like any other language.

bayesian_horse 8y ago

As far as I have understood it, interfacing with JS is quite efficient now. DOM access isn't that bad either.