3 ms·

Call me when browsers support another language. What are we going to use? CSS?

modeless 2y ago
wasm "but wasm has to call JavaScript to use browser APIs" WasmGC is shipped in Chrome and Firefox and enabled by default in WebKit nightly
- johnfn 2y ago
  Let me know when WASM has a dev workflow that gets a change to your browser 1/10th as fast as Vite + TypeScript + React.
  - modeless 2y ago
    The web is undefeated in iteration time for sure. There are some native workflows that approach it with hot code reloading, but I'm not aware of anyone doing that for wasm yet.
  - xpe 2y ago
    I will grant that fast iteration is beneficial. But for me, under 10 seconds is usually fast enough. (For example, I don't think I would care too much when comparing 0.5 vs 5 second builds.) I personally care a lot more about having a confidence-inspiring language and ecosystem. In my experience with Rust and WASM (with various tools such as Dioxus), I find myself caring a lot more about the WASM ecosystem and browser evolution/improvement. For example, at bottom, the JS interop feels pretty sub-optimal. Calling this "hcky" might even be deserved: I'm talking about memory serialization between JS-land and WASM-land. As I understand it, we may see significant improvement under the hood in the next few years. (I'm not an expert on the particular proposals, their adoption, etc. Please weigh in if you have a better sense.)
    - johnfn 2y ago
      The reason I bring it up is because web-dev often ends up being an extremely long sequence of small tweaks. "Hmm, did that make the modal go on top of the sidebar? [save] no? [save] did that? [save] how about that? [savesavesavesavesavesave]" Iterate that process 1000 times and you have my typical workflow. This is why even a 10 second build time, which is pretty fast for most domains, is actually pretty mind-numbing in web-dev. I'm all for having a confidence-inspiring language and ecosystem, don't get me wrong, but it's kind of a non-starter if I can't build at the same pace in Rust as I can in typical web technologies.
- nuz 2y ago
  WasmGC is just garbage collection? Not browser APIs
  - modeless 2y ago
    My understanding is that GC integration was the major blocker for better wasm/browser API integration. Now that it is here I bet better integration is not far behind, although I haven't personally investigated the current proposals.
- postalrat 2y ago
  WASM has to call javascript to do really anything.
- bastawhiz 2y ago
  Great, show us how you render something on the page with wasm only
slashdave 2y ago
Well... sort of? https://emscripten.org https://emscripten.org
- bastawhiz 2y ago
  Which compiles to...
  - jitl 2y ago
    WebAssembly
    - bastawhiz 2y ago
      Which is only usable on the web with...
- wiseowise 2y ago
  Amazing dev experience for sure. 10/10.
Arch485 2y ago
Oh yeah. CSS is turing complete, after all!

wasm "but wasm has to call JavaScript to use browser APIs" WasmGC is shipped in Chrome and Firefox and enabled by default in WebKit nightly

johnfn 2y ago
Let me know when WASM has a dev workflow that gets a change to your browser 1/10th as fast as Vite + TypeScript + React.
- modeless 2y ago
  The web is undefeated in iteration time for sure. There are some native workflows that approach it with hot code reloading, but I'm not aware of anyone doing that for wasm yet.
- xpe 2y ago
  I will grant that fast iteration is beneficial. But for me, under 10 seconds is usually fast enough. (For example, I don't think I would care too much when comparing 0.5 vs 5 second builds.) I personally care a lot more about having a confidence-inspiring language and ecosystem. In my experience with Rust and WASM (with various tools such as Dioxus), I find myself caring a lot more about the WASM ecosystem and browser evolution/improvement. For example, at bottom, the JS interop feels pretty sub-optimal. Calling this "hcky" might even be deserved: I'm talking about memory serialization between JS-land and WASM-land. As I understand it, we may see significant improvement under the hood in the next few years. (I'm not an expert on the particular proposals, their adoption, etc. Please weigh in if you have a better sense.)
  - johnfn 2y ago
    The reason I bring it up is because web-dev often ends up being an extremely long sequence of small tweaks. "Hmm, did that make the modal go on top of the sidebar? [save] no? [save] did that? [save] how about that? [savesavesavesavesavesave]" Iterate that process 1000 times and you have my typical workflow. This is why even a 10 second build time, which is pretty fast for most domains, is actually pretty mind-numbing in web-dev. I'm all for having a confidence-inspiring language and ecosystem, don't get me wrong, but it's kind of a non-starter if I can't build at the same pace in Rust as I can in typical web technologies.
nuz 2y ago
WasmGC is just garbage collection? Not browser APIs
- modeless 2y ago
  My understanding is that GC integration was the major blocker for better wasm/browser API integration. Now that it is here I bet better integration is not far behind, although I haven't personally investigated the current proposals.
postalrat 2y ago
WASM has to call javascript to do really anything.
bastawhiz 2y ago
Great, show us how you render something on the page with wasm only

slashdave 2y ago

Well... sort of? https://emscripten.org https://emscripten.org

bastawhiz 2y ago
Which compiles to...
- jitl 2y ago
  WebAssembly
  - bastawhiz 2y ago
    Which is only usable on the web with...
wiseowise 2y ago
Amazing dev experience for sure. 10/10.

Arch485 2y ago

Oh yeah. CSS is turing complete, after all!