Hacker News Reader

Comment by mananaysiempre | Hacker News Reader

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/f8ba0d...

[2] https://wingolog.org/archives/2023/10/19/requiem-for-a-strin...

[3] https://queue.acm.org/detail.cfm?id=3746174

View on HN

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.

> 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.)

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?

> 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).

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.

Except you are missing the part that CLR has a type system designed specifically for cross language interop, and is taken into account on the design of WinRT as well.

Common Language Specification - https://simple.wikipedia.org/wiki/Common_Language_Specificat...

> The CLS was designed to be large enough to include the language constructs that are commonly needed by developers, yet small enough that most languages are able to support it. Any language construct that makes it impossible to quickly confirm the type safety of code was excluded from the CLS so that all languages that can work with CLS can produce verifiable code if they choose to do so.

WinRT Type System - https://learn.microsoft.com/en-us/uwp/winrt-cref/winrt-type-...

The WIT types don’t seem random or Rust-centric to me, they’re basic types common to every major current-generation language, not just Rust but also Swift, Kotlin, even Zig. It’s true that languages with type designs from the 90s can’t take full advantage of WIT types, but WIT does seem perfectly capable of representing types from older languages, which seems like the only possible sensible design to me—older languages are supported, but that support needn’t burden interop between modern languages.

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!

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

> 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).

At least the 'web' part makes more sense than the 'assembly' part ;)

WASM was designed as a successor to asm.js, and asm.js was purely a web thing. While non-web-platforms were considered as a potential use case (in the sense of "using WASM outside the web should be possible", it wasn't clear at the time what the successful usages outside browsers would even look like).

Web assembly has never had anything to do with the web.

At least that's been my experience whenever I find it in production.

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.

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.

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.

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

This is a nice conspiracy theory but doesn't match facts like Safari implementing the WebGPU standard at a faster pace than Firefox. Safari might not be great in some areas, but their WASM/WebGPU/WebAudio support is in pretty good shape.

Push Notifications, Web Bluetooth, Web NFC, User Idle Detection, the list goes on and on. Not even counting the hundreds of #wontfix bugs in their css engine. Its not a conspiracy theory if you recognize their incentives and consistent anti-consumer behavior for fucking decades.

That is not Web, that is ChromeOS Platform, incredible how people complain about Google's taking over the Web, while pushing Electron crap and their Chrome APIs.

> Web Bluetooth, Web NFC

These are things that literally everyone but Google thinks are terrible ideas.

Why don't you flip the conspiracy around and ask yourself why Google, the world's largest advertising agency and data hoover, wants browsers, a category dominated by Google, to have unmediated access to ever more user, system, and local network data?

That's nonsense. There's plenty of people that want those APIs that don't work at Google. And it does not give Google "unmediated access" - you have to explicitly opt-in to allow the browser to use them when a website requests access to these APIs. But of course, don't let the facts get in the way of your fanboyism for Apple.

And when it's normalised for firmware updates to happen via WebHID and WebUSB? Saying no will seem as fringe as browsing the web with NoScript. It's already the main way to upgrade keyboard firmware for a lot of mechanical keyboards, and it only works on Chrome. Thrilling developments for Google.

>> But of course, don't let the facts get in the way of your fanboyism for Apple.

Mate, I didn't even mention Apple. You're the one with the fixation here. Mozilla/Firefox is also deeply opposed to these anti-features.

>Mozilla/Firefox is also deeply opposed to these anti-features.

Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does.

If Apple weren't total assholes and didn't forbid Chrome from actually being Chrome on iOS, then I wouldn't care, I'd simply tell users to install Chrome. But Apple forces all browsers on iOS to use Safari, which they have intentionally crippled and refuse to let other browsers use their own engine.

If you don't think that's abusive business practices and deserves the DOJ lawsuit, then you're just another Apple shill.

>> Mozilla is irrelevant, and they don't have a hardware platform where they forbid all other browser engines from it like Apple does.

>> If Apple weren't total assholes

>> Apple forces all browsers on iOS to use Safari

>> you're just another Apple shill.

I've still not even mentioned Apple once.

You seem extremely fixated on Apple.

I'm not aware of any major corporation, group, standards body, or OSS project that would agree with Google's attempts to extend the browser so deeply beyond the web. The general consensus is that it is deeply reckless.

Google failed to get stuff like WebHID into the standard - because everyone thinks it's a terrible idea - so they've just rolled it out on their own anyway, using their browser monopoly to force facts on the ground. Facts favourable to Google, unsurprisingly.

When Microsoft did this sort of thing, we used to call them out on it. I have no idea why you seem so adamant to defend this. I can only suspect that you've let yourself become completely partisan in some grand Google-Apple war that you've imagined, which is why you keep bringing up Apple out of nowhere?

You are missing the initial point here, the accusation is that apple doesn't want the web as a viable platform to develop fully fledged cross platform applications that circumvent its own moat. You just repeat the maximalist position that the web shouldn't "extend the browser so deeply beyond the web". Many people disagree with that, its the best shot we have for true cross platform applications that would force Apple to open their platform, we say the reason apple doesn't want that is for purely profit driven reasons.

Also doesn't this argument apply to WebAssembly and other standards (like WebGPU) as well? Why should I be able to render a video game in the browser but have no way to manage input devices (like multiple controllers) to make it a suitable platform for fully-fledged video games in the future? Like I understand why Apple (OR Microsoft for that matter) doesn't want Stadia-like services to suddenly run on all their devices without any cut in monetization, so naturally they sabotage such efforts in Safari...

Like here is my own reason to support that effort: I use Linux, and there are a ton of proprietary applications that if there were developed on the web platform would become accessible to me.

I understand the privacy concerns with some of those APIs, but the argument isn't that the user shouldn't have agency over those features, do you see how that's a separate conversation?

So now: Why are you against it?

> Many people disagree with that, its the best shot we have for true cross platform applications that would force Apple to open their platform, we say the reason apple doesn't want that is for purely profit driven reasons.

And equally, Google wants their platform to replace OSes for purely profit-driven reasons of their own. I'm not saying this as some terrible indictment. They're all corporations, I don't expect anything else from them.

> Also doesn't this argument apply to WebAssembly and other standards (like WebGPU) as well?

This is a fairly consistent strain of criticism on WASM posts here on HN. The death of software as we know it; all of computing as a service, forever.

> Like here is my own reason to support that effort: I use Linux, and there are a ton of proprietary applications that if there were developed on the web platform would become accessible to me.

What makes you think future thin-client 'PC's will even be able to run anything other than a browser shell? The current requirements for Windows/iPhone/Android will just be replaced by a requirement to run an approved, TPM-clad Chromebook, cryptographically certified to be running no software other than Chrome. The ultimate in Secure Boot. But of course this will provide no actual security to end users, in a world where websites can write to your keyboard firmware. Security for corporate IP, maybe.

I genuinely think you're letting your dislike of Apple - on which I hear you, Apple's no angel - cloud your judgment here. The future Google's building is pretty dark.

But it feels like a slippery slope argument to me, like how do you go so quickly from standardized web APIs to your ChromeOS/TCPA dystopia? I think that's quite the leap to make, especially considering we already have those locked tight ecosystems right now with iOS, Android, Windows, Mac OS to varying levels of degree anyway. If proprietary applications go that route they would remain unaccessible to me, it wouldn't really change anything. But right now I can use things like figma and countless other apps because it runs on the web, it would otherwise never have been possible.

> in a world where websites can write to your keyboard firmware

again I would never relinquish control over the decision if it "can", I've been using Linux for 20+ years I already go to significant lengths to remain in control over my computing. But the fact that I can develop a cross-platform app that talks to some USB device directly via some standard web API, has benefits that outweigh the costs, that's just pragmatism.

Also if you asked me I would personally rather see Apple, Google, Microsoft and every other orphan crushing machine/publicly traded company shut down and all it's CEOs and shareholders hanging from street lamps, but personal politics aside, I'm only speaking of within the dystopia we already have anyway.

I don't think your stated interest in "remain[ing] in control over [your] computing" is at all compatible with the specific moves in tech that you're advocating for.

There's an obvious long-term trend for software to migrate from on-disk to cloud-based: from everything SaaS, through gaming, to Office suites. One common thread with all this software is that you have absolutely no control over it, which is - of course - the aim. No piracy, no unauthorised mods. Walled gardens forever in every direction.

Equally, there's a simultaneous long-term trend for 'attestation', ID checks, 'digital ID' documents, etc. Already, many bank apps refuse to run on Android devices that aren't Google-blessed and kissed. This trend is only accelerating.

In a world where paying taxes online - or accessing a bank account, or running an office suite - requires a Trusted Device™, what good is OSS? What good is software freedom? Running a Linux computer unable to interact with basic aspects of the modern world will quickly become as quaint as trying to do your day job on an Amiga.

> that would agree with Google's attempts

I never mentioned Google. You seem really fixated on Google for some weird reason.

>The general consensus is that it is deeply reckless.

Bullshit, you made that up in your own head. Show some actual statistics instead of making shit up.

>Google failed to get stuff like WebHID into the standard - because everyone thinks it's a terrible idea

So you think you speak for "everyone"? Because you're also making that up.

>When Microsoft did this sort of thing, we used to call them out on it. I

Oh, like when they came out with XMLHTTPRequest and everyone told them to fuck off? That time? Oh, no, they actually didn't tell them to fuck off with their proprietary API, they also all implemented it in their browsers, and now it runs most of all the web.

> I have no idea why you seem so adamant to defend this.

I already spelled this out for you. Apple forbids any other browser on iOS except their own Safari. If they didn't abusively force Safari on all browsers on iOS, I would not have a problem, I would just tell users to install Chrome. But I can't, because Apple is abusive and here you are acting clueless again about what is actually going on.

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.

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.

> good web app can do everything native app can.

I could not disagree more

Your disagreement only remains valid because of Apple using their blocking power to quash web APIs from becoming standards. You can shill all you want for Apple, but they are being sued by the DOJ for abusive business tactics, which include leveraging their vote in the W3C to prevent web browsers on their platform from being as capable as native apps.

https://www.justice.gov/archives/opa/media/1344546/dl?inline

Sorry, but you are the one obsessed with Apple for some reason and are projecting the opposite of that (shilling) on me. I don't have any particular reason to favor Apple.

I do, however, notice that I have never used a program that was built with either a web stack or a gc language stack, that wasn't getting slower over time, wouldn't cause strange issues, and wouldn't have crippled UI to match whatever the stack's limitations have been at the time. IMO the right direction is developing (or adopting) modern native languages. If the "price" for that is some web standard being stuck, I personally am totally okay with that.

I am sick of this idea that the web browser is almost an OS. It was supposed to serve web pages.

But the app-slop is totally fine right? Apple controlling every piece of software on my phone hasn't gone too far? Empowering the web to compete with Apple and Google's native locked down options is the only viable alternative I see.

Problem, as I see it, is that these "native locked down options" are very often just webpages in disguise, which is also webslop imo

The native locked down options are the natives apps you're advocating for, I don't understand. They're the Swift/uikit or Koltin/jetpack apps. It sounds like you don't like web technology in general and would rather everyone do it the centralized Apple/Google way?

Kotlin is not native. And yes, I don't like web technology. That doesn't imply doing it in Company A / B / C way, it implies preference for compiled programs that run natively in their respective environments with full utilization of resources those environments provide, e.g. hardware access, software standards etc.

Sorry I just saw this, if Kotlin isn't native, then what is the "native" way to write android apps?

I really want stringref to make a comeback.

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.

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.

Who killed stringref and why?

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.

Can you use WTF-16 for strings in your language?

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.

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.

Reply on news.ycombinator.com