3 ms·

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ https://component-mo

If you’d like to get acquainted with modern WebAssembly, check out the component model book: https://component-model.bytecodealliance.org/ https://component-model.bytecodealliance.org/ It includes high level concepts, practical code samples and more that introduce the really powerful parts of WebAssembly. With regards to the JS ecosystem specifically there are 3 projects to know: https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodealliance/StarlingMonkey https://github.com/bytecodealliance/ComponentizeJS https://github.com/bytecodealliance/ComponentizeJS https://github.com/bytecodealliance/jco https://github.com/bytecodealliance/jco The most mature tool chain right now is Rust, but there is good support for most things with LLVM underneath (C/C++ via clang). Golang, python and support for other languages is getting better and better (tinygo and big go) and there’s even more to come. One of the goals of WebAssembly is to melt right into your local $TOOLCHAIN as a compilation target, and we are getting closer every week.

flohofwoe 7mo ago
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 7mo ago
  You're replying to a comment on an article about how WASM does not work fine in the browser
  - flohofwoe 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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).
pjmlp 7mo ago
Hello COM, CORBA, RMI, Jini, .NET Remoting, Tcl Agents,..., that is basically what it is.
- hardwaresofton 7mo ago
  Very reductive :) there are flavors and hints of all these previous technologies /paradigms in WebAssembly + Component Model today, because only fools would attempt to build something without considering relevant prior art. Won't bother trying going through differences/how-this-is-not-that but I'll say this: This time, it's slightly better, just like every time before. I'd even go so far as to say this iteration is much better than what came before, and the speed of adoption by multiple language toolchains, platforms, operating systems, browsers proves that.
  - pjmlp 7mo ago
    So far I haven't seen that on the existing tooling, nothing that would make me say it is much better, rather it looks much worse given the developer experience. Zero IDE integration, no right mouse click to generate or consume interfaces/stubs, no debugging tools, no integration with existing toolchains like those alternatives, no wire debugging,.... It feels designed for those that never left the command line, vim and emacs kind of world.
    - hardwaresofton 7mo ago
      I think we probably disagree on the most important parts of the tooling. I’m a lot more focused on what it lets me do/whether the abstractions are right. That said, people have worked on IDE integration (it’s not zero, ex. WIT syntax highlighting), there is existing integration with upstream language tool chains, but trying to debate that seems silly. Whether tech is good or worth exploring is not dictated by IDE support, I think! There has been substantial work on improving debugging, DX and documentation! Hopefully in the LLM age the existing can move even faster
    - Touche 7mo ago
      Why would "right mouse click" be part of a protocol?

flohofwoe 7mo ago

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 7mo ago
You're replying to a comment on an article about how WASM does not work fine in the browser
- flohofwoe 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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).

pjmlp 7mo ago

Hello COM, CORBA, RMI, Jini, .NET Remoting, Tcl Agents,..., that is basically what it is.

hardwaresofton 7mo ago
Very reductive :) there are flavors and hints of all these previous technologies /paradigms in WebAssembly + Component Model today, because only fools would attempt to build something without considering relevant prior art. Won't bother trying going through differences/how-this-is-not-that but I'll say this: This time, it's slightly better, just like every time before. I'd even go so far as to say this iteration is much better than what came before, and the speed of adoption by multiple language toolchains, platforms, operating systems, browsers proves that.
- pjmlp 7mo ago
  So far I haven't seen that on the existing tooling, nothing that would make me say it is much better, rather it looks much worse given the developer experience. Zero IDE integration, no right mouse click to generate or consume interfaces/stubs, no debugging tools, no integration with existing toolchains like those alternatives, no wire debugging,.... It feels designed for those that never left the command line, vim and emacs kind of world.
  - hardwaresofton 7mo ago
    I think we probably disagree on the most important parts of the tooling. I’m a lot more focused on what it lets me do/whether the abstractions are right. That said, people have worked on IDE integration (it’s not zero, ex. WIT syntax highlighting), there is existing integration with upstream language tool chains, but trying to debate that seems silly. Whether tech is good or worth exploring is not dictated by IDE support, I think! There has been substantial work on improving debugging, DX and documentation! Hopefully in the LLM age the existing can move even faster
  - Touche 7mo ago
    Why would "right mouse click" be part of a protocol?