3 ms·

WebAssembly cannot access the DOM. So, not a full replacement.

by fuzzy2 2y ago

peutetre 2y ago
Sure it can. It's true you have to use JavaScript glue code, but it's also true that won't be true forever.
- lelanthran 2y ago
  > It's true you have to use JavaScript glue code, but it's also true that won't be true forever. I won't live forever and I'd like to deliver my product before I die.
  - peutetre 2y ago
    It isn't onerous. Here's an example using Scheme in the browser: https://www.spritely.institute/news/building-interactive-web-pages-with-guile-hoot.html https://www.spritely.institute/news/building-interactive-web...
    - hu3 2y ago
      At this point one should think if TypeScript isn't a better solution for most frontend code.
    - lelanthran 2y ago
      > It isn't onerous. Here's an example using Scheme in the browser: > https://www.spritely.institute/news/building-interactive-web https://www.spritely.institute/news/building-interactive-web... That looks pretty damn onerous to me: 1. (Guile) Declare all the JS symbols you wish to use. 2. (JS) Write wrappers for the symbols from #1 above. In short, you're still writing custom glue code for manipulating the DOM from the wasm language, and you'll need more custom glue code if you ever want to call your wasm functions from JS (for example, from the `onclick` attribute in an element tag, from `setInterval()`, from resolution of a promise, etc). This is not what I meant by my response in the following exchange: >>> It's true you have to use JavaScript glue code, but it's also true that won't be true forever. >> I won't live forever and I'd like to deliver my product before I die. Right now, it is true that wasm DOM access is non-existent, needs glue code to be existent, and the DOM <--> wasm interface, even with glue code, is limited as hell. I don't know if there are plans to address this. It is irresponsible of me to use wasm for a client today under the assumption that, by the time I need a DOM <--> wasm interface, it will be there. Before the limitations of the DOM <--> wasm interface is ever addressed, the product might even have reached end of life.

WebAssembly cannot access the DOM. So, not a full replacement.

by fuzzy2 2y ago

WebAssembly cannot access the DOM. So, not a full replacement.

peutetre 2y ago

Sure it can. It's true you have to use JavaScript glue code, but it's also true that won't be true forever.

lelanthran 2y ago
> It's true you have to use JavaScript glue code, but it's also true that won't be true forever. I won't live forever and I'd like to deliver my product before I die.
- peutetre 2y ago
  It isn't onerous. Here's an example using Scheme in the browser: https://www.spritely.institute/news/building-interactive-web-pages-with-guile-hoot.html https://www.spritely.institute/news/building-interactive-web...
  - hu3 2y ago
    At this point one should think if TypeScript isn't a better solution for most frontend code.
  - lelanthran 2y ago
    > It isn't onerous. Here's an example using Scheme in the browser: > https://www.spritely.institute/news/building-interactive-web https://www.spritely.institute/news/building-interactive-web... That looks pretty damn onerous to me: 1. (Guile) Declare all the JS symbols you wish to use. 2. (JS) Write wrappers for the symbols from #1 above. In short, you're still writing custom glue code for manipulating the DOM from the wasm language, and you'll need more custom glue code if you ever want to call your wasm functions from JS (for example, from the `onclick` attribute in an element tag, from `setInterval()`, from resolution of a promise, etc). This is not what I meant by my response in the following exchange: >>> It's true you have to use JavaScript glue code, but it's also true that won't be true forever. >> I won't live forever and I'd like to deliver my product before I die. Right now, it is true that wasm DOM access is non-existent, needs glue code to be existent, and the DOM <--> wasm interface, even with glue code, is limited as hell. I don't know if there are plans to address this. It is irresponsible of me to use wasm for a client today under the assumption that, by the time I need a DOM <--> wasm interface, it will be there. Before the limitations of the DOM <--> wasm interface is ever addressed, the product might even have reached end of life.