The big difference is that Handlebars always produces strings that your browser has to parse as HTML. Handlebars also doesn't know how to mutate between states, meaning if you add a class 10 levels deep in the template the best you can do is re-render the entire thing.
JSX + React produce functions that return React's representation of the DOM, their "virtual DOM", and React knows how to make small mutations based on state. If a change in state only needs to add a class 10 levels deep in the hierarchy, that is the only change that happens in the real DOM; it doesn't have to re-render the entire template.
Thanks for the demo link; I hadn't heard of HTMLBars.
It makes for a good demo I suppose, but I prefer React in a couple places: there's no separate template, style construction is done with an object and not a string (constructing that style string for HTMLBars seems error prone), and the connection between the values on the Ember object and how they will be used in the DOM is guessed only by naming convention. You could use `this.set('hotdogs', count % 255)` and reference 'hotdogs' in your template in place of 'color'.
There is a very nuanced set of performance (mem and cpu) and usability tradeoffs you make when adopting a dirty checking vs change tracking system. I'm working on coming up with a reasonable talk about it.
JSX + React produce functions that return React's representation of the DOM, their "virtual DOM", and React knows how to make small mutations based on state. If a change in state only needs to add a class 10 levels deep in the hierarchy, that is the only change that happens in the real DOM; it doesn't have to re-render the entire template.