I don't think I buy the premises under the goals here.
> The main goal of HTML First is to substantiall widen the pool of people who can work on web software codebases.
Fair goal.
> A second goal of HTML First is to make it more enjoyable and seamless to build web software.
Also a fair goal.
> The way we achieve these goals is by acknowledging that HTML is very easy to understand, and thus using HTML as the bedrock of our product - not only to define content and structure, but also to set styling and behaviours.
It's not. It's a large, heterogeneous collection of behaviors based on the arrangement of various tags with coupling between the tags defined by hundreds upon hundreds of pages of individual tag descriptions. And that's before we even consider that there's a matrix of browser compatibility layered atop that.
If I code up some complex behavior in React (such as the details-summary example here), the result is obvious, shows up in the deubgging tools, and works on every browser that supports React. Most importantly, the knowledge is composable: that approach to showing and hiding content works regardless of the content being a "details" and "summary" or a shopping cart contents pane or a modal dialog. With vanilla HTML, every aspect of the default behavior is dictated by the browser, and very few pieces compose with each other sanely (what happens when I nest <details> tags? I have to try it to find out; if it's a React component, I can read the JavaScript and know).
I'm not saying one shouldn't use vanilla HTML or should only use <div> with style for the whole layout or anything like that; there are semantic concerns that make using HTML where possible a good idea. But I'm not going to trip over myself to memorize every behavior and interaction of the declarative HTML model if it's easier to build things like collapsible details tags in React.
> The main goal of HTML First is to substantiall widen the pool of people who can work on web software codebases.
Fair goal.
> A second goal of HTML First is to make it more enjoyable and seamless to build web software.
Also a fair goal.
> The way we achieve these goals is by acknowledging that HTML is very easy to understand, and thus using HTML as the bedrock of our product - not only to define content and structure, but also to set styling and behaviours.
It's not. It's a large, heterogeneous collection of behaviors based on the arrangement of various tags with coupling between the tags defined by hundreds upon hundreds of pages of individual tag descriptions. And that's before we even consider that there's a matrix of browser compatibility layered atop that.
If I code up some complex behavior in React (such as the details-summary example here), the result is obvious, shows up in the deubgging tools, and works on every browser that supports React. Most importantly, the knowledge is composable: that approach to showing and hiding content works regardless of the content being a "details" and "summary" or a shopping cart contents pane or a modal dialog. With vanilla HTML, every aspect of the default behavior is dictated by the browser, and very few pieces compose with each other sanely (what happens when I nest <details> tags? I have to try it to find out; if it's a React component, I can read the JavaScript and know).
I'm not saying one shouldn't use vanilla HTML or should only use <div> with style for the whole layout or anything like that; there are semantic concerns that make using HTML where possible a good idea. But I'm not going to trip over myself to memorize every behavior and interaction of the declarative HTML model if it's easier to build things like collapsible details tags in React.