Ploymer was a crapshow and HTML import a nightmare for load times. Unless some sort of topology bundling is provided for web components I'm out. We tried to do generic components for multiple frameworks based in webcomponets and it was an utter failure in practice especially for low band networks.
Even from the beginning of Polymer and it's use of HTML Imports there were tools for bundling them and they worked great! It's even easier to find the right tool for you now that ES Modules deliver the power of web components with the help of your favorite Rollup or Webpack configs and plugins...
To be fair, HTML imports is deprecated and won't be standardised. The recommended way to package web components now is with ES modules, and they can be bundled (with eg. Rollup or Webpack.)
That is great, but I am still 100% sceptical of a web component intergration with any given framework. Is the integration point opinounated? Is it reactive, callbacks? Two way bindings? What does the application lifecycle look like? Would it be just opiononated sets of components? I just don't know... If I'm wrapping web components to meet our design patterns then why bother at all? I feel like the entire web component concept from an API level is a great concept but just not there for real world at scale consumption. I may just be not optimistic about it all.
It seems that it's not about binding but that devs need to take of it themselves. On the other hand, I guess you first need to generic interface to bind on and then it's possible to take care of bindings.
That said, I think nobody needs any framework any more if some automatic binding mechanism would get standardized. At least for apps that routinely instantiate and destroy components would profit from that a lot.
Allow me to float ZephJS at you as an example of a Web Component framework with a bundling tool to do what you describe. Simplifies everything about building Web Components.
