React completely changed the way I thought about rich clients. It took me a little longer than 2 days, I went into React with an absolute hatred of anything Javascript and came out 2 weeks later loving it. There is something to be said for a library that can wash away over 10 years of built up anger for a particular technology. It's not just another revamped library thrown into the frying pan, it's a complete rethink of how rich clients can be developed almost effortlessly with code that anyone can read. When I got into react, all I could think was "yes, this makes sense, this is how it should have been all along." Moving into the future I expect most libraries will unify under the concepts introduced by React in the same way that most web applications frameworks are different flavors of MVC.
Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.
Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.
HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).
I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.
> HTML mixed in with JS via JSX is also an abomination ...
Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should address this hole.
> Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.
Unfortunately it doesn't seem like React documented React.DOM :( . I would rather just use HTML, but I would rather have it in a separate file. Perhaps a build tool for grunt/gulp where you can register keys with the path to the template being the value, and the tool converts the value into the React.DOM elements would be a good idea.
React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.
Edit: As a note, I did find out how it worked by doing source code diving two months ago.
Why?
Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.
Never got beyond all the directives, digests, factories, services, scopes, dependency injentions, all the ng-* tags and so on. That is a lot of terminology for something that is supposed to make developing web appliclations easy.
Granted I am not a Web UI developer was just curious what everything was excited about.
Maybe all this complexity just makes sense to someone who already did all the more complex stuff wiht jQuery? Not sure.
Anyway React made sense to me. The whole data flow ideas, minizing mutable state and inter-dependencies between components, VDOM and even JSX.
So I like React a lot better.
- this feels like it is a key conceptual difference but I'm not clear on what this means.