As I understand it, the original reasons for including some indirection in the production of HTML were: (1) templating - i.e. injecting boilerplate at compile or run time. This would include standard headers, footers, <head> elements, etc.; (2) navigation and tags - both of which are highly laborious to maintain manually, and (3) RSS feeds.
I would be _really_ interested to see someone use modern web platform features like HTML imports, web components, JS modules, or something else to achieve the above features _at run time_ while enabling one to write in nearly pure HTML.
And lose static rendering, all the accessibility and ability for simple parsers to understand and/or store the page. All that comes to mind when web components come up is “what we’re they thinking?”.
Browsers have native, built-in components like <select>, <select multiple>, <input type="button">, <input type="date">, etc. Styling and behavior of those is self-contained, with a public API.
The idea behind web components was to provide a built-in way to build your own self-contained components - something people have been doing for a long time with tons of <div> elements. But it's always been a challenge because doing that well requires adopting some consistent approach (usually through a library) that builds its own mechanisms. And there are many different libraries, and they all have different approaches. Wouldn't it be better to provide a standard mechanism for defining custom components and abstracting their styling/behavior?
Web components and other modern web tech could eliminate the need for libraries like React to build complex web apps with custom controls.
> Web components and other modern web tech could eliminate the need for libraries like React to build complex web apps with custom controls.
But they won't, for the reasons presented here. They solve only the lower half of the problem. They're perfectly fine for building self-contained UI controls/elements, but create a top-level `<BlogArticle>` component to mimic the composability of modern frameworks and you lose all I mentioned above.
> But they won't, for the reasons presented here. They solve only the lower half of the problem.
Right, I wasn't arguing for use of web components for anything like <BlogArticle>. That's way outside their scope. But with web components being available, libraries like React would be optional/redundant when custom components are involved (like in complex web apps).
But I still think it would be fun to see someone hack modern web tech (even web components) to build modern blog features with pure HTML (+ sprinkled JS/CSS, as needed).
> libraries like React would be optional/redundant when custom components are involved (like in complex web apps)
This is where we disagree - this is not true at all. In complex web apps, what you need the most is high-level components such as `<BlogArticle>` that allow you to tame complexity, isolate reusable pieces of UI that might be as large as a page itself, and not just localized elements. As you acknowledge, WC doesn't even aspire to fill this role, meaning you'll still need higher level frameworks on top of them, which significantly diminishes the value of being built-in.
Have you ever tried to build a reusable multi-select combo box? That’s not easy without some framework. Event and state management can become a real headache.
But higher-level items like articles/comments are so much easier without a framework - I just don’t see how React/etc. is necessary given you have a decent templating library and a module loader that has CSS, JSON, and string plugins.
I would be _really_ interested to see someone use modern web platform features like HTML imports, web components, JS modules, or something else to achieve the above features _at run time_ while enabling one to write in nearly pure HTML.