4 ms·

Get your blatant component model propaganda outta here ;) (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly"

Get your blatant component model propaganda outta here ;) (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh)

hmry 8mo ago
You're replying to a comment on an article about how WASM does not work fine in the browser
- flohofwoe 8mo ago
  The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into browsers is overkill for that (and everything else belongs into the toolchains without touching the browser guts).
  - hmry 8mo ago
    > The entire article boils down to one specific problem: string marshalling overhead No, I don't think so at all. 80% of the article is about other problems (JS bindings are complicated to generate and a leaky abstraction, additional tools beyond the compiler are required, compiler authors don't want to deal with them, they increase the friction for getting started, they're hard to debug, ...)
    - flohofwoe 8mo ago
      ...all those problems should be fixed in the toolchains, not in the browser. Emscripten exists, DWARF debugging support exists and works (I can step from C/C++ code into JS code and back with the WASM DWARF debugging extension for VSCode), other language ecosystems just need to catch up.
      - troad 8mo ago
        You're implying the only solution to unnecessary friction is reams of unnecessary lubricant. Someone had to spend time building those unnecessary toolchains. Imagine if this time were spent developing cool libraries or use cases for WASM, instead of building out plumbing.
hardwaresofton 8mo ago
> Get your blatant component model propaganda outta here ;) It's perfectly good content, sir! > (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh) WebAssembly absolutely works fine without the component model, and I'd argue it's much better with the component model. Here's my simple pitch. world before component model: > be me > build a webassembly core module > give it to someone > they ask what imports it needs > they ask how to run it > they ask how to provide high level types to it world after component model: > be me > write an IDL (WIT[0]) interface which specifies what the component should do > write the webassembly component WebAssembly gives us an incredible tool -- a new compilation target that is secure, performant and extensible. We could crudely liken this to RISCV. In $CURRENT_YEAR it doesn't make sense to stop at the RISCV layer and then let everyone create their own standards and chaos in 50 directions on what the 1/2/3 step higher abstractions should be. Emscripten carried the torch (and still does great work of course) in building this layer that people could build on top of, but it didn't go far enough. Tools like wasm_bindgen in Rust work great but lack cross-platform usage. The Component Model is absolutely the future of WebAssembly. Maybe not the future of WebAssembly core, but if you want to be productive and do increasingly interesting things with WebAssembly, the Component Model is the standards-backed, community-driven, cross-platform, ambitious way to do things with WebAssembly. To be incredibly blunt, the failure of other attempts to centralize community, effort, and bring people along to build a shared thing that is just low cost enough that everyone can build on top is impressive. Nothing against other efforts, but I just can't find any similar efforts that others have standardized on in any meaningful way. We're talking about a (partially already here) world where every popular programming language just outputs to WebAssembly natively and computers on every popular architecture/platform have an easy time running those binaries and libraries? If that's not the future, paint me a different one/show me movement in that direction -- genuinely would love to see what I'm missing! And in all of this, the Component Model is optional -- if you don't like it, don't use it. If WebAssembly core works for you, you are absolutely free to build! wasm32-unknown-unknown is right there, waiting for you to target it (in Rust at least).

hmry 8mo ago

You're replying to a comment on an article about how WASM does not work fine in the browser

flohofwoe 8mo ago
The entire article boils down to one specific problem: string marshalling overhead can be optimized to be about 2x faster. Integrating the component model into browsers is overkill for that (and everything else belongs into the toolchains without touching the browser guts).
- hmry 8mo ago
  > The entire article boils down to one specific problem: string marshalling overhead No, I don't think so at all. 80% of the article is about other problems (JS bindings are complicated to generate and a leaky abstraction, additional tools beyond the compiler are required, compiler authors don't want to deal with them, they increase the friction for getting started, they're hard to debug, ...)
  - flohofwoe 8mo ago
    ...all those problems should be fixed in the toolchains, not in the browser. Emscripten exists, DWARF debugging support exists and works (I can step from C/C++ code into JS code and back with the WASM DWARF debugging extension for VSCode), other language ecosystems just need to catch up.
    - troad 8mo ago
      You're implying the only solution to unnecessary friction is reams of unnecessary lubricant. Someone had to spend time building those unnecessary toolchains. Imagine if this time were spent developing cool libraries or use cases for WASM, instead of building out plumbing.

hardwaresofton 8mo ago

> Get your blatant component model propaganda outta here ;) It's perfectly good content, sir! > (to elaborate: WASM works just fine without the component model, it's not "the future of WebAssembly", just an option built on top of it, and of questionable value tbh) WebAssembly absolutely works fine without the component model, and I'd argue it's much better with the component model. Here's my simple pitch. world before component model: > be me > build a webassembly core module > give it to someone > they ask what imports it needs > they ask how to run it > they ask how to provide high level types to it world after component model: > be me > write an IDL (WIT[0]) interface which specifies what the component should do > write the webassembly component WebAssembly gives us an incredible tool -- a new compilation target that is secure, performant and extensible. We could crudely liken this to RISCV. In $CURRENT_YEAR it doesn't make sense to stop at the RISCV layer and then let everyone create their own standards and chaos in 50 directions on what the 1/2/3 step higher abstractions should be. Emscripten carried the torch (and still does great work of course) in building this layer that people could build on top of, but it didn't go far enough. Tools like wasm_bindgen in Rust work great but lack cross-platform usage. The Component Model is absolutely the future of WebAssembly. Maybe not the future of WebAssembly core, but if you want to be productive and do increasingly interesting things with WebAssembly, the Component Model is the standards-backed, community-driven, cross-platform, ambitious way to do things with WebAssembly. To be incredibly blunt, the failure of other attempts to centralize community, effort, and bring people along to build a shared thing that is just low cost enough that everyone can build on top is impressive. Nothing against other efforts, but I just can't find any similar efforts that others have standardized on in any meaningful way. We're talking about a (partially already here) world where every popular programming language just outputs to WebAssembly natively and computers on every popular architecture/platform have an easy time running those binaries and libraries? If that's not the future, paint me a different one/show me movement in that direction -- genuinely would love to see what I'm missing! And in all of this, the Component Model is optional -- if you don't like it, don't use it. If WebAssembly core works for you, you are absolutely free to build! wasm32-unknown-unknown is right there, waiting for you to target it (in Rust at least).