[chrismorgan]

And that concept was bonkers, proof conclusive that he had lost the plot—if his involvement with and endorsement of canvas-only Flutter wasn’t proof enough—and should be ignored completely until he comes to his senses.

The obvious benchmark would be: can you implement an HTML/CSS/JS browser inside this environment and have it behave identically to the browser’s own HTML/CSS/JS? And the answer is: not a chance. WASM + WebGPU + ARIA + WebHID is simply not enough. Browsers provide a lot of functionality in ways that web content cannot see or interact with. Some of it could be mapped, other parts of it never can be, for security/privacy reasons. And the more you want to map, the bigger your spec gets, until you’ve added every diverse feature from every OS to the web’s API surface—and then you stop browsers from adding new functionality, too.

Some examples of things that can’t be implemented in web content (most fundamentally, one or two merely currently): Native text rendering in this WebGPU world. Links with all their functionality. Native font preferences. Text selection and its interactions with native platform functionality (including things like context menus). Native scrolling behaviour. The browser as a compositor (important for things like scrolling and video performance). Browser extensions (the user agency part of that first scathing comment).

[Hixie]

The things you list that couldn't be implemented in such an environment are a mix of two things, first, things that browsers are specifically designed to _prevent_ a web page from doing, e.g. to avoid leaking privacy, and second, things that absolutely should be possible in that environment, because if they're not, then the environment isn't yet complete.

But in practice I don't think either is especially critical. You can already do pretty much what I suggested just by running the Wasm code against WebGL in a stub HTML page; it hasn't stopped people from creating such things (e.g. Google Docs, Figma, Flutter, etc). The core thing I proposed was allowing the inversion of the architecture so that the Wasm code could be a top-level resource the same way text/html and application/pdf are today. Sure, it could be improved in time by allowing some of the things you list, but that doesn't mean it wouldn't be useful today. The perfect is the enemy of the good, and all that.

[chrismorgan]

Your concept is an extension of what I call the pure-canvas approach. Less bad than current pure-canvas, but a lot of the problems of pure-canvas will persist.

Google Docs is not pure-canvas. If it were, it would be horrible. As it is, it’s… meh, fine I guess, merely somewhat worse than before it started using canvas at all (incorrect keyboard behaviours, worse performance, terrible latency and jitter, though still not as bad as whatever Microsoft call their version of Word that runs in a web browser).

Figma only uses canvas for its canvas, which pretty obviously should indeed be canvas; all UI is DOM, and it would be much worse if it were not.

In a web browser, Flutter is horrible. I loathe, detest and abominate it with vitriol befitting sulphuric acid.

(I’ve written about all of these before. https://news.ycombinator.com/item?id=42253177 is a fair starting point.)

[Hixie]

I've written about it before too :-) https://news.ycombinator.com/item?id=34622514

[rapnie]

Part of my interest in what you wrote in the link I passed stemmed from my imagination (or fantasy) where I saw opportunities arising to finally step away from the straitjacket of the browser oligopoly, with wasm et al the enabling technology to that. Yes, it would be a lot of work. A lot of things would need to significantly mature to get robust UI development frameworks, and it would be a bit like before the web, alien to many. But right now, things aren't good either, as you also referred to just now.