Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going!
Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!
For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours?
Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it?
With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code.
With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.
I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.
"Javascript the good parts" has served me well.
This will all settle down in a year or two, once we get the most basic features built-in into browsers. Like for example modules + HTTP2 will probably mean no more bundlers or build tools (which is where the vast majority of this craziness is coming from)
I really wish people would qualify what they're trying to accomplish when they bang on about things being "needlessly complex". Maybe for what they're doing it totally is and they shouldn't be distracted with React, Flux, Webpack, etc. There's nothing wrong with that. However, when taking on a project where these sorts of things are immensely useful, it's nice they exist.
I'm not saying we shouldn't get on react - I'm sure in the end it will serve myself and others well, but it's a bit of a headf*ck trying to figure out the whole ecosystem, and how to write a good solid app in it. For anyone that tries to say "but it's only react with x" - No it's not! Not for anyone that cares about the quality of their app, theres a whole heap to learn.
And I am learning, but at the same time I'd rather create a well designed app with the crummy tech I know than a crummy app in something I just haven't figured out yet. Luckily I'm doing my own thing so have that choice.
I mean why use one package manager/module loader when you can use 4?
Then there's routing, which is not present in the React core, so you'll need a routing library as well. Again your API surface increases.
In the end, if you want to write a larger application with React, you'll often have a similar or even larger API surface than Angular. I can understand that some people prefer the conceptual model of React (with its focus on Components) over that of Angular. The claims about a smaller "API surface" have always felt wrong to me, though.
For instance if you've already spent time learning about Redux you'll have a very easy time re-using those in Angular 2 (with ngrx).
By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Angular 1 still beats the pants off of everything else in my experience, if you know how to trim the fat. I'd very much like to write more about my approach in the near future.
If you look at react-redux-starter-kit [1], I would absolutely not say that it's simple. This file [2] is only 12 lines of code but can you call it simple? I don't think so.
[1] https://github.com/davezuko/react-redux-starter-kit
[2] https://github.com/davezuko/react-redux-starter-kit/blob/mas...
React has become synonymous in some people's minds with "React + a bunch of other stuff", but this wasn't intentional. It's an unfortunate side effect of its popularity.
function App(props) { return <div>Hello {props.name}</div>; }
ReactDOM.render( <App name="nichochar" />, document.getElementById('root') );
Or the alternative component API that has componentWillMount, componentDidMount, componentWillReceiveProps, shouldComponentUpdate, componentDidUpdate, componentWillUnmount, and render.
That's pretty much all there is