No. Chrome is just an app. One that happens to host the most amazing living/alive medium mankind has created.

The page is all you need. A web site can be a canvas where everything can come together. And it can pull in other sites and capabilities.

We do need some new APIs for the web platform to flourish fully. Some small local host services might fill in. Or yes we could indeed enhance the browser. But the idea is that it's the page not the browser creating the experience. The page is the hypermedium.

Honestly, web platform is an ugly example of bad engineering, lot of legacy, weird choices, lots of privacy leaks, dangerous crossdomain requests enabled by default, etc. Instead of adding new APIs it would be better to freeze it and design a better platform.

I welcome the competition but literally no one is even starting to try. HTML is a million times more real as a good open standard for computing than anything else.

I don't even disagree per se, i just think the grumbling is mostly irrelevant to how incredibly potent excellent & interconnected what we have is. And I think the grissly grim outlooks all ignore the incredible vectors of progress that have been lifting lifting lifting things so much higher for so long & show no signs of abating.

Letting the perfectionist neediness get in the way of seeing how amazing & competent & remarkable an ecosystem is is unfortunate.

It’s almost like the way people talk about C++. Modern C++ has many of the features and ergonomics that people evangelize Rust for in a more mature format, but the majority of C++ code people encounter isn’t modern.

It's actually not hard to carve out a subset of HTML you want, define a protocol you want to use over the existing implementation [0], then go back and implement that without the web at some later date if it's popular. If it isn't popular, well, it runs on the web. But doing things this way would indicate that you know what you want to get out of the redesign, which in a lot of cases, I don't think programmers do. They just know that the way it is isn't how they want it, or the thing they want to address is that the browser isn't quite the entire OS yet and it would be nice if it were just a little bit bigger.

[0] https://prog21.dadgum.com/66.html

This is exactly how Flutter started actually, they started with a subset of HTML initially.

Sure there's competition, lots of WASM based alternatives are starting to crop up, like Bazel, Rust's GUI frameworks, Flutter, etc. I welcome those for applications more than what we have with HTML, CSS and JS now.

Replacements to HTML for GUIs tend to have terrible accessibility. I'm sure that will eventually be solved, but pure HTML solutions work right out of the box. They also do better at adapting to different display sizes.

I don't need a screen reader, but I do use Vimium, and I always hate finding an app that I can't navigate with the keyboard (usually because of abuse of JavaScript, but sometimes because they're just rendering a canvas). I don't look forward to that continuing.

How is accessibility done for mobile apps? I assume it's the same way it'd be done for WASM, it's not done simply because WASM GUI apps aren't widely used but once they are, accessibility will be developed, just as it was for HTML.

None of these are competing with what html is, but which is an open standard for rendering stuff.

Oh sure there are hundreds of modern new graphics libraries. Not a one of them is trying to be a language independent medium. None of these could ever be regarded as an internet protocol.

Not sure what you mean, WASM is a language independent medium. HTML is not an internet protocol, that would be something like HTTP, TCP or UDP. Even with HTTP, you can send any data you want, not just hypertext, which is how WASM is sent over the wire.