6 ms·

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's

by eqrion 6mo ago

I worked on the original interface-types proposal a little bit before it became the component model. Two goals that were added were: 1. Support non-Web API's 2. Support limited cross language interop WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Component interfaces take more of an intersection approach that isn't as expressive, but is much more portable. I personally have always cared about DOM access, but the Wasm CG has been really busy with higher priority things. Writing this post was sort of a way to say that at least some people haven't forgotten about this, and still plan on working on this.

mananaysiempre 6mo ago
> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Yes, another part of the problem, unrelated to the WIT story, seems to have been the abandonment of the idea that <script> could be something other than JavaScript and that the APIs should try to accomodate that, which had endured for a good while based on pure idealism. That sure would have come useful here when other languages became relevant again. (Now with the amputation of XSLT as the final straw, it is truly difficult to feel any sort of idealism from the browser side, even if in reality some of the developers likely retain it. Thank you for caring and persisting in this instance.)
- nineteen999 6mo ago
  Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "world wide web". Go on. I dare you!
  - bfivyvysj 6mo ago
    Web assembly has never had anything to do with the web. At least that's been my experience whenever I find it in production.
    - pjmlp 6mo ago
      It definitly had to do everything with Web, it was the agreement between Mozila going with asm.js, Chrome pushing for PNaCL, Adobe with CrossBridge, Sun with Java, Microsoft with ActiveX,.... Then some folks rediscovered UNCOL from 1958, all the systems influenced by it, and started to sell the dream of the bytecode that was going to save the world.
    - flohofwoe 6mo ago
      This is retconning the history of WASM. While WASM was designed to be also be usable outside browsers, nobody could really predict at the time what this usage would look like exactly.
    - tegmentum 6mo ago
      That's were it came from but it's perfectly able to run in environments that don't have anything to do with the web.
  - afiori 6mo ago
    The web part is the security model and the tradeoffs between security and performance. PNaCL was in browsers but not "web" for this reason. Like the assembly part means low-level and meant as a compilation target, not CPU instructions. So websssembly is an assembly language for the web, like webgl is opengl for the web and webgpu are gpu APIs for the web. And behold none of those can access DOM APIs
    - flohofwoe 6mo ago
      > So webassembly is an assembly language for the web. But is isn't, at most WAT is (the WASM text format). WASM itself is a bytecode format. Nobody calls CPU machine code 'assembly' (nitpicking, I know, but the 'web' part of the name makes a lot more sense than the 'assembly' part).
- laughinghan 6mo ago
  You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly? Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?
  - flohofwoe 6mo ago
    > but I don’t understand how #2 cross-lang interop could ever have been optional This problem hasn't been solved outside the web either (at least not to the satisfaction of Rust fanboys who expect that they can tunnel their high level stdlib types directly to other languages - while conveniently ignoring that other languages have completely different semantics and very little overlap with the Rust stdlib). At the core, the component model is basically an attempt to tunnel high level types to other languages, but with a strictly Rust-centric view of the world (the selection of 'primitive types' is essentially a random collection of Rust stdlib types).
    - jnbridge 6mo ago
      The cross-language type-mapping problem is where every interop approach eventually runs aground. The component model's challenge is the same one that hit every bridge technology before it: whose type system is "canonical"? .NET's Common Type System was supposed to be the neutral ground for dozens of languages. In practice, it had strong C# biases — try using unsigned integers from VB or F#'s discriminated unions from C#. The CLR "primitive types" were just as much a random collection as the WIT primitives are being described here. The practical lesson from two decades of cross-runtime integration: stop trying to tunnel high-level types. The approaches that survive in production define a minimal shared surface (essentially: scalars, byte buffers, and handles) and let each side do its own marshaling. It's less elegant but it doesn't break every time one side's stdlib evolves. WASM's linear memory model actually gets this right at the low level — the problem is everyone wants the convenience layer on top, and that's where the type-system politics start.
      - 6mo ago
paxcoder 6mo ago
[dead]

by eqrion 6mo ago

mananaysiempre 6mo ago

> Two goals that were added were: 1. Support non-Web API's. 2. Support limited cross language interop. I mean, surely it does not come to a surprise to anyone that either of these is a huge deal, let alone both. It seems clear that non-Web runtimes have had a huge influence on the development priorities of WebAssembly—not inherently a bad thing but in this case it came at the expense of the actual Web. > WebIDL is the union of JS and Web API's, and while expressive, has many concepts that conflict with those goals. Yes, another part of the problem, unrelated to the WIT story, seems to have been the abandonment of the idea that <script> could be something other than JavaScript and that the APIs should try to accomodate that, which had endured for a good while based on pure idealism. That sure would have come useful here when other languages became relevant again. (Now with the amputation of XSLT as the final straw, it is truly difficult to feel any sort of idealism from the browser side, even if in reality some of the developers likely retain it. Thank you for caring and persisting in this instance.)

nineteen999 6mo ago
Technology with "web" in the name, invented by Web fanboys, not really much good for working with key web API's like the DOM. Cool parts of the webassembly technology aside - this should be no surprise to anybody. News at 11. The non-sequitur in the title of this post should be enough to give everybody pause. Waiting for someone to chime in and tell me that the "web" in "webassembly" wasn't meant to refer to the "world wide web". Go on. I dare you!
- bfivyvysj 6mo ago
  Web assembly has never had anything to do with the web. At least that's been my experience whenever I find it in production.
  - pjmlp 6mo ago
    It definitly had to do everything with Web, it was the agreement between Mozila going with asm.js, Chrome pushing for PNaCL, Adobe with CrossBridge, Sun with Java, Microsoft with ActiveX,.... Then some folks rediscovered UNCOL from 1958, all the systems influenced by it, and started to sell the dream of the bytecode that was going to save the world.
  - flohofwoe 6mo ago
    This is retconning the history of WASM. While WASM was designed to be also be usable outside browsers, nobody could really predict at the time what this usage would look like exactly.
  - tegmentum 6mo ago
    That's were it came from but it's perfectly able to run in environments that don't have anything to do with the web.
- afiori 6mo ago
  The web part is the security model and the tradeoffs between security and performance. PNaCL was in browsers but not "web" for this reason. Like the assembly part means low-level and meant as a compilation target, not CPU instructions. So websssembly is an assembly language for the web, like webgl is opengl for the web and webgpu are gpu APIs for the web. And behold none of those can access DOM APIs
  - flohofwoe 6mo ago
    > So webassembly is an assembly language for the web. But is isn't, at most WAT is (the WASM text format). WASM itself is a bytecode format. Nobody calls CPU machine code 'assembly' (nitpicking, I know, but the 'web' part of the name makes a lot more sense than the 'assembly' part).
laughinghan 6mo ago
You seem to be implying that these goals were optional, but I don’t understand how #2 cross-lang interop could ever have been optional. Isn’t running non-JS languages the entire point of WebAssembly? Given that, do you really think goal #1 non-Web APIs really added much additional delay on top of the delay necessitated by goal #2 anyway?
- flohofwoe 6mo ago
  > but I don’t understand how #2 cross-lang interop could ever have been optional This problem hasn't been solved outside the web either (at least not to the satisfaction of Rust fanboys who expect that they can tunnel their high level stdlib types directly to other languages - while conveniently ignoring that other languages have completely different semantics and very little overlap with the Rust stdlib). At the core, the component model is basically an attempt to tunnel high level types to other languages, but with a strictly Rust-centric view of the world (the selection of 'primitive types' is essentially a random collection of Rust stdlib types).
  - jnbridge 6mo ago
    The cross-language type-mapping problem is where every interop approach eventually runs aground. The component model's challenge is the same one that hit every bridge technology before it: whose type system is "canonical"? .NET's Common Type System was supposed to be the neutral ground for dozens of languages. In practice, it had strong C# biases — try using unsigned integers from VB or F#'s discriminated unions from C#. The CLR "primitive types" were just as much a random collection as the WIT primitives are being described here. The practical lesson from two decades of cross-runtime integration: stop trying to tunnel high-level types. The approaches that survive in production define a minimal shared surface (essentially: scalars, byte buffers, and handles) and let each side do its own marshaling. It's less elegant but it doesn't break every time one side's stdlib evolves. WASM's linear memory model actually gets this right at the low level — the problem is everyone wants the convenience layer on top, and that's where the type-system politics start.
    - 6mo ago

paxcoder 6mo ago

[dead]