Agree with this 100%. It's called Web Components since it's best used for writing individual components that be dropped into larger apps. I did a side project with LitElement recently, and just could not find the value add over React. That's when I realized that was never the intention anyways.
I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites, i.e. no server HTML generation. So if I'm building a shopping app, I would never create an HTML file with the following with proper declarative HTML:
Then, you can add interactivity with JS events or a JS framework. Instead, you'll just see:
<shop-app></shop-app>
where the data to render the child elements is dependent on an AJAX request that gets the initial data. Creating standalone, declarative, and well-scoped components is just not necessary in this case, since everything is done in JS anyways.
My thoughts exactly. For some reason people tend to think that a web component should stand on its own from high level. But that's just not how HTML works. Something like <shop-app></shop-app> should be seen as an anti-pattern IMO.
I see web components as a compositional approach for dealing with complexity.
Something else that is extremely powerful that people seem to forget is that you can add a src attribute to your web component that links to JSON data, or HTML fragements on a server. It can give you a lot of caching and concurrency opportunities, browser engines are extremely efficient dealing with this. For most people an src attribute feels really obvious for an img tag, but apparently less so in other contexts.
In what way does <shop-app> not deal with complexity through composition? It is a component, composed of other components, which in turn are composed of further components.
At what arbitrary level of complexity should we stop composing?
At the level where the overhead from it exceeds the benefits of componentizing. It's a subjective judgment, sure, but that doesn't make it any less real.
In particular, if something is never going to be re-used, what's the point of componentizing it?
I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites, i.e. no server HTML generation. So if I'm building a shopping app, I would never create an HTML file with the following with proper declarative HTML:
<shop-app> <shop-item name="Nike Air Force 1" price="85" currency="dollars"></shop-item> <shop-item name="Nike Lebron 18" price="130" currency="dollars"></shop-item> <shop-item name="Nike Kobe 8" price="145" currency="dollars"></shop-item> </shop-app>
Then, you can add interactivity with JS events or a JS framework. Instead, you'll just see:
<shop-app></shop-app>
where the data to render the child elements is dependent on an AJAX request that gets the initial data. Creating standalone, declarative, and well-scoped components is just not necessary in this case, since everything is done in JS anyways.