5 ms·

WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity. But there's still far to go. Large parts of the browser API ar

by sshine 2y ago

WebAssembly could replace JavaScript, the assembly language, once it has reached feature parity. But there's still far to go. Large parts of the browser API are still not directly available in WASM. I very much look forward to WASM reaching stability. It's very enjoyable to run Rust code in the browser.

em-bee 2y ago
right, making those APIs accessible from WASM is something i am also waiting for.
- croes 2y ago
  So you want more rights for code that’s harder to read than obfuscated JS?
xscott 2y ago
What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.
- em-bee 2y ago
  direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
  - peutetre 2y ago
    Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
    - emseetech 2y ago
      Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.
      - xscott 2y ago
        What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
        anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
        em-bee 2y ago
        there is also option D. wait for a framework that implements option A. if option A works, why aren't there any frameworks yet that implement it? maybe all the framework devs are waiting for C? but why? you could be right about A but at present the majority view seems to be that C is the right option. which is what pushes me into going with B because i have no interest in developing my own framework. if a framework appears that implements option A i'll gladly consider it. (just as long as it isn't tightly coupled with a backend)
  - 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.
  - davexunit 2y ago
    All imports have to come from the host, which in the case of the web means they have to be expressed as JavaScript. Behind the scenes they could be optimized, though, and I've heard that JS/Wasm engines maybe already be doing this with well-known imports (think Math.sin).
  - leptons 2y ago
    The DOM itself is very slow, much slower than Javascript, so you're not going to be seeing any great performance increase if WASM can access the DOM directly. I also have to wonder if people are excited about replacing Javascript, why they would want to have HTML/CSS/DOM on top of WASM. A different front-end UI tech could be much better than slow, old DOM.

by sshine 2y ago

em-bee 2y ago

right, making those APIs accessible from WASM is something i am also waiting for.

croes 2y ago
So you want more rights for code that’s harder to read than obfuscated JS?

xscott 2y ago

What parts are not available? WebAssembly can call arbitrary JavaScript through imports. You could literally provide an `eval` function if you were motivated to.

em-bee 2y ago
direct access to the DOM for example without having to go through the javascript host, which is slow and makes DOM intensive applications impractical
- peutetre 2y ago
  Or you can just draw to canvas to make the UI fast which is what Flutter does now: https://flutterweb-wasm.web.app/ https://flutterweb-wasm.web.app/ https://www.youtube.com/watch?v=Nkjc9r0WDNo https://www.youtube.com/watch?v=Nkjc9r0WDNo
  - emseetech 2y ago
    Drawing to canvas means recreating the UI and all its wide-sweeping concerns, which is quite an undertaking. And even if it were accomplished in a central open source library like Flutter, that adds a considerable amount to the package size of any application. Acceptable (or even preferred) for certain applications but not for most. Providing access to an already proven DOM would be the better solution.
    - xscott 2y ago
      What would access to the DOM look like? WASM already has import and export (nearly) arbitrary functions. People keep saying it can't manipulate the DOM, but it clearly can. So, what's missing?
      - anonzzzies 2y ago
        What is missing is that I never want to touch js for anything, so how do I do that if I have to write glue and imports in js/ts?
        xscott 2y ago
        I thing we agree. JavaScript is awful, and TypeScript is simultaneously impressive and still awful. I think we have three options: A) Get your hands dirty and write what you want. Once. B) Chant along with the mob who doesn't even understand what they're asking for. C) Wait several years for some super complicated solution to be designed by committee. I wouldn't even want direct access to the DOM if we had it today. The DOM as an API is atrocious. Instead, I want a set of nice functions that do things like put a graphical chart on the page - all in one call. Or one call to pass a bunch of 3D triangles or splats to visualize in a WebGL canvas. Or one call to play some audio samples. Or a function to poll for recording audio. And so on... I choose option A.
        em-bee 2y ago
        there is also option D. wait for a framework that implements option A. if option A works, why aren't there any frameworks yet that implement it? maybe all the framework devs are waiting for C? but why? you could be right about A but at present the majority view seems to be that C is the right option. which is what pushes me into going with B because i have no interest in developing my own framework. if a framework appears that implements option A i'll gladly consider it. (just as long as it isn't tightly coupled with a backend)
- 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.
- davexunit 2y ago
  All imports have to come from the host, which in the case of the web means they have to be expressed as JavaScript. Behind the scenes they could be optimized, though, and I've heard that JS/Wasm engines maybe already be doing this with well-known imports (think Math.sin).
- leptons 2y ago
  The DOM itself is very slow, much slower than Javascript, so you're not going to be seeing any great performance increase if WASM can access the DOM directly. I also have to wonder if people are excited about replacing Javascript, why they would want to have HTML/CSS/DOM on top of WASM. A different front-end UI tech could be much better than slow, old DOM.