react-app will contain a couple useful run-time components plus a react-app CLI tool and templates, while react-app-tools contains all the build/run configurations - Webpack, PostCSS, Browsersync, HMR etc.

Here is a nice course on Pluralsight - Webpack Fundamentals: https://www.pluralsight.com/courses/webpack-fundamentals I have a real-world Webpack config with comments here: https://github.com/koistya/react-static-boilerplate/blob/master/webpack.config.js Do these comments help? Please, let me know if some comments are missing or confusing.

If component doesn't require API methods use functional React components whenever possible function Button (props) { return <button className= "mdl-button" {...props} />; } If component does require API methods use class-based syntax for declaring React components class Button extends React . Component { componentDidMount() { ... } componentWillUnmount() { ... } render() { return <button ref= "root" className= "mdl-button" {... this .props} /> } } If component doesn't mutate state and needs access to API methods, prefer extending it from React.PureComponent class Button extends React . PureComponent { render() { ... } } Use property initializers for declaring prop types and default props class Button extends React . Component { static propTypes = { className: PropTypes.string }; render() { const { className, ...other } = this .props; return <button className={cx( 'mdl-button' , className)} {...other} />; } } Use "on" prefix for delegates class Button extends React . Component { static propTypes = { onClick: PropTypes.func }; render() { ... } } Name event handlers starting with a verb, e.g. handleSubmit, removeRow etc. class Button extends React . Component { handleClick = (event) => { event.preventDefault(); ... }; render() { ... } } Lint your code with ESLint and AirBnb JavaScript style guide (eslint-config-airbnb) Use the ES2015+ syntax whenever possible and it makes sense to make the code more readable. Visit React Starter Kit for the full collection of best practices

Visual Studio Code is free, works faster than Atom and has a very cool built-in debugger for Node.js and ASP.NET Core apps.

GraphQL seems to be a good way to go, much better than RESTful API, no issues with API versioning and under/over fetching, great tooling - GraphiQL IDE. As of Relay, there are some alternatives, Apollo is being the most promising one. For small apps it might be a good idea to use GraphQL server directly, unless you're already comfortable using Relay or another GraphQL client. For larger apps, you may want to evaluate Relay, Apollo, Lokka to check what better suites project's needs.

You may want to use ugilifyify transform when you bundle your code with Browserify. You may want to set debug: true for you development builds to make it generate source maps. Why to use Gulp if you can fire up Browserify directly with a custom script and/or command. Here is an example: https://github.com/kriasoft/react-starter-kit (see tools/bundle.js and package.json/scripts )

You can for example create a Location object as a wrapper for History API, and call Location.navigateTo(/post/${id}) inside a user action handler. E.g. handleClick(event) { event.preventDefault(); Location.navigateTo(event.target.href) } . Then you may want to add more features into it such as Location.goBack() , Location.navigateTo(url, { replace: true }) etc.

The code sample above demonstrates how to implement a basic routing without using any 3rd party libraries. And in regards to the react-routing library.. it has this concept of a routing table (basically an array) where each route is just a URL path and one or more actions (route handlers) associated with it. Inside a route handler function you're free to do whatever you want, e.g. print to the console, fire up some actions on a worker process, asynchronously fetch some data, render React component etc. (it has no dependency on React and is extremely flexible I believe ).

We do use React and CSS per component approach mentioned here . The CSS code becomes simpler, there is no more (or very little) global / shared CSS rules which is a good thing I believe - easier to develop and maintain the project, very easy to refactor or remove obsolete stuff keeping your project nice an clean. And instead of reusing CSS you tend to compose UI elements, which dramatically improves the developer experience. Follow me on Twitter or GitHub