A grouping of form controls and labels that together represent a piece of form data is a field. True, HTML doesn't have any exact `field` tag, but the notion of a field has always been there, see `<fieldset>`. Working with custom "fantasy" elements is quite typical of modern frontend development, and very productive to work in.

Nevertheless, in the more restricted question of using custom elements to replace CSS classes, you may have a point; many libraries that try to do this typically end up with a far more restricted use case since a custom components library is less open to extension than CSS classes, and custom components authors often fail to anticipate ways in which CSS frameworks are used. (e.g. using a CSS class with a standard HTML tag, and then, using a CSS class with a custom component)

That's the million dollar question.

What's the alternative to declaring our UI using pseudo-html elements and string-matching on css class proxies from the currently-in-favour CSS framework which sits on top of the javascript framework of the moment which, after going through several transpilation steps to become plain old javascript, then sits on the client manipulating a shadow-DOM, to finally render plain old html?

No idea. Hopefully some nice solutions will arise from other languages which compile to wasm - I would expect all the major players to be looking at coming up with something to that effect now that the world seems ready for Silverlight 2.0 and everyone loves writing frameworks.[1]

Until then, any solution will unfortunately probably involve adding yet another level to the house of cards, maybe one which compiles down to buefy or the Vue bootstrap components..

[1] yeah, I see the irony in that it's just another stack which will probably be just as insane in many ways, but at least it will compile in less than 5mins.