Absolutely. React creates a dependency at the worst possible place, the view/component level. That's the one part of your code that should be the most re-useable. How many times do we have to re-write the same image galleries?
The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that trap us in dependency hell and minimize re-useability.
I'm on the Polymer team, so admittedly biased here, but I don't understand your comment about Polymer minimizing reusability.
Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.
Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.
My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.
Using Polymer(...) instead of document.registerElement(...) means that for anyone to re-use a component I build, they will need Polymer as a dependency. There will likely be more web component based libraries popping up, so then I'm going to need to download half a dozen identical libraries to use different components for my site? Then there's hacked components like React that don't even use the web components spec...
Yes, to use any component you will need that component's dependencies. That's just true of any software component. The Polymer() call has nothing to do with it, as in the end it just calls document.registerElement(). Raw elements that call into a template library in attachedCallback() will depend on that template library.
> The only clear winner can be vanilla JS web component
It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess.
Javascript isn't scoped in an HTML page, that's its first "sin". Therefore, any component architecture needs to work against the natural workflow of a webpage. So no ,the winner is certainly not "vanilla JS" and you know it. unless you are dealing with some trivial apps, I bet you'd use framework X or Z in an heartbeat.
The custom element polyfill is 2KB gzipped. All browsers are on board with supporting it. No, polyfills are not akin to frameworks, and yes, I am building a large SPA using just custom elements (no framework) and it's amazing.
The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that trap us in dependency hell and minimize re-useability.