6 ms·

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebID

This (appears as though it) all could have happened half a decade ago had the interface-types people not abandoned[1,2] their initial problem statement of WebIDL support in WebAssembly in favour of building Yet Another IDL while declaring[3] the lack of DOM access a non-issue. (I understand the market realities that led to this, I think. This wasn’t a whim or pure NIH. Yet I still cannot help but lament the lost time.) Better late than never I guess. [1] https://github.com/WebAssembly/interface-types/commit/f8ba0d044e7846c29b7f05c73acaf5251a47a83d https://github.com/WebAssembly/interface-types/commit/f8ba0d... [2] https://wingolog.org/archives/2023/10/19/requiem-for-a-stringref https://wingolog.org/archives/2023/10/19/requiem-for-a-strin... [3] https://queue.acm.org/detail.cfm?id=3746174 https://queue.acm.org/detail.cfm?id=3746174

eqrion 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 7mo 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 8mo 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
- paxcoder 8mo ago
  [dead]
davexunit 8mo ago
I really want stringref to make a comeback.
- spankalee 8mo ago
  My god yes. I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.
  - davexunit 8mo ago
    Yeah it's really frustrating and JS string builtins are not a good fit for me as I do not want to deal with 16-bit code units.
  - dfabulich 8mo ago
    Who killed stringref and why?
    - davexunit 8mo ago
      It couldn't get past a vote in the Wasm community group to advance from phase 1 to phase 2. Here's a quote from the "requiem for stringref" article mentioned above: > 1. WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). > 2. The requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings.
  - wffurr 8mo ago
    Can you use WTF-16 for strings in your language?
    - spankalee 8mo ago
      I have a compiler flag to switch from wtf-8 and wtf-16 so if you compiler for your host you don't have to reencode strings. That means that strings in my language hide their byte representation, don't allow indexed access, and only have code point iterators.
leptons 8mo ago
I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps. Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions, so that developers are forced to make a native app where Apple can then charge the developers (and thus the users) for a cut of any sales made through the app. It's one reason the DOJ started suing Apple, but I fear that may have been sidelined due to politics. https://www.justice.gov/archives/opa/media/1344546/dl?inline https://www.justice.gov/archives/opa/media/1344546/dl?inline
- neonstatic 8mo ago
  I for one am thankful to them for it. I think we need a return to the real native. The JS/Web-slop has gone too far.
  - aacid 8mo ago
    I personally hate that I need to download app from every company for every service they offer. On the other hand I love tje simplicity of opening webpage, do what I want to do there and forget it. Probably 80% of app in my phone are used very rarely, often just once yet they still sit there, getting updates, requesting permissions and sometimes eating battery... good web app can do everything native app can.
    - speefers 8mo ago
      [dead]
    - neonstatic 8mo ago
      > good web app can do everything native app can. I could not disagree more
      - leptons 7mo ago
casey2 8mo ago
The lack of DOM access IS a non issue. Nobody who uses webassembly wants anything to do with the web. The web is a pile of garbage.

eqrion 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 8mo 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 7mo 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 8mo 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
paxcoder 8mo ago
[dead]

davexunit 8mo ago

I really want stringref to make a comeback.

spankalee 8mo ago
My god yes. I'm building a new Wasm GC-based language and I'm trying to make as small as binaries as possible to target use cases like a module-per-UI-component, and strings are the biggest hinderance to that. Both for the code size and the slow JS interop.
- davexunit 8mo ago
  Yeah it's really frustrating and JS string builtins are not a good fit for me as I do not want to deal with 16-bit code units.
- dfabulich 8mo ago
  Who killed stringref and why?
  - davexunit 8mo ago
    It couldn't get past a vote in the Wasm community group to advance from phase 1 to phase 2. Here's a quote from the "requiem for stringref" article mentioned above: > 1. WebAssembly is an instruction set, like AArch64 or x86. Strings are too high-level, and should be built on top, for example with (array i8). > 2. The requirement to support fast WTF-16 code unit access will mean that we are effectively standardizing JavaScript strings.
- wffurr 8mo ago
  Can you use WTF-16 for strings in your language?
  - spankalee 8mo ago
    I have a compiler flag to switch from wtf-8 and wtf-16 so if you compiler for your host you don't have to reencode strings. That means that strings in my language hide their byte representation, don't allow indexed access, and only have code point iterators.

leptons 8mo ago

I have to wonder if Apple will allow any of this to move forward in the W3C standards committee since they've been blocking many things that would make web browsers as capable as native apps. Apple perceives web-based applications as chipping away at their app store (which makes them money), and so they cripple their Safari browser and then force all mobile browsers on iOS to use their browser engine, no exceptions, so that developers are forced to make a native app where Apple can then charge the developers (and thus the users) for a cut of any sales made through the app. It's one reason the DOJ started suing Apple, but I fear that may have been sidelined due to politics. https://www.justice.gov/archives/opa/media/1344546/dl?inline https://www.justice.gov/archives/opa/media/1344546/dl?inline

neonstatic 8mo ago
I for one am thankful to them for it. I think we need a return to the real native. The JS/Web-slop has gone too far.
- aacid 8mo ago
  I personally hate that I need to download app from every company for every service they offer. On the other hand I love tje simplicity of opening webpage, do what I want to do there and forget it. Probably 80% of app in my phone are used very rarely, often just once yet they still sit there, getting updates, requesting permissions and sometimes eating battery... good web app can do everything native app can.
  - speefers 8mo ago
    [dead]
  - neonstatic 8mo ago
    > good web app can do everything native app can. I could not disagree more
    - leptons 7mo ago

casey2 8mo ago

The lack of DOM access IS a non issue. Nobody who uses webassembly wants anything to do with the web. The web is a pile of garbage.