5 ms·

It's crazy that people say that WASM won't replace JavaScript. This demonstrates a use case better suited for languages with better threading models than JavaSc

It's crazy that people say that WASM won't replace JavaScript. This demonstrates a use case better suited for languages with better threading models than JavaScript. Feels like the web world is desperately in need of competent threading capabilities. Can I (practically) use Rust or Go in the browser via wasm already!?

leptons 2y ago
Call me crazy but, WASM won't replace JavaScript. There are so many cases where a simple script will do. Firing up a terminal, writing in another language, compiling and going through the trouble to turn something simple into WASM is actually the crazy thing to do. Also, I am in no way approving of the techniques described in the article.
- chamomeal 2y ago
  Yeah but most big web apps aren’t simple. If wasm ever replaces JS in a significant way, it won’t be replacing simple scripts. It’ll be replacing webpack lol
  - explaininjs 2y ago
    Why would wasm be needed for build time tools? We already use fast compiled languages for modern webpack replacements (esbuild, swc, Bun :: Go, Rust, Zig), and they don’t use wasm.
  - metadaemon 2y ago
    I do love the idea of a dedicated compiler handling my builds. Even with the most modern build tools today, large web applications can take minutes to build which doesn't include type checking, linting and testing. If you're not prioritizing build times as your app grows, this can quickly balloon.
  - leptons 2y ago
    >It's crazy that people say that WASM won't replace JavaScript. >big web apps So you've defined the goalpost as "big web apps". There are billions more use cases for Javascript than however many "big web apps" might exist. So your phrasing is too broad, maybe consider: >>It's crazy that people say that WASM won't replace JavaScript in big web apps. Nobody's saying that. You are free to use WASM for your "big web app". Nobody and nothing is stopping you. WASM certainly has its place, but it also certainly won't replace JavaScript in most of the places JavaScript is used every day. "Big web apps" are (my guess) maybe 1,000,000 of the 49,501,698 websites that use JavaScript, but it would depend on how you define "big web app" (and I really don't want go down that goal-posting rabbit hole). There are 13.8 million people writing javascript every day, how many of them do you think are working on "big web apps" that actually need WASM? How many of them do you think want to switch to Rust from Javascript? "developers" always seem to think everyone else should be some rockstar 10x programmer, but most use cases for javascript are pretty simple, and yet totally effective for what the requirements typically are.
    - chamomeal 2y ago
      Damn I’m just playing devils advocate for your point of “WASM won’t replace JS because there is a build process”. I don’t think everybody needs to be building big web apps, I just think that most full time developers writing JS (or TS) are probably on a team working on a web app, so the introduction of a build process isn’t really an issue. Of course it’s valid to write good ol’ javascript. I do it all the time. I’m always happy to avoid dealing with webpack
AgentME 2y ago
Even with multithreaded WASM, the DOM will still only be usable from the page's (or iframe's) main thread, so if you want to do DOM operations not on the page's main thread you'll still need to do the same steps OP's project does (create an iframe and do stuff there).
explaininjs 2y ago
This use case is purposefully hamstringed for demo purposes. Rust or Go won’t change anything here, you still need to pass messages to/from the worker. Same exact mechanism as if you used a webworker, which are already widely available. But to answer your question, yes you can use Rust and Go practically in the browser. It just isn’t all that helpful except in narrow circumstances.
- apatheticonion 2y ago
  Fair, you're right that typically you'd have a dedicated UI thread with workers handling business logic. The difference with Rust and Go is they have better synchronization capabilities - where JavaScript largely forces you to clone data between threads. So while you may still be messaging worker threads in Rust/Go - threads share memory which is fast and you have access to things like atomics and mutexes. We can use Rust in the browser today with WASM and it's super cool - but without something like WASI, extensive thunking through JavaScript is required, plus there are issues with threading. I hope that one day we can initialize a wasm module via a script tag with the browser offering a wasi interface `<script src="module.wasm" type="application/wasi">` And that browsers allow for threading without the restrictive security headers we have today
  - mr_toad 2y ago
    There is a proposal to add threading to WASM itself https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/main/proposals/t... But that’s not going to help when accessing the DOM.
    - apatheticonion 2y ago
      Oh nice! That will be helpful. I guess WASI doesn't help with DOM access either - that's more about file access and such? Is there a proposal(s) covering DOM access? I remember interface types were a thing a few years back. If you have access to a dom object (I assume by pointer?) and it is removed/GC'd - would the wasm module have a null pointer?
mr_toad 2y ago
The language has nothing to do with it. You can use “WASM threads” from Rust or Go. Or JavaScript for that matter. Under the hood it’s all workers and shared array buffer, nothing to do with the language. Last time I checked you can’t even use std::thread for instance in Rust, since the compiler doesn’t understand workers (because workers aren’t actually part of WASM). None of which will help you when updating the DOM anyway, since that happens in its own thread. It’s up to the browser how they run their rendering engine and I doubt they’re ever likely to allow direct control over that.
jauntywundrkind 2y ago
> Can I (practically) use Rust or Go in the browser via wasm already!? You can (built into rust and tinygo for go.)! And wasm-threading has been around for a while! https://webassembly.org/features/ https://webassembly.org/features/ But I don't think these wasm-threading capabilities are well harnesses by any languages yet. There been a decade of webworkers being super possible. That does get multi-threading! With transferable memory & everything. So, this isn't like some new super non-js thing. Some folks do use workers, but alas not popular enough, not something React or Angular helps steer folks to. Whats super neat and tricky here is that the iframe in separate origin-agent-cluster has a full DOM implementation that's there & raring to go. We already could have tried using jsdom or happy-dom or a wasm-powered alternative in a worker to do something like this, already. This is super cool though because it's much lower code! It uses a dom runtime that's already loaded & available (the browser's) rather than having to ship & load a separate DOM runtime.

leptons 2y ago

Call me crazy but, WASM won't replace JavaScript. There are so many cases where a simple script will do. Firing up a terminal, writing in another language, compiling and going through the trouble to turn something simple into WASM is actually the crazy thing to do. Also, I am in no way approving of the techniques described in the article.

chamomeal 2y ago
Yeah but most big web apps aren’t simple. If wasm ever replaces JS in a significant way, it won’t be replacing simple scripts. It’ll be replacing webpack lol
- explaininjs 2y ago
  Why would wasm be needed for build time tools? We already use fast compiled languages for modern webpack replacements (esbuild, swc, Bun :: Go, Rust, Zig), and they don’t use wasm.
- metadaemon 2y ago
  I do love the idea of a dedicated compiler handling my builds. Even with the most modern build tools today, large web applications can take minutes to build which doesn't include type checking, linting and testing. If you're not prioritizing build times as your app grows, this can quickly balloon.
- leptons 2y ago
  >It's crazy that people say that WASM won't replace JavaScript. >big web apps So you've defined the goalpost as "big web apps". There are billions more use cases for Javascript than however many "big web apps" might exist. So your phrasing is too broad, maybe consider: >>It's crazy that people say that WASM won't replace JavaScript in big web apps. Nobody's saying that. You are free to use WASM for your "big web app". Nobody and nothing is stopping you. WASM certainly has its place, but it also certainly won't replace JavaScript in most of the places JavaScript is used every day. "Big web apps" are (my guess) maybe 1,000,000 of the 49,501,698 websites that use JavaScript, but it would depend on how you define "big web app" (and I really don't want go down that goal-posting rabbit hole). There are 13.8 million people writing javascript every day, how many of them do you think are working on "big web apps" that actually need WASM? How many of them do you think want to switch to Rust from Javascript? "developers" always seem to think everyone else should be some rockstar 10x programmer, but most use cases for javascript are pretty simple, and yet totally effective for what the requirements typically are.
  - chamomeal 2y ago
    Damn I’m just playing devils advocate for your point of “WASM won’t replace JS because there is a build process”. I don’t think everybody needs to be building big web apps, I just think that most full time developers writing JS (or TS) are probably on a team working on a web app, so the introduction of a build process isn’t really an issue. Of course it’s valid to write good ol’ javascript. I do it all the time. I’m always happy to avoid dealing with webpack

AgentME 2y ago

Even with multithreaded WASM, the DOM will still only be usable from the page's (or iframe's) main thread, so if you want to do DOM operations not on the page's main thread you'll still need to do the same steps OP's project does (create an iframe and do stuff there).

explaininjs 2y ago

This use case is purposefully hamstringed for demo purposes. Rust or Go won’t change anything here, you still need to pass messages to/from the worker. Same exact mechanism as if you used a webworker, which are already widely available. But to answer your question, yes you can use Rust and Go practically in the browser. It just isn’t all that helpful except in narrow circumstances.

apatheticonion 2y ago
Fair, you're right that typically you'd have a dedicated UI thread with workers handling business logic. The difference with Rust and Go is they have better synchronization capabilities - where JavaScript largely forces you to clone data between threads. So while you may still be messaging worker threads in Rust/Go - threads share memory which is fast and you have access to things like atomics and mutexes. We can use Rust in the browser today with WASM and it's super cool - but without something like WASI, extensive thunking through JavaScript is required, plus there are issues with threading. I hope that one day we can initialize a wasm module via a script tag with the browser offering a wasi interface `<script src="module.wasm" type="application/wasi">` And that browsers allow for threading without the restrictive security headers we have today
- mr_toad 2y ago
  There is a proposal to add threading to WASM itself https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md https://github.com/WebAssembly/threads/blob/main/proposals/t... But that’s not going to help when accessing the DOM.
  - apatheticonion 2y ago
    Oh nice! That will be helpful. I guess WASI doesn't help with DOM access either - that's more about file access and such? Is there a proposal(s) covering DOM access? I remember interface types were a thing a few years back. If you have access to a dom object (I assume by pointer?) and it is removed/GC'd - would the wasm module have a null pointer?

mr_toad 2y ago

The language has nothing to do with it. You can use “WASM threads” from Rust or Go. Or JavaScript for that matter. Under the hood it’s all workers and shared array buffer, nothing to do with the language. Last time I checked you can’t even use std::thread for instance in Rust, since the compiler doesn’t understand workers (because workers aren’t actually part of WASM). None of which will help you when updating the DOM anyway, since that happens in its own thread. It’s up to the browser how they run their rendering engine and I doubt they’re ever likely to allow direct control over that.

jauntywundrkind 2y ago

> Can I (practically) use Rust or Go in the browser via wasm already!? You can (built into rust and tinygo for go.)! And wasm-threading has been around for a while! https://webassembly.org/features/ https://webassembly.org/features/ But I don't think these wasm-threading capabilities are well harnesses by any languages yet. There been a decade of webworkers being super possible. That does get multi-threading! With transferable memory & everything. So, this isn't like some new super non-js thing. Some folks do use workers, but alas not popular enough, not something React or Angular helps steer folks to. Whats super neat and tricky here is that the iframe in separate origin-agent-cluster has a full DOM implementation that's there & raring to go. We already could have tried using jsdom or happy-dom or a wasm-powered alternative in a worker to do something like this, already. This is super cool though because it's much lower code! It uses a dom runtime that's already loaded & available (the browser's) rather than having to ship & load a separate DOM runtime.