Nobody writes production web components in vanilla JS — so using a framework makes total sense
You may hear someone say they avoid using React, Polymer, Angular, or some other framework du jour, and that they prefer to write their front end code in vanilla JavaScript instead. But when it comes to writing web components, it seems everybody ends up writing atop a framework — even if it's a tiny framework of their own devising. Production web components written in vanilla JS appear to be very rare.
It seems there's just a bit too much work involved to meet even baseline expectations for a custom element. To handle instantiation, for example, you might need to:
Create a shadow root on the new instance.
Stamp a template into the shadow root.
Marshall any attributes from the element root to the corresponding component properties. This process breaks down into more work, such as:
Given this amount of work to simply instantiate the component, it's easy to see why most efforts to create interesting components typically end up relying on shared code. You might write a single web component in vanilla JS, but as soon as you start your second component, you'll be dying to factor the boilerplate into shared code… And now you're constructing a framework.
That's not necessarily a bad thing. It only means that, when you hear someone say that they want to write a component-based app, but don't want to use any framework at all, you have to take that with a grain of salt. It's possible the person has — perhaps unintentionally — ended up building the foundations of their own web component framework.
Does it matter whether that code is called a framework? Wikipedia enumerates these software framework hallmarks:
Given this definition, it seems hard to conclude that frameworks are bad per se. Surely there are good frameworks as well as bad frameworks.
Perhaps one reason people shy away from the concept of a framework is that, as a framework achieves higher levels of abstraction, it becomes something tantamount to a domain-specific language. If you and I both thoroughly understand JavaScript, but we are using different JavaScript frameworks, then in practice we may not find each other's code mutually intelligible.
Since the term "framework" can provoke strong negative reactions, authors of such code may actually care whether their code is labeled a framework or not. Google, for example, seems to take great pains to avoid describing its own Polymer project as a framework. They call it a "library", which sounds perhaps smaller or less threatening. But Polymer easily meets all of the above framework criteria. For example, Polymer's internal asynchronous task-scheduling infrastructure establishes the flow of control in a Polymer application, determining when to invoke component lifecycle callbacks and property observers.
Whether you like the idea of a framework or not, when it comes to web components, the DOM API is so rudimentary that, in practice, that API alone does not provide a sufficient framework for web component development. As long as that remains the case, the use of a JavaScript web component frameworks seems unavoidable. If you really, really want to avoid writing or using code that meets the above definition of "framework", perhaps you can do so and still be productive, but that seems like a hard way to go.
For our own work, we want to be using a popular web component framework, be it Polymer or something else. If our alternative were to write a proprietary, ad hoc framework of our own, which was shared by no one else, we would likely waste a lot of time solving problems others have already solved.