1. The virtual DOM. When I'm writing jQuery-based code, I have to write both a component template and code that updates the DOM in response to input; when I'm writing code for a virtual DOM, the component template is sufficient to update the DOM and I don't have to write that extra code, so there are fewer chances for bugs to creep in.

2. HTML-like syntax embedded in Javascript (JSX). I didn't like this at first until I configured Sublime Text to highlight embedded HTML correctly. Embedded HTML has pros and cons, but I think it's a net positive.

React projects also typically include new tech like ES2015, webpack, hot code reloading, and Redux with its time-traveling debugger. You can build your own stack that uses a virtual DOM library, embedded HTML, ES2015, and so on, but it's helpful to start with a common stack that many people understand. That's why React is interesting.

- Combined with immutable state manager like Redux, it can dramatically simplify front end development.

I used to hate working on website frontends. Tangled webs of event handlers and dom mutation. React got rid of the mess and I once again enjoy working on the front end.

In other words, you can think of the user interface as a function of your app's state, where the state is neatly kept in one place, instead of smeared all over the code. And since ClojureScript has excellent immutable data structures, you get great performance right out of the box. Things that do not need to be re-rendered aren't.

So, when React arrived it fit like a well-designed glove. Suddenly one could easily create complex apps with few lines of code and great performance.

As a side note, there are some aspects of React that we don't care about. JSX is one: various lisp-like languages have been using vector/list syntax for HTML for years, so in ClojureScript you don't have to use a separate syntax or pre-process your files: your functions just return nested vectors with HTML elements. Much more natural.

1. Virtual DOM -- but this also includes DOM diffing, which makes it extremely efficient to re-render "the entire app" whenever a change happens (because you're not actually rendering it all but you largely don't have to know that).

2. JSX -- but unlike HTML this is just syntactic sugar for the underlying API. It may look like someone got HTML in your JS but it's really just syntax for nesting components and the rest is plain old JavaScript (compared to HTML templates where you have to learn a proprietary template language to do the same things you can already do in JS).

3. Unidirectional (one-way) data flow with pure components. This isn't enforced by React itself but if you stick to constructing your components this way (which companion libraries like Redux encourage you to do), your entire application becomes easier to reason about because you can think of your React code as one giant render function.

A lot of these concepts have appeared in other libraries and frameworks but prior to React we used to think that Angular 1's two way bindings were the holy grail (despite the countless complexities it brought in real applications).