Those that you apparently read but didn't understand.
> the browser is a 30 year effort to do that and has always failed at it
And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work?
> browser implementations of even basic widgets aren't usable
The problem with the basic widgets is not that they are incomplete, but that they are not enough. Almost any attempt to re-build even the built-in widgets sucks and fails in numerous ways. Now Hixie wants to remove event that and pretend that building all that from scratch is "easier for developers".
> that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>
Here's what that PM said, verbatim:
--- start quote ---
No one needed <section> and <aside> they needed <tabs> and <accordion>
Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.
--- end quote ---
How you read this as "give up on HTML tags" and "refocus on obscure features" is beyond me.
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).
--- end quote
But sure, "give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy". Making the platform be only extreme primitives will definitely not make framework authors happy.
You didn't solve the problems devs find challenging. Frameworks do. The existence of frameworks on the web is a feature, not a bug. Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic.
We're shipping container queries, scope, nesting, style queries, state queries and a host of other features devs tell us they need to architect component systems
In other words, the Chrome team (today) assumes the use of frameworks as a given and sees their job as empowering frameworks. Note that "devs" here clearly refers to framework authors, the sort of people who architect component systems. She doesn't mean app devs.
So HTML as an all-inclusive app framework is going to die, arguably has already died, and the argument between Hixie and stubbornella is just an argument about what specific way to empower framework authors. Hixie argues that the focus should be on features for big frameworks that skip HTML entirely, stubbornella argues for features for smaller frameworks that still use some HTML, but they're both in agreement that raw HTML is just kind of useless and not the way devs want to go anymore. After all "state queries" is not <tabs> either. There's less between these positions that may seem.
Now the real question is not could browsers theoretically ship really great HTML widgets. Sure, there's no rocket science in GUIs, in theory, browsers could do this. Yet after 30 years of immense effort they don't do so. That suggests some deeper structural issue. It might be team scalability issue. Chrome has a truly enormous team, but clearly they're struggling to do everything people might want from a browser. All that code has to be maintained after all, so as Chrome gets bigger we should expect them to slow down. Since the death of plugins the web is a completely monolithic platform. Given a choice between implementing some API that only a browser developer can do (e.g. WebUSB) or implementing an API that devs can hack up their own alternative to (a widget), it's clear why they always choose the former. Anything that browser makers can push off to web developers they clearly will, because there's so much to do that can't be pushed off in that way. Hence why HTML is still a poor UI toolkit and why JS frameworks are so widely used. It's a division of labor issue.
Those that you apparently read but didn't understand.
> the browser is a 30 year effort to do that and has always failed at it
And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work?
> browser implementations of even basic widgets aren't usable
Great article on the topic: "You can't capture the nuance of my form fields https://drewdevault.com/2021/06/27/You-cant-capture-the-nuan..."
The problem with the basic widgets is not that they are incomplete, but that they are not enough. Almost any attempt to re-build even the built-in widgets sucks and fails in numerous ways. Now Hixie wants to remove event that and pretend that building all that from scratch is "easier for developers".
> that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like <section> and <progress>
Here's what that PM said, verbatim:
--- start quote ---
No one needed <section> and <aside> they needed <tabs> and <accordion>
Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.
--- end quote ---
How you read this as "give up on HTML tags" and "refocus on obscure features" is beyond me.
BTW, here's what Dan Abramov, on of the key developers of React, had to say a while back: https://dev.to/dan_abramov/comment/6kh1
--- start quote ---
React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).
--- end quote
But sure, "give up on HTML tags like <section> and <progress>, refocus on obscure features that make framework devs happy". Making the platform be only extreme primitives will definitely not make framework authors happy.