I'm looking forward to your next post on this topic. It's interesting but I'm not sure I fully share your view. But I'm not going to comment on the technical parts of the whole Web Components VS Framework debate as I believe others have done it better (Rich Harris for example, in dev.to/richharris/why-i-don-t-use-... and in the surrounding discussions on Twitter).
Though I believe that some parts of your reasoning feels a bit fragile. Like "[...] if you are really honest to yourself, then you would probably still be happy with class-based components". I think this is a naive and potentially hurtful way of reasoning that limits progress and technological advancement. Imagine someone saying "if we didn't invent the wheel we'd still probably be happy to carry all the stuff around on our own". Yes, if we are not aware of, or chose to ignore, alternative ways then sure, we'll be happy with what we currently have. Because we don't know of any other alternatives and we don't aim to improve the current process. I don't see how this argument adds any value to the debate.
Concerning hooks specifically, the marketing (from actual React maintainers) has never been "Hooks are extremely superior, you should rewrite all your class components NOW". Some members of the community have maybe tried to convey that message, but I really don't think that "we have been tricked by marketing". Can you point me toward some of the marketing you're thinking if? If it's mainly community created posts and opinions I instead wonder how you classify marketing in this case? Reading the official adoptation strategy FAQ (reactjs.org/docs/hooks-faq.html#ad...) I think it makes it pretty clear that they don't expect anyone to rewrite or scrap all their old class based components. Sure, they encourage us to try the hooks API, but I don't consider the marketing very problematic, authoritative or controlling. I think the difference between official marketing and community opinions from individual users should be made clear.
You're also discussing the risk of having too many front end frameworks to choose between and how it paralyzes people. Is that really the case when it comes to general UI frameworks though? React has been around for 6 years with very few breaking changes. Vue.js has been around for 5 years with very few breaking changes. Angular has been around for a very long time, unfortunately can't say the same about few breaking changes here though.. :P
Do you find this enough to impose "overchoice" and paralysis? I don't personally think so. Sure, there are lots of other frameworks and libraries in the JS ecosystem, but you seem to be mainly talking about more general UI frameworks here. If we're talking about JS libs in general the reasoning also applies to a development process focusing on Web Components. And if you think we need to consider all smaller frameworks as well, than I'd say that the situation in the JS ecosystem isn't very different from other languages. If wide adoptation is of no importance then you'll be able to find quite many obscure little libraries and frameworks in the .NET or Java landscape as well. That could impose paralysis if you choose to not only consider the main, widely adopted, alternatives.
UPDATE: I see you've clarified that you're "not against frameworks! I'm against everybody doing its own thing!". I partially agree with you about that, but with some of the thecnical inconveniences of Web Components I'm not sure I believe it's the best option. And if you're fine with using a Framework on top of WCs, than I believe everybody will still be able to "do their own things"? :)
Ah okay, I think I got a little misguided by the post's title them. So you're meaning kind of like Svelte 3 is already doing? (although with an optional compiler flag) My understanding is that the current WC spec is challenging to work with to achieve some patterns and features that are considered needed or very useful in frameworks. Which is why it might make more sense from a framework perspective to only optionally target WCs in order to fully support some features without a lot of extra hassle and workarounds.
One problem area that comes to my mind is the Web Components total inability to handle SVG content conveniently due to elements needing to exist in the html namespace
I'm looking forward to your next post on this topic. It's interesting but I'm not sure I fully share your view. But I'm not going to comment on the technical parts of the whole Web Components VS Framework debate as I believe others have done it better (Rich Harris for example, in dev.to/richharris/why-i-don-t-use-... and in the surrounding discussions on Twitter).
Though I believe that some parts of your reasoning feels a bit fragile. Like "[...] if you are really honest to yourself, then you would probably still be happy with class-based components". I think this is a naive and potentially hurtful way of reasoning that limits progress and technological advancement. Imagine someone saying "if we didn't invent the wheel we'd still probably be happy to carry all the stuff around on our own". Yes, if we are not aware of, or chose to ignore, alternative ways then sure, we'll be happy with what we currently have. Because we don't know of any other alternatives and we don't aim to improve the current process. I don't see how this argument adds any value to the debate.
Concerning hooks specifically, the marketing (from actual React maintainers) has never been "Hooks are extremely superior, you should rewrite all your class components NOW". Some members of the community have maybe tried to convey that message, but I really don't think that "we have been tricked by marketing". Can you point me toward some of the marketing you're thinking if? If it's mainly community created posts and opinions I instead wonder how you classify marketing in this case? Reading the official adoptation strategy FAQ (reactjs.org/docs/hooks-faq.html#ad...) I think it makes it pretty clear that they don't expect anyone to rewrite or scrap all their old class based components. Sure, they encourage us to try the hooks API, but I don't consider the marketing very problematic, authoritative or controlling. I think the difference between official marketing and community opinions from individual users should be made clear.
You're also discussing the risk of having too many front end frameworks to choose between and how it paralyzes people. Is that really the case when it comes to general UI frameworks though? React has been around for 6 years with very few breaking changes. Vue.js has been around for 5 years with very few breaking changes. Angular has been around for a very long time, unfortunately can't say the same about few breaking changes here though.. :P
Do you find this enough to impose "overchoice" and paralysis? I don't personally think so. Sure, there are lots of other frameworks and libraries in the JS ecosystem, but you seem to be mainly talking about more general UI frameworks here. If we're talking about JS libs in general the reasoning also applies to a development process focusing on Web Components. And if you think we need to consider all smaller frameworks as well, than I'd say that the situation in the JS ecosystem isn't very different from other languages. If wide adoptation is of no importance then you'll be able to find quite many obscure little libraries and frameworks in the .NET or Java landscape as well. That could impose paralysis if you choose to not only consider the main, widely adopted, alternatives.
UPDATE: I see you've clarified that you're "not against frameworks! I'm against everybody doing its own thing!". I partially agree with you about that, but with some of the thecnical inconveniences of Web Components I'm not sure I believe it's the best option. And if you're fine with using a Framework on top of WCs, than I believe everybody will still be able to "do their own things"? :)
I don't have anything against frameworks.
What I want from these frameworks is to target web components.
Everybody is still free to do what they want!
Ah okay, I think I got a little misguided by the post's title them. So you're meaning kind of like Svelte 3 is already doing? (although with an optional compiler flag) My understanding is that the current WC spec is challenging to work with to achieve some patterns and features that are considered needed or very useful in frameworks. Which is why it might make more sense from a framework perspective to only optionally target WCs in order to fully support some features without a lot of extra hassle and workarounds.
One problem area that comes to my mind is the Web Components total inability to handle SVG content conveniently due to elements needing to exist in the html namespace
The moment I can turn my reactjs component into a web component I would be happy!
SVG in general are kind of challenging but that's IT in general
Check out direflow.io/. It packages a React component in a Web Component 📦 and it provides the glue between attributes and props.