There is lit-html and lit-element, though you can get tripped up by the difference between props and attributes coming from React JSX where everything is props because it’s all native JS until the DOM render...
It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that direction... I expect React will be the last to adopt them, or they’ll push for spec changes before they do...
You can also technically start using native es modules in browsers, either localhost in Chrome 74+ or via origin whitelist with Google. Or use a polyfill such as Guy Bedford’s https://github.com/systemjs/systemjs/blob/master/docs/import... or https://github.com/guybedford/es-module-shims — but you’ll have to consider solutions for custom syntax, scss or non-es module dependencies. I personally think there’s a gap in the npm ecosystem which is building “source packages” that are native single-file es modules you can easily import or compile from with a native JS module system...
But at that point the headline is "framework x could replace framework y"?
Web Components are great for reusable components like date pickers that you might want to re-use regardless of framework. If they're just the technology backing the implementation of some framework, than that framework is only worth switching to if it provides something fundamentally better than the framework you and many others already know, because the mere fact that it's built on Web Components no longer provides a significant advantage...
Templating libraries are far from frameworks. lit-html doesn't have a component model, and it's use in a web component doesn't leak outside of that component. You could switch from lit-html to something else and it wouldn't be a breaking change to users.
Try thinking about writing a React component that doesn't use React to render. Or seamlessly intermixing React and Vue commoners. Then you see the difference.
You can absolutely use web components with react... you just have to use `<lower-case-component>` for webcomponents, since a capital first character will trigger JSX transforms.
So you can use, for example this set of components with a react application and get some of the best of both worlds. The only down side is attributes in web components aren't passable via the markup, only via DOM reference.
I happen to like react as-is, but Vue is probably much closer to web components and could see Vue becoming a compile to web components option sooner than later.
Well I like stencil for its typescript and jsx but I haven't dug into it hard enough yet to discover its agony points. Its just that when it compiles its all native code calls, no framework to ship but you still benefit from jsx and typescript in development.
It’s tricky to recommend them because I’m using web components at work and find the transition from React especially rocky. But they are native and standard, and other frameworks are slowly moving in that direction... I expect React will be the last to adopt them, or they’ll push for spec changes before they do...
open-wc is also worth a mention: https://dev.to/thepassle/announcing-open-web-components-5h7 - their guide and setup for using web components is over here: https://open-wc.org/guide/#quickstart
You can also technically start using native es modules in browsers, either localhost in Chrome 74+ or via origin whitelist with Google. Or use a polyfill such as Guy Bedford’s https://github.com/systemjs/systemjs/blob/master/docs/import... or https://github.com/guybedford/es-module-shims — but you’ll have to consider solutions for custom syntax, scss or non-es module dependencies. I personally think there’s a gap in the npm ecosystem which is building “source packages” that are native single-file es modules you can easily import or compile from with a native JS module system...