A big part of React (and arguably the whole point of React), is the way in which state changes are handled and re-rendered. A React version of this progress bar element would simply have a render method, that when the state changed would simply be called again for another full-re-render of the element. The fact that this grabs individual elements and mutates them is about as far from React-style programming as you can get. Virtual DOM, tree-diffing, all of this is around a central concept that "immediate mode" programming reduces visual bugs, and is completely absent from custom elements. I'm not saying Custom Element are wrong, but they are absolutely different from React in a core and essential way.

Where's the part of React which allows me to return a new copy of what I want the HTML to look like, while only updating the changed elements of my view instead of totally blowing away the existing elements (the virtual DOM + reconcilitation part of React)? Also, where's the declarative event binding part?

I'd also point out that the state tree (setState) is a part of React, and plenty of apps are just fine being built using only setState for state management (no redux/flux/mobx).

I don't see the reason for down-votes here guys. It's a legitimate question, isn't it? I was hoping the recipient would understand - once they try to enumerate "the parts" - that it's them managing the state, and that centralized state management and unidirectional data flow are obtainable in Backbone, Custom Elements, or vanilla JavaScript for that matter.