Why would I use this over React, or why would I use this at all?
Eventually React will fall out of fashion like every other framework before it, and teams that went all-in on it will have to do a painful rewrite. Web Components based apps will be able to incrementally migrate, element by element, to a different library.
Second, by relying on the browser to host components and run the component lifecycle and composition parts, it's pretty easy to be smaller and faster than frameworks like React.
Third, Shadow DOM fixes CSS. Scoped styles are simpler, easier to reason about, faster, have lower specificity, ID's become useful again, and it's much easier to do things like lazy load below-the-fold styles because you transform that into lazy-loading below-the-fold components (simpler than teasing apart rule soup).
Or they could just keep using what works? React's surface area (compared to something like Angular or Ember) is so small, it's not obvious to me why you'd want to do a rewrite just because it "fell out of fashion".
Sure, the core React library is small. But when do people ever just use the core library? Think of all the additional libraries and components in the React ecosystem that get used in projects. The footprint of the average React project ends up being just as large as the footprint of the average Angular or Ember project.
Fashion matters more than it should. The ecosystems move on, support lessons, new hires are less likely to know and really desire to learn the old thing...
edit: More importantly, the new applications in your organization might move on to the new things and then you usually have a hard time sharing components between them.
Why someone would be doing that? I mean mix and matching libraries could be asking for unmaintainable code...
Depending on standards will be great in the long run, as over time the need to deliver polyfills will evaporate.
In addition, writing a web component allows integration with any framework (even React! https://github.com/webcomponents/react-integration ).
First and foremost, Skate is a web component library designed to give you an augmentation of the specs focusing on a functional rendering pipeline and clean property / attribute semantics. It's about a tenth the size of just React itself, doesn't require any extras and utilises both custom elements and shadow DOM out of the box.
React is nice, and if you're can't invest the time to learn something new, Standalone is definitely a good choice. That said, the time it takes to learn Standalone you could have probably learned Skate. In my opinion, right tool, right job; hammer principle etc :)
Would be interested to see what jpnelson thinks as well.
React is brilliant and my favourite library and architecture, but without things like react-standalone[0] integrating singular components within an existing application, especially one that isn't completely client-side, is rather painful at times!
A lot of my applications are either legacy or hybrid's, somewhat heavy JS on the client side but not SPA's, I think of them as lots of mini-SPA's (routing and such is still handled by the server), I've actually found that approach much easier to reason about and it has the benefit of clean seperation of concerns, the downside is that you have to think more carefully about synchronisation between client and server.