It really only makes sense to compare React to Angular's Directives because they are both trying to simplify the process of creating isolated, reusable componen

It really only makes sense to compare React to Angular's Directives because they are both trying to simplify the process of creating isolated, reusable components with data binding built in. In fact, they both use in-memory representations of the DOM to track model changes, although they differ in the actual mechanisms for doing so. Angular uses "dirty-checking" which basically tracks whether or not a model has changed in any way from its previous value and it does this on a loop. It's very simple and inexpensive but can start to perform poorly when dealing with large lists of items (in the tens of thousands). React also has an in memory representation of the DOM they call the "virtual DOM" (not to be confused with Web Components' "shadow DOM") and differs from Angular in the way it employs its diffing algorithms to efficiently and surgically respond to only the elements that need to change when a model is updated. It performs better than Angular when dealing with very large collections of items but I believe Angular is as performant or better than React in the small case. React also enforces certain restrictions by default when it comes to mutating data. While Angular encourages "two-way binding" where data can be changed by two different sources (e.g. the controller and the user changing the input field), React encourages a strict policy of one-way data passing. It is possible to restrict Angular directives to function exactly like React components, however, if you subscribe to React's core philosophies about data handling. For large applications, though, React applications get messy as they need to pass data down a very long tree of nested components. They wrote the "Flux" pattern to address this concern, but it really ends up looking like yet another version of MVC (although I like it, personally). Where React and Angular differ dramatically is in how they handle templating. Angular's philosophy from the start was to embrace HTML and a declarative programming style. They believe HTML should be embraced and extended using "Directives" which is very much in-line with the philosophies behind the coming Web Components standard. React's team, on the other hand, challenges long-held assumptions about web development like not including markup in your code, opting instead for a framework that not only encourages it, but requires it. This is a controversial aspect of React, but it makes sense when you actually try it. Some logic is better written imperatively (like if statements, map/reduce, etc.) and it's nice having everything required to render the component in one file. It does, however, require a compilation step unless you use their imperative DOM manipulation library so in that respect Angular is far easier to get up and running with (which is part of its dramatic success). In my mind, the only aspect where React really has a clear advantage is the ability to run server-side, which allows you to pre-render components before sending them to the client. This solves a variety of SEO and time-to-render issues single-page web applications often struggle with. The only caveat is that single-page apps don't typically need to be SEO friendly (like gmail or google docs, for instance) so it remains to be seen how important this differentiator really is. The React team admits it was really a happy side-effect of the virtual DOM and not really the main reason they built it, but it's compelling nonetheless. One last thing I'll mention is that currently it's a very difficult time to pick a horse in front-end development world. All signs point to Web Components becoming the next big thing, but React has made a lot of people question whether or not that's the correct approach. React has not made it a stated goal of theirs to align with the Web Components specifications like the Ember and Angular teams have. I can't say whether this is incredibly wise or foolish, but again, it's compelling. edit: I forgot to answer your original question directly: > Does it use the one-way-only data-binding powered by shadow DOM It allows for both the use of one-way binding and two-way binding, which React actually does too (although React's core team discourages using two-way binding). Neither is powered by shadow DOM so I'll assume you meant virtual DOM. I kind of answered this above but to re-iterate, both frameworks build up virtual representations of the DOM in memory to better serve data-diffing, but they both chose different mechanisms for doing said diffing which is outside the scope of this post but definitely interesting to learn about. The important point to take away is that you can restrict Angular directives to function exactly the same as React components, the only functional difference being the diffing algorithms under the hood and the templating systems used.