6 ms·

Has there been any meaningful progress in doing DOM manipulation (and accessing other web APIs) from WASM?

flohofwoe 4y ago
Depends on what you mean. The DOM still strictly lives on the Javascript side (and IMHO that's a good thing), but the calling overhead from WASM to JS (and back) has been reduced in browsers (ca 2018/19) so that the overhead doesn't matter much anymore, and Emscripten has features to keep the JS shim close to the C/C++ side (by embedding Javascript directly into C/C++ source files). That way it's quite trivial to build a C or C++ library which manipulates the DOM by calling out into small JS source snippets. To the user of such a library it doesn't make a difference whether WASM manipulates the DOM directly or goes through a JS shim. WASM proposals like Interface Types (or whatever it is called currently) will reduce the amount of housekeeping needed by the JS shim, but that would only affect the library maintainer, not the library user. (IMHO: using WASM for a framework which spends most of its time manipulating the DOM is wasted effort, JS is much better suited for this type of "dynamic workload", this type of application might be better done with a hybrid approach where Javascript and WASM work hand in hand)
- gspr 4y ago
  > (IMHO: using WASM for a framework which spends most of its time manipulating the DOM is wasted effort, JS is much better suited for this type of "dynamic workload", this type of application might be better done with a hybrid approach where Javascript and WASM work hand in hand) Well, I suspect there might be a non-trivial number of us who have absolutely no interest in learning JS, but would like to do DOM manipulation in web apps written 100% in [Personal Favorite Language That Compiles To WASM].
  - flohofwoe 4y ago
    FWIW if you look around, C++ and Rust libraries for DOM manipulation exist (I haven't searched for other languages which compile to WASM): https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore I think solving the problem of DOM access on the library level is exactly the right way to tackle this problem. The library user don't need to care about specific WASM features, and the library implementation can be simplified when those WASM features become available (and also implement per-browser fallback paths)
    - tcfhgj 4y ago
      Those libs/frame works would benefit massively from WASM DOM access.
      - irrational 4y ago
        But, why? You would have to recompile the WASM code every time a change was made to the DOM. Add a new DIV that you now need to address? Add a reference to it in the WASM code and recompile. What a pain that would be.
        gspr 4y ago
        I don't understand. Can you elaborate?
        HexDecOctBin 4y ago
        A div's name is equivalent to a pointer to a widget in a GUI library. HTML isn't some special sauce, we've known how to do GUI in C/C++ for a long time.
      - flohofwoe 4y ago
        I doubt it. What would "DOM access in WASM" even look like? The DOM is exposed as a tree of high level Javascript objects with properties, but WASM has no notion of objects, properties and their relationship, it only has a few integer and floating point primitive types and heap addresses. All that "DOM access from WASM" would mean is that there's a new primitive "external reference" type which allows to tunnel an opaque Javascript object reference through WASM and back to JS while pinning the JS object for the JS garbage collector. But one couldn't really do anything useful with that reference on the WASM side without calling through JS (AFAIK there are some very high level proposals for this too, which could basically create the required JS shim code automatically, but that would just add more runtime complexity for little actual gain - the same shim-generation work could be done offline in the compiler toolchain). All that the "external reference" type would enable is a slightly simplified Javascript shim, because it would no longer need to map index handles to Javascript objects. But that's just a small part of what the JS shim does. It's a bit like asking if x86 machine code has support for the Win32 window system API, the answer is both 'yes' and 'no' ;)
  - xwolfi 4y ago
    I think trivial. Manipulating the DOM without Javascript is as useful to understand it as manipulating a car without hands. It can work other ways, you can prefer it but it wasn't made for that amount of flexibility. Better use wasm for what it's good at: obfuscation of proprietary code, high intensity mathematics, port of existing code. Not adding a span in a div please.
    - gspr 4y ago
      > I think trivial. Neither one of us can back up our claims, but: Surely there's a non-trivial amount of people out there who abhor JS and who would still want to be able to target the web as a platform? > Manipulating the DOM without Javascript is as useful to understand it as manipulating a car without hands. Why? If you mean that because "things are the way they are", then sure, but this isn't a fundamental limitation. > Better use wasm for what it's good at: obfuscation of proprietary code, That's not what WASM is for. > high intensity mathematics, port of existing code. Not adding a span in a div please. But why? Why should that last task be the domain of only JS? I think this is exactly the attitude that has kept me shying away from the web as a platform. On classical OS platforms, they may well be better suited and less suited languages for a given task – but declaring that you mustn't do something in a given language is just strange to me. Yet it seems like the norm on the web.
      - esperent 4y ago
        > Surely there's a non-trivial amount of people out there who abhor JS The amount of people for whom the hate is deserved and not just a knee jerk reaction is probably trivial though (at least once you include Typescript and ES6). Modern JS is not a bad language and it's time for hating on it to go out of fashion.
        gspr 4y ago
        > The amount of people for whom the hate is deserved and not just a knee jerk reaction is probably trivial though (at least once you include Typescript and ES6). Modern JS is not a bad language and it's time for hating on it to go out of fashion. I'm not saying it's a bad language any more than I'm saying that strawberry ice cream is bad. I'm merely stating the fact that there's a non-trivial amount of people who abhor strawberry ice cream and JS. I find your reply, that strawberry ice cream is perfectly fine, a strange one.
  - NohatCoder 4y ago
    So you want to avoid the horrors of the web by inserting some language-warping piece of glue code that is guaranteed to only ever get in your way. The irony. In any case, the DOM and CSS is like 90% of the reason to hate the basic web stack. The other 90% of the reason that people hate JavaScript for is the myriad of frameworks that some people opt to use. You don't have to, and if you come from C you will probably feel right at home not doing so.
    - gspr 4y ago
      > So you want to avoid the horrors of the web by inserting some language-warping piece of glue code that is guaranteed to only ever get in your way. The irony. No, I in particular want to avoid glue code! > In any case, the DOM and CSS is like 90% of the reason to hate the basic web stack. The other 90% of the reason that people hate JavaScript for is the myriad of frameworks that some people opt to use. You don't have to, and if you come from C you will probably feel right at home not doing so. Perhaps. In my case, it's simply that I abhor the idea that this particular platform requires one specific langauge. I think that's rather dumb. I'd prefer to treat web browsers as just another platform. I do understand that this platform is a bit different from the classical ones (Linux, Windows, Mac, the other unices, take the cartesian product with hardware architectures if you want) in that it doesn't have a notion of file access (and a bunch of other things), but still – just another (a bit esoteric) platform nonetheless. The platform shouldn't care what language you write in, as long as you have a compiler targeting it. I pick my language—any with a compiler that targets the platforms I require—and then I perhaps write different frontends depending on the platform. Maybe on the unices the frontend reads and writes files. Maybe on Windows it's GUI based. And maybe on the browser one interacts with it through DOM manipulation. That last detail shouldn't, IMHO, dictate that the language used. We don't accept that in other situations, so why do we when it comes to the web?
      - NohatCoder 4y ago
        > We don't accept that in other situations, so why do we when it comes to the web? Because it is the only thing we have sufficiently sandboxed so that we can actually run it untrusted. I totally get what you want, but we already have a bunch of X-to-JavaScript compilers that pretty much all deliver the experience of: "It works, but it is a bit gnarly, so why would you use this when you can just write JavaScript". And I don't think WebAssembly is going to change that experience much, mainly because it is a pretty poor VM, seemingly designed around the misconception that a lack of features makes it a good compilation target. I honestly think we could give compiled languages a much better time on the web with a new intermediate language, but someone has to design it for that purpose rather than cargo cult Assembly similarity.
- HexDecOctBin 4y ago
  > the calling overhead from WASM to JS (and back) This is what I meant: is it still necessary to go through JS, or do we now get low level access to DOM directly through WASM? I guess we don't.

Depends on what you mean. The DOM still strictly lives on the Javascript side (and IMHO that's a good thing), but the calling overhead from WASM to JS (and back) has been reduced in browsers (ca 2018/19) so that the overhead doesn't matter much anymore, and Emscripten has features to keep the JS shim close to the C/C++ side (by embedding Javascript directly into C/C++ source files). That way it's quite trivial to build a C or C++ library which manipulates the DOM by calling out into small JS source snippets. To the user of such a library it doesn't make a difference whether WASM manipulates the DOM directly or goes through a JS shim. WASM proposals like Interface Types (or whatever it is called currently) will reduce the amount of housekeeping needed by the JS shim, but that would only affect the library maintainer, not the library user. (IMHO: using WASM for a framework which spends most of its time manipulating the DOM is wasted effort, JS is much better suited for this type of "dynamic workload", this type of application might be better done with a hybrid approach where Javascript and WASM work hand in hand)

gspr 4y ago
> (IMHO: using WASM for a framework which spends most of its time manipulating the DOM is wasted effort, JS is much better suited for this type of "dynamic workload", this type of application might be better done with a hybrid approach where Javascript and WASM work hand in hand) Well, I suspect there might be a non-trivial number of us who have absolutely no interest in learning JS, but would like to do DOM manipulation in web apps written 100% in [Personal Favorite Language That Compiles To WASM].
- flohofwoe 4y ago
  FWIW if you look around, C++ and Rust libraries for DOM manipulation exist (I haven't searched for other languages which compile to WASM): https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom https://github.com/sycamore-rs/sycamore https://github.com/sycamore-rs/sycamore I think solving the problem of DOM access on the library level is exactly the right way to tackle this problem. The library user don't need to care about specific WASM features, and the library implementation can be simplified when those WASM features become available (and also implement per-browser fallback paths)
  - tcfhgj 4y ago
    Those libs/frame works would benefit massively from WASM DOM access.
    - irrational 4y ago
      But, why? You would have to recompile the WASM code every time a change was made to the DOM. Add a new DIV that you now need to address? Add a reference to it in the WASM code and recompile. What a pain that would be.
      - gspr 4y ago
        I don't understand. Can you elaborate?
      - HexDecOctBin 4y ago
        A div's name is equivalent to a pointer to a widget in a GUI library. HTML isn't some special sauce, we've known how to do GUI in C/C++ for a long time.
    - flohofwoe 4y ago
      I doubt it. What would "DOM access in WASM" even look like? The DOM is exposed as a tree of high level Javascript objects with properties, but WASM has no notion of objects, properties and their relationship, it only has a few integer and floating point primitive types and heap addresses. All that "DOM access from WASM" would mean is that there's a new primitive "external reference" type which allows to tunnel an opaque Javascript object reference through WASM and back to JS while pinning the JS object for the JS garbage collector. But one couldn't really do anything useful with that reference on the WASM side without calling through JS (AFAIK there are some very high level proposals for this too, which could basically create the required JS shim code automatically, but that would just add more runtime complexity for little actual gain - the same shim-generation work could be done offline in the compiler toolchain). All that the "external reference" type would enable is a slightly simplified Javascript shim, because it would no longer need to map index handles to Javascript objects. But that's just a small part of what the JS shim does. It's a bit like asking if x86 machine code has support for the Win32 window system API, the answer is both 'yes' and 'no' ;)
- xwolfi 4y ago
  I think trivial. Manipulating the DOM without Javascript is as useful to understand it as manipulating a car without hands. It can work other ways, you can prefer it but it wasn't made for that amount of flexibility. Better use wasm for what it's good at: obfuscation of proprietary code, high intensity mathematics, port of existing code. Not adding a span in a div please.
  - gspr 4y ago
    > I think trivial. Neither one of us can back up our claims, but: Surely there's a non-trivial amount of people out there who abhor JS and who would still want to be able to target the web as a platform? > Manipulating the DOM without Javascript is as useful to understand it as manipulating a car without hands. Why? If you mean that because "things are the way they are", then sure, but this isn't a fundamental limitation. > Better use wasm for what it's good at: obfuscation of proprietary code, That's not what WASM is for. > high intensity mathematics, port of existing code. Not adding a span in a div please. But why? Why should that last task be the domain of only JS? I think this is exactly the attitude that has kept me shying away from the web as a platform. On classical OS platforms, they may well be better suited and less suited languages for a given task – but declaring that you mustn't do something in a given language is just strange to me. Yet it seems like the norm on the web.
    - esperent 4y ago
      > Surely there's a non-trivial amount of people out there who abhor JS The amount of people for whom the hate is deserved and not just a knee jerk reaction is probably trivial though (at least once you include Typescript and ES6). Modern JS is not a bad language and it's time for hating on it to go out of fashion.
      - gspr 4y ago
        > The amount of people for whom the hate is deserved and not just a knee jerk reaction is probably trivial though (at least once you include Typescript and ES6). Modern JS is not a bad language and it's time for hating on it to go out of fashion. I'm not saying it's a bad language any more than I'm saying that strawberry ice cream is bad. I'm merely stating the fact that there's a non-trivial amount of people who abhor strawberry ice cream and JS. I find your reply, that strawberry ice cream is perfectly fine, a strange one.
- NohatCoder 4y ago
  So you want to avoid the horrors of the web by inserting some language-warping piece of glue code that is guaranteed to only ever get in your way. The irony. In any case, the DOM and CSS is like 90% of the reason to hate the basic web stack. The other 90% of the reason that people hate JavaScript for is the myriad of frameworks that some people opt to use. You don't have to, and if you come from C you will probably feel right at home not doing so.
  - gspr 4y ago
    > So you want to avoid the horrors of the web by inserting some language-warping piece of glue code that is guaranteed to only ever get in your way. The irony. No, I in particular want to avoid glue code! > In any case, the DOM and CSS is like 90% of the reason to hate the basic web stack. The other 90% of the reason that people hate JavaScript for is the myriad of frameworks that some people opt to use. You don't have to, and if you come from C you will probably feel right at home not doing so. Perhaps. In my case, it's simply that I abhor the idea that this particular platform requires one specific langauge. I think that's rather dumb. I'd prefer to treat web browsers as just another platform. I do understand that this platform is a bit different from the classical ones (Linux, Windows, Mac, the other unices, take the cartesian product with hardware architectures if you want) in that it doesn't have a notion of file access (and a bunch of other things), but still – just another (a bit esoteric) platform nonetheless. The platform shouldn't care what language you write in, as long as you have a compiler targeting it. I pick my language—any with a compiler that targets the platforms I require—and then I perhaps write different frontends depending on the platform. Maybe on the unices the frontend reads and writes files. Maybe on Windows it's GUI based. And maybe on the browser one interacts with it through DOM manipulation. That last detail shouldn't, IMHO, dictate that the language used. We don't accept that in other situations, so why do we when it comes to the web?
    - NohatCoder 4y ago
      > We don't accept that in other situations, so why do we when it comes to the web? Because it is the only thing we have sufficiently sandboxed so that we can actually run it untrusted. I totally get what you want, but we already have a bunch of X-to-JavaScript compilers that pretty much all deliver the experience of: "It works, but it is a bit gnarly, so why would you use this when you can just write JavaScript". And I don't think WebAssembly is going to change that experience much, mainly because it is a pretty poor VM, seemingly designed around the misconception that a lack of features makes it a good compilation target. I honestly think we could give compiled languages a much better time on the web with a new intermediate language, but someone has to design it for that purpose rather than cargo cult Assembly similarity.
HexDecOctBin 4y ago
> the calling overhead from WASM to JS (and back) This is what I meant: is it still necessary to go through JS, or do we now get low level access to DOM directly through WASM? I guess we don't.