3 ms·

Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application i

by xscott 2y ago

Can you give an example of anything anywhere that manipulates the DOM without using JavaScript? Because it seems to me that pretty much every web application is currently using the javascript host, and the well written ones are pretty snappy.

em-bee 2y ago
this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did you mean there are snappy webapplications running in WASM? if you have any examples, i'd be curiuos to learn more.
- xscott 2y ago
  Previously you said: > [...] go through the javascript host, which is slow And now you admit: > this is going beyond my level of experience [...] > how much slower, i don't know I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma. > did you mean there are snappy webapplications running in WASM? No. I meant that all existing web apps go through the "javascript host", using JavaScript. So if any of them are fast enough, and some certainly are, the problem isn't the "javascript host".
  - em-bee 2y ago
    you are not answering my question. most existing webapps are not running inside WASM. i am only talking about webapps running inside WASM. are there any WASM based webapps that are as fast as pure js webapps?
    - xscott 2y ago
      > you are not answering my question Lol, your question asked me what I meant. I told you what I meant. > are there any WASM based webapps that are as fast as pure js webapps? You can browse links from Google for examples and benchmarks. Maybe one of these will scratch your itch, but I won't vouch for any of them: https://madewithwebassembly.com/ https://madewithwebassembly.com/ But really, JavaScript and WebAssembly are both very fast. I don't think speed is the reason to choose one or the other. For me, I like WebAssembly because it lets me program in languages other than JavaScript. JavaScript makes me want to scratch my eyes out.
- sshine 2y ago
  > i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are available. Those things aren't available in other JavaScript VMs, like Node. (There's no DOM to interact with.) And they're not yet available in the WASM VM in the browser, either. The reason is that the WASM APIs/ABIs have not stabilised. It takes time to make right, but there is progress.
  - em-bee 2y ago
    That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available
    - davexunit 2y ago
      A fundamental aspect of the Wasm capability security model is that all access to the outside world (I/O) is controlled via imports. Direct access to the entire browser API doesn't make sense in this context.

by xscott 2y ago

em-bee 2y ago

this is going beyond my level of experience, but i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM, which is slower. how much slower, i don't know. i also don't know how old that discussion is where i learned about this. so maybe it improved since. that would be good news. did you mean there are snappy webapplications running in WASM? if you have any examples, i'd be curiuos to learn more.

xscott 2y ago
Previously you said: > [...] go through the javascript host, which is slow And now you admit: > this is going beyond my level of experience [...] > how much slower, i don't know I guess people just repeat what they hear without questioning or understanding it, and then it becomes dogma. > did you mean there are snappy webapplications running in WASM? No. I meant that all existing web apps go through the "javascript host", using JavaScript. So if any of them are fast enough, and some certainly are, the problem isn't the "javascript host".
- em-bee 2y ago
  you are not answering my question. most existing webapps are not running inside WASM. i am only talking about webapps running inside WASM. are there any WASM based webapps that are as fast as pure js webapps?
  - xscott 2y ago
    > you are not answering my question Lol, your question asked me what I meant. I told you what I meant. > are there any WASM based webapps that are as fast as pure js webapps? You can browse links from Google for examples and benchmarks. Maybe one of these will scratch your itch, but I won't vouch for any of them: https://madewithwebassembly.com/ https://madewithwebassembly.com/ But really, JavaScript and WebAssembly are both very fast. I don't think speed is the reason to choose one or the other. For me, I like WebAssembly because it lets me program in languages other than JavaScript. JavaScript makes me want to scratch my eyes out.
sshine 2y ago
> i thought there can't be any such example because javascript is the only way. the difference is between code written in javascript which is fast of course and accessing js functions from WASM That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. The browser exposes a browser API to the JavaScript VM it hosts, so things like the DOM are available. Those things aren't available in other JavaScript VMs, like Node. (There's no DOM to interact with.) And they're not yet available in the WASM VM in the browser, either. The reason is that the WASM APIs/ABIs have not stabilised. It takes time to make right, but there is progress.
- em-bee 2y ago
  That doesn't have to be true. Eventually WASM will get direct access to the full browser API, without going through JavaScript. well, that is what i am waiting for. my point is that it's not the case yet, while the gp seemed to suggest that it's not needed because access through the host is available
  - davexunit 2y ago
    A fundamental aspect of the Wasm capability security model is that all access to the outside world (I/O) is controlled via imports. Direct access to the entire browser API doesn't make sense in this context.