With angular I can keep all my HTML in my HTML files. Is this normal or am I completely missing something?
A lot of these issues turn out to be things we learnt were bad ages ago and have forgotten why. The original context you learnt in might be sufficiently different or other factors might mitigate the underlying issue.
In the case of JSX - we were all told that to keep css, js and html separate - that inlines js and styles are bad. These things are all partially true but in a react.js project your components are usually tiny and there is always an inescapable dependence between js and html. It is therefore very different from when we used to see long html documents littered with onclick.
The real reason we keep "technologies" separate is so that we understand what realm we're working at any given moment. Furthermore, we can distribute responsibilities across multiple team members focused on different disciplines. Facebook has the kind of clout internally to force their designers to use JSX and inline styles, but many organizations do not have that kind of alignment.
In this case, you can split out that boilerplate into a separate, smaller component and reuse it inside as many other components as you need.
> By that logic we should be putting our data stores in the component, any translations required to internationalize the component, the database queries.
I respectfully disagree with your inference here - such functions can be abstracted and used by many components - in most cases there's no value in baking them directly into a component.
The exception to this is if the function is not abstract at all, makes no sense outside the context of the component, and therefore can't be reused. Then, it probably makes more sense to put it inside the component, rather than breaking it out into a separate file.
This is true of most if not all of the markup and styles used inside a component, which is why React encourages JSX and inline styles to be put directly inside the component as it's the only place they make sense, and the only place they'll be used. The markup, styles and component behaviour are intrinsically coupled, there is a lot of 1:1 referencing, and separating them out into separate files means you'll just be flicking between three files when working on a component, instead of one. Where there is 1:n referencing, well, that's when you should break your component into smaller, reusable pieces.
The reason like Knockout.js because all the magic happens in a standard data-bind attribute, no funky syntax or paradigm shifts required. A purely functional solution like React seems like it's good for making games. Beyond that, for most sites, I think it would be more work to use React for little to no gain.
However it has a few issues.
1. Wrapping everything in observables is a bit annoying. Subtle issues can arise here in there especially if using the mapping plugin (which you kind of have to, it makes the process bearable).
2. If you start to have a lot of bindings on a page (a few hundred) performance degrades rapidly and there is a ton of DOM thrashing. Part of the problem is that a binding places an event handler directly on the DOM element. But there is also the initial load "flicker"/DOM thrash which for a significant page can take a second or two.
3. There are lots of workarounds such as rate limited observables, etc... But these are applied individually and become very tedious. They do not solve the entire problem either.
React solves all 3 of these so I can see significant benefits there. I have not switched myself but am experimenting. I do think Flux, Stores, etc.. are very overkill and actually poor architecture. But thankfully there are many alternatives cropping up which are much better.
React.js seems like it could be a good core for something like those alternative frameworks that you mentioned popping up. Aurelia looks interesting to me, but I don't think it uses React by default.
My advice is to try it at least to the point where you've created a couple of components and rendered one inside the other. A component manages everything to do with how it works with props it's given and the state it manages, and how it renders is just another part of that concern.
One of the nice pros you get used to quite quickly is having your editor autocomplete event handler and data variable names, as they're all right there in the same file.
JSX is just sugar for React.createElement() function calls, the syntax of which otherwise gets quite unpleasant to write and maintain once you start nesting them to any degree (ask anyone who's used a DOM builder library for a complete app).
Once I started using React in practice though, it turned out to be pretty nice. It significantly reduces cognitive overhead when thinking about frontend elements. And if you're worried about your javascript file starting to look more like an HTML file, composition of JSX components helps break things up.
Even if I can't convince you that it's actually pretty nice, you can write React without using any JSX. Just use a live compiler http://facebook.github.io/react/jsx-compiler.html to translate any documentation into the vanilla JS equivalent.
http://apidock.com/rails/ActionView/Helpers/TextHelper/conca...
http://thepugautomatic.com/2013/06/helpers/
http://guides.rubyonrails.org/form_helpers.html
https://github.com/rails/rails/blob/dd7af2c413a06ea44e50abf0...
http://courseweb.lis.illinois.edu/~hkim214/lis514/img/Dr_Seu...
Also i've never really gotten into all the string magic that angular templates use. ng-click="myEvent()", vs passing the event to the component as a property feels.
The Angular parser will go through the elements in the DOM and look for attributes it knows about like ng-click. When it finds ng-click, it will run the expression "myEvent()" on the controller's $scope.