Posts like this tend to promote an unrealistic view of Web Components. Or atleast Web Components in the current state. As I'm sure re-iterated many times in the comments a Framework replacement they are not. I've been using them in production (polyfilled to be sure) since 2014 and I think generally the wrong comparison is being made. People still generally need tools to make working with them easier a library/framework of sorts. In fact, I would say Web Components are some of the biggest culprits of Library fracturing. They provide just enough that every would-be library author now has a framework. I can't help but feel it starts from the sentiment presented in this article.
Admittedly I'm guilty as charged of being one of those. But I think it's more interesting where popular libraries have tried to align with Web Components (I'm looking at Vue, Svelte) and now have diverged or would not recommend using them.The reason is simple. Beyond not being wholely up to the task they are primarily DOM oriented. It makes sense but it means silly small things like eager versus lazy evaluation of slots, or lack of declarative Shadow Root, or event retargetting interfering with event delegation gets in the way just enough. I mean libraries have been developing techniques to better interact with the DOM that aren't quite compatible with Web Components. Now obviously we can say "React your synthetic event system should no longer be necessary so get rid of implicit event delegation to be compatible." Or maybe we shouldn't. There are solutions to resolving composed paths for that specific example. And there are lots of different ways to solve similar problems. But it is still something.
I think another thing we don't talk about is their natural overhead. There is a difference between components and Components(TM). What I mean is that components as containers Web Components are adequate. Defined contract of API, encapsulation, modularity. However in a library like React that isn't how or why you use Components. The patterns being used by libraries have just as much to do with performance or mechanical reasons as they do for containerization. Web Components are a much heavier construct than those. Thinking you can use them interchangeably is a big mistake on scaling performance.
All that being said I think Web Components are important and have the potential for a lot of great things. I just think that this sort of argument is so easy to poke holes in that it will never get consensus. Web Components are not the same as those libraries. They can cause just as much fracturing of solutions. And they come with just as many specific tradeoffs. Accepting that is where the real conversation starts.
To say it in a shorter way:
"IT is hard" and yes it is!
But I rather work together with the people on one goal then everybody supporting just there team.
But that's just my opinion :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.