[purpletoned]

Not to mention, it's much simpler than Angular. You can get upto speed with React in 2 or 3 days. Once you make the shift to specifying single states for your interactions and letting React rebuild the DOM on changes, you'll never go back to anything else.

[gasping]

> you'll never go back to anything else.

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.

[bryanlarsen]

You are absolutely right. Which is why I'm so excited about Angular2. It's the first post-React client-side framework to come along. (as opposed to React which is more of a library than a framework, although it definitely pushes the boundaries of that...)

[colinramsay]

Technically you're right - it is post-React. But in order for it to really have learned from React I think we'd have to wait a little while longer, because the industry is still learning what React and Flux can really bring to the table. For me, one of those things is simplicity, and that's something that I feel Angular sorely lacks.

[malandrew]

Given the choice between two solutions capable of helping you solve a problem, why would you ever choose a framework over a library? I would never choose a framework when a library suffices.

[Offler]

It's not really a post-React framework though, it has been designed at the same time as React was starting to take mind share so it's not clear if they have built something that responds to what React + Flux provide.

[Bahamut]

I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application.

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).

[purpletoned]

> Angular has a void with the lack of a useful enough eventing solution - $scope eventing ...

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.

[Bahamut]

> 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.

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.

[spicyj]

> Unfortunately it doesn't seem like React documented React.DOM :(

React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.

[Bahamut]

At the least, I cannot find any mention of the specifics anywhere on the main GitHub page - this is the best that I can tell: http://facebook.github.io/react/docs/top-level-api.html#reac... . I do know the recommendation is to use JSX, and I can see why, but more visibility of the API would be better.

Edit: As a note, I did find out how it worked by doing source code diving two months ago.

[purpletoned]

I think there's a page or two that describes what the jsx transformer does(which is it converts them to React.DOM elements IIRC). I think that's where I learnt that you could use raw JS functions instead of jsx, even though it said that jsx should be preferred or something to that effect.

[spion]

"HTML mixed in with JS via JSX is also an abomination"

Why?

[rdtsc]

> HTML mixed in with JS via JSX is also an abomination,

Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.

[kuni-toko-tachi]

You can reinvent Angular concepts in ReactJS using RxJS. If you do that, the code to do so is very small and is much more logical that AngularJS nonsense.

[rdtsc]

100x that.

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.

[zdam]

Can you elaborate on 'specifying single states for your interactions and letting React rebuild the DOM'...

- this feels like it is a key conceptual difference but I'm not clear on what this means.