The fact that Google has brought Android to ChromeOS and not the other way around, that Fuchsia is based on Flutter and not ChromeOS UI, and all the corpses of Web based OSes all the way back to Web Widgets Runtime on Symbian is quite telling about the performance of web UIs on phone hardware.
As far as Flutter vs ChromeOS UI, I think it makes sense because of how Flutter works and how much success it's seen being used on android/iOS which reflects how much work they put into it. Flutter literally draws every pixel on the screen, and they put their army of engineers to work on rebuilding native interfaces in android[0]/iOS[1] to replicate their interfaces. The amount of control that flutter gives them is probably can't be matched by any existing widget framework, I don't think anyone's actually done something that crazy yet. Fuchsia is their thing, it makes sense for them to re-use the projects that they find offer the best abstraction for them I don't think this is so much a condemnation of web UIs on phone hardware, they also chose not every other widget/display library in existence.
Also I want to point out that rendering and performance of web UIs could be good on phone hardware, the native implementations just have to want that to be the case. I honestly haven't thought about it deeply, but I also haven't seen a compelling case for why android/iOS's specific markup languages naturally render faster than something that was HTML based -- android/iOS just have subsets of the power HTML offers and that's where the savings is.
[EDIT] - I got what you mean about bringing Android-to-ChromeOS, so removed the section asking for clarification
Flutter original team started with former Chrome engineers and one of the first design decisions was to drop the Web UI concepts.
If I am not mistaken it was Timothy Jordan that explained it on an interview.
So Google, the company pushing Web UIs, including PWAs in collaboration with Microsoft, still thinks they aren't worthwhile to be the default stack on their devices.
Apple and Microsoft also have UI stacks where JavaScript has first class support (TVML and UWP) and like Flutter, completely dropped the DOM.
Just because they decided to drop the Web UI concepts do not mean that what they chose was more powerful or the better decision in general -- it suggests it was the right decision for them.
Also, since when was Google "the" company pushing web UIs forward? Mozilla is that company in my mind -- remember the time when they made a whole mobile operating system based on it, and at the same time tried to push forwards for various parts along (WebBluetooth, other APIs)? That's what investing in the web as a platform looks like. Flutter is successful, but not in a way that plays nicely with anything else -- if you want to push a platform forward or encourage growth, doing things that play nicely with others even if they're less convenient for you is the way to go.
I'd love to be enlightened to what you think is the problem with DOM in particular that makes it not the right model -- TVML and UWP dropped the DOM, but basically replaced them with their own walled-garden re-implementations of basically the same concept. A quick look at the documentation for both and pages like collectionList[0] in TVML and the Getting Started page for UWP[1] look just like shitty HTML.
Ultimately, I can see why they would invent their own UI languages, because it means they don't have an external standard to comply with and can move pretty quickly. I think this is the major reason, not that those other markup languages they created are magically better than HTML's standard. Again, I think this is less of an indictment of HTML than it is companies trying to move as fast as they can without care for interop -- great for them, but probably bad for developers who have to learn all their little languages that are re-creations of an established standard.
> Also, since when was Google "the" company pushing web UIs forward?
Since they introduced JIT compilers for JavaScript, keep spending money pushing forward an operating system that is basically a browser juggler and introduced PNaCL.
> I'd love to be enlightened to what you think is the problem with DOM in particular that makes it not the right model
Rendering performance.
The way DOM semantic works is no match for a composition engine designed from the bottom up for accelerated graphics UI.
DOM is for displaying documents not interactive graphics.
This is also the main reason why Flutter team dropped DOM, at they were hitting the border of what was possible while keeping DOM semantics.
Also why Houdini project exists, but it is far from ever reaching the browsers.
>Also I want to point out that rendering and performance of web UIs could be good on phone hardware, the native implementations just have to want that to be the case.
So that raises the question why Google, the king of the web, wouldn't want it.
I noted this in my other response but since when is Google the king of the web and in what way do you mean that?
Mozilla seems to do the most work trying to move the web as a platform forward.
Flutter is a system that would be impossible to create or fund unless you were at google scale, because it's massively wasteful as an idea -- it's literally a complete rendering engine and widget system built from relative scratch. It offers more flexibility than adhering to any other established UI standard, so I'm not surprised it made sense for them -- surely they can move faster with Flutter than they can by trying to support all of HTML.
There is a cost to using established standards and being held accountable to outside forces, Google just chose not to pay that tax here, which is well within their rights.
I think both Google and Mozilla are moving the web forward. But I'm using "king" as a metaphor for power+money.
No one derives more power and money from the web than Google, and therefore they have a vested interest in keeping the web at competitive levels of performance compared to native platforms.
So if neither Google nor Mozilla can make web rendering as fast as Flutter, then I suspect that there is an inherent technical reason for that and not just lack of want.
