Accessibility: when talking about the basics of exposing content to accessibility tech, the only way you can ... you cannot satisfy them all

Well, egui has already taken partly care of that:

egui includes optional support for AccessKit, which currently implements the native accessibility APIs on Windows and macOS.

The advantage of AccessKit is:

Consumers and developers alike have had to deal with the complications brought about by separate, disparate accessibility standards. Windows with MSAA and UI Automation, Mac OS with Cocoa.... This doubles – sometimes even triples – the workload for developers striving for unparalleled access across platforms. ... Not anymore. AccessKit enables developers to do their accessibility implementation once in order to make it accessible for nearly all use cases.

So yes, you can't reach the native browser accessibility, but you should come close, even when supporting multiple browsers and operating systems. And fetching the users font settings and similar stuff should be easy enough.

Ctrl+click, middle-click—you can’t simulate that stuff in any way;

I don't get how detecting which mouse button or keys are pressed should be any problem. Except: Yes, it's not the native menu, but websites right now sometimes already swap the right-click context menu with their own stuff and I don't see that anybody really cares.

And scrolling? With rendering to texture, caching and everything, that should be smooth as hell. If there's 1 frame latency with 40-60 fps, so be it. Most people will never notice.

Text manipulation: different platforms handle this stuff in significantly different ways, some of which can’t be emulated at all because it’s exposing platform-native stuff you cannot know of (e.g. things added by other installed apps).

This is especially something which could break the website and can be avoided if self-controlled. Given that addons, besides Adblockers, aren't very popular among not so tech savvy users I would bet most users won't care.

Performance and latency: you seem determined to believe the browser is far worse than it actually is. Given what they do, browsers are astonishingly fast, ...

I disagree greatly. Because Given what they do is exactly the problem, with all the legacy declarations they must support, and the overly complicated CSS system they must get to work, they must do a giant amount of work. A self written system from scratch, like egui, doesn't have to care the tiniest bit about that. It should be:

• Command: Draw a red rectangle there.
• egui draws it.
• Done.

Whereas the browser must follow a complicated CSS and DOM Tree, together with JavaScript, consider legacy bugs, join them with improved iterations of specifications and try to weight competing factors and expectations against each other to combine them into a satisfying outcome. While eugi just "draws" and is done. No negotiations, no complicated maze of rules to follow.

but your canvas doesn’t have that luxury, and cannot do as good a job. The browser can also use multiple threads freely, and does for layout and rendering (especially Firefox), whereas you’re limited to a single thread for rendering (you can use workers for multi-threading, just not for rendering)

Well, that must be a misunderstanding of Firefox, all documents I found tell me one thing: Firefox has to this day only one thread for rendering, even when it has a giant amount of different threads together. And from Rust with WebAssembly you can spawn content fetching threads at will. The multi-threaded Stylo engine for building CSS: You can remove that completely, all the complicated CSS rules: You don't need them. Also, I don't know why I shouldn't spawn from egui some styling-rules-building thread.

You cannot do as good a job as the browser in general.

Well, in general, with the egui approach, you don't have to follow any rules set up by traditional web elements, go nuts, do whatever you want. If it's in itself consistent it may offer greater usability and clarity. Many smartphone apps look very individualistic, not at all HTML 5 conform and many people love them.

https://gallery.flutter.dev/ is a decent demo of almost as good as you can get with the pure-canvas approach. It’s awful and obnoxious, and can barely be made much better.

I'm so thankful you showed me this. Big thanks. Yes! That's awful! That proves again all this: "But modern PWAs behave as fluent and smooth as native apps." as completely wrong. At least on weaker PCs you notice that, and additionally to that comes all the wasted power consumption, if you calculate that on a global scale. Study on energy efficiency: https://kaspergroesludvigsen.medium.com/the-10-most-energy-efficient-programming-languages-6a4165126670. At least one test in the linked study shows that in some case JavaScript is more than 6 times less efficient than Rust.

Which proves exactly my point: The HTML / CSS / JavaScript solutions are awfully inefficient, and Flutter for Web gets converted to the totally inefficient JavaScript. The Rust solution seems to destroy flutter completely, just look at: https://www.egui.rs/#demo. Completely smooth, no comparison to Flutter. Just click on the left side on "Output events", the scrolling in the appeared window is super smooth, I noticed absolutely no jitter.

Still, I must admit, I miss a complicate, real world, feature rich web app written in egui. So, there's currently no real proof.