So for example, some of the HTML in the "template:" section of a VueJS component would be tags which are defined by web components...
A framework component is effectively a reusable block of code. It's an organizational principle more than anything; modular and reusable, but not meaningful to the browser in its own right once rendered. A web component, on the other hand, is very literally a new HTML element, and is treated by the browser as such. Once defined, the browser itself sees that component as a meaningful entity in its own right.
While the difference between those two ideas is fairly subtle on the surface, there's a whole nest of smaller differences that result from it. For just one example, web components are perfectly AJAX-compatible with no extra strings attached - you simply add the HTML tag representing a component to the DOM, and it works out of the box, no matter when or from where you got it. Achieving that with a framework component requires some additional work at best, which may or may not have been done for you by the framework authors.
That's not to say one is necessarily better than the other either, to be clear - they're just different, and treating them as if they were the same does both a disservice.
I think that, for me as a newcomer to front-end development, this is the biggest takeaway: a framework component is a reusable block of javascript while a webcomponent is a reusable HTML element.
As a newcomer[1] it does not make sense to even learn the front-end frameworks. As an example, the time spent in learning the entire framework simply so I can 'watch' an element's value for changes, or propagate an element's changed value to other elements is going to be order of magnitudes greater than simply writing 3 custom elements that monitor and propagate values for any child element.
(PS. I like your post. I think a followup blog post with two concrete examples may make sense in refining your thesis:
Example 1. This is a popular React mechanism to do $FOO, here's how it is easier in a webcomponent.
Example 2. This is a complex webcomponent, here's how it is easier in React.)
[1] One who is not looking to put "react", "vue", etc on their CV.
I feel like you're underestimating how easy this is to skrew up.
However, it's far far easier for a newcomer to screw up when approaching react or cue than when approaching a custom html element.
Time will tell as I use my experiment in more domains, more often and in larger apps.
For the reactivity stuff, you might want to read https://frontendmasters.com/blog/vanilla-javascript-reactivi... - it shows a bunch of no-library-required patterns that, while in a number of cases I'd much rather use a library myself, all seems at least -basically- reasonable to me and will probably be far more comprehensible to you than whatever I'd reach for, and frameworks are always much more pleasant to approach after you've already done a bunch of stuff by banging rocks together first.
Web components/custom elements are reusable behaviours/functions - which can contain custom js, all bundled as a reusable HTML element.
Think of it a bit like an object in an object orientated programming language - the object has both data/state (DOM) and code/functions to manipulate that state.
So is a web component…
To me there is a larg distinction but I do concede that to others there may be no difference.
If you're writing them, certainly.
For web designers, using Web Components means not having to know JS, not having to know React, not having to know hooks, not having to know usememo, etc.
That's, to my mind, a large enough distinction: the requisite knowlege to reuse a framwork's components needs a full time developer. The knowledge required to reuse a web component is ... HTML (and maybe CSS?)
I think if you are new to webcomponents[1] it might help if you list all the useful functionality you get from a front-end framework, and look up how to achieve the same thing using webcomponents (Custom element, templates, slots).
[1] As I am. I am, in fact, new to front-end in general.