I'm just writing a first React app, and read beforehand that it was going to be difficult to choose which libraries to use, and to get them to work together, but I haven't found that to be much of an issue in practice.

create-react-app set up all the build tooling, for a router the clear recommendation is react router, and for a flux implementation the clear recommendation is Redux. It feels like there's a well defined path for beginners. Over time you'll have to figure out how everything works, as is always the case, but you can learn more as and when it's necessary.

The bumps were more whether to use ES5 or ES6 (but then I found an official position in favour of ES6), and whether or not you need to use flux (although that was really just learning how flux worked, which wasn't wasted time).

The only uncertainty I have now is whether TypeScript will be necessary/useful in future, and if so how to integrate it.

The sanctioned way forward for React is Flow. It's not as comprehensive as TypeScript, but there's no compilation required - Flow annotations just get stripped out. As of a couple of weeks ago it is part of create-react-app.

https://flowtype.org

Too bad flow doesn't work as well as typescript in practice. It has way more bugs, is not as tested.

It was very promising at first but typescript now has caught up with Flow best design decision: noImplicitAny, strictNullChecks.

Also, check on the "try typescript" website: typescript's JS output is almost left untouched. it's effectively a replacement for babel, if you only care for ES2015 stuff, and not some of the more recent stage 0 / stage 1 stuff.

this. tried flow, but it's too 'smart' for my iMac to handle. Flow reads all JS files without problems - which killed my iMac after using 6>gb ram. a partial solution was to manually set ignore on some node_modules packages. but still, really slow experience with atom/subl/etc.

Compared to this, typescript is actually dumb enough to require ts definition files to actually parse non-ts (js) files.

Having used TypeScript and also picked up recent projects where it is not being used, TS is definitely the way to go.

The issue is that TS 1.8 doesn't support async/await in the browser until v2.0, but a ts -> babel transpile does the job nicely.

TS 2.0.2 is stable enough for usage I've found, had no issues at all using it so far.

Yes, typescript betas/rc's are more stable than many products out there :p

Microsoft stuff not allowed in my stack...

Why? It's Apache 2.0 licensed...

People seem to have forgotten that MicroSoft was a gigantic threat to our industry, and still is. It owns 98% PCs world wide. What would we think if 98% of gaz stations worldwide where belonging to one company? That would be dangerous, right? Same with MS except it's worse, because PCs are eveyrwhere controlling everything. It's Big Brother in real life. Just imagine one moment how many critical decisions having world wide impact on the life of billions of people are done using Excel? What if Excel was remote controlled?

So, no, sorry, I don't eat that stuff. Bill Gates has built the most dangerous edifice and no amount of charity will save him from the Hell of digital beings.

This is garbage.

I replaced react-router with route-recognizer. The later is a simple tool your code is using, has proper documentation and stability, and do not get in the way of automated tests with jest. But react-router changed too much (i.e. removed named routes), has a lot of dependencies (browserhistory, etc), has very poor documentation, and did not allow me to do automated testing at the levels I wanted to. Moreover, it is a "framework": you're code lives inside of it, breathes through it, and that's something I dislike greatly (for such a moderate usefulness).

Agreed, react-router developers try too much to change and add new features to their baby. it has become a bit of a monster. 46KB for a minified router framework...

Good thing you don't have clients demanding IE compatibility. Bye bye ES6 :-(

Doesn't babel (ES6 --> ES5) solve this issue or is there more to it?

You're right. But I've avoided bringing transpiling or polyfill stuff into our big project at work. I'm the only dev at work who really like JS at all, anyway, so I'm trying to keep it simple for the Java-only crowd.

CRA isn't opinionated aside from the config and testing (Jest). It has no router, no Redux, etc.

It was made for demos, proof of concepts, and beginners (at the beginning, maybe not anymore). I don't know how Angular CLI works, but if it works like Ember's, then there's no comparison. Ember CLI generates models, controllers, etc. any kind of thing and it enforces a file and directory structure that makes all Ember apps look the same.

Don't have a dog in the fight-- I'm using both React and Angular2 in production. I just wanted to add that create-react-app (which was built by a few guys over a weekend or something like that?) I found to be IMMENSELY more useful than angular-cli.

I know a lot of work has been put in to angular-cli and it's been through a few iterations at this point, but I almost wish they would scrap the whole thing and fork create-react-app.