Tell me about it! Literally all you need is React.

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!

I've used React by itself for over a year before I ever reached for anything else you mentioned there. I eventually picked up many of the other things you mentioned too, and they were very useful, but they were very far from being necessary to make use of React, and I probably would've wanted them or something close if I didn't use React.

they may not have been necessary for your projects, but they're absolutely necessary for any real-world production grade apps. Angular is solely targeted in that direction. 90% of the React examples I see when I interview people are handlebars/mustache 2016, and would be better solved with server-side rendering in the first place.

I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.

While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework.

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 agree. React is far too opinionated for me to treat it as just a library. I use it as a framework just as I would use Angular, and it fits the bill. That it can also be used as just a library is a bonus, but doesn't define its identity.

I'd much rather select the libraries and frameworks I want to use than some huge monolithic beast of a framework. Oh did I mention that all the libraries I select in the react echo system are just JS? Not some massively proprietary framework like angular? yeah.

Lmao, this is exactly how I've felt, and why I'm using ordinary js with closures and a bit of jquery for the time being while I get up to speed and figure out wtf is going on.

"Javascript the good parts" has served me well.

If what you're trying to accomplish is feasible and maintainable with "ordinary js ... and a bit of jquery" then using a full React+Flux stack like the OP outlined is complete overkill. If someone has experience with those libs and tools then they'll probably use it even for trivial projects. However that does not mean it's prescribed for _everyone_ to use _every time_ they need to write a bit of javascript functionality.

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.

Sure, but tell me what isn't feasible? Ok, I'm not creating photoshop in a browser, but there have been some non-trivial highly interactive apps I've built and they are still modular and serve their purpose well.

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.

Eh, it really is not that bad. With just React and a fetch polyfil (to replace jquery's ajax) you can get pretty much the same power as with just jquery.

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)

Made the switch to HTTP/2. Using push with minified/gzipped/cached assets. Loading all my assets is typically a 6ms affair for all of react, react-dom, redux, custom JS, custom CSS, and additional PWA files. Mind you, dev machine.

... and this is how major diversity spawned in the frontend business the last couple of years... Seriously, though, a lot of companies still gets it on with mediocre frontend developers that still rocks jquery solo. It might be down to down company culture or just an unlucky set of colleagues.

I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.

I know you're using webpack but you could really add gulp to manage webpack and then manage gulp with grunt and then manage grunt with npm.

I mean why use one package manager/module loader when you can use 4?

This is exactly why I don't buy the argument that frameworks are so much easier to use and learn than languages. I look at the state of JS these days and shake my head in disbelief. When did it get so needlessly complex? More importantly, WHY?!?!

People who aren't doing complex things start using libraries that are designed to manage complex things, even though they don't need them, then complain that they're overcomplicated. Repeat ad nauseam.

That's one of the pros often mentioned about React. In practice, I haven't found it to be true so far. Once you start using React, you'll almost certainly have to use one the Flux implementations. So let's say you use Redux. Suddenly you also have Actions, Reducers and Stores that you have to learn. If you want to use Async Actions (which is very likely in a web application), you'll probably need Redux Thunk, so that's another concept to understand.

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.

You don't "almost certainly" need Flux at all.

By coincidence Dan Abramov just posted this: https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

The difference is that you're spending time learning about concepts that you are unfamiliar with, as opposed to learning Angulars many APIs.

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

Absolutely this. While it might be tedious to put those pieces together at first the knowledge that you gain is very transferable to the other app that you build instead of being one-trick pony in angular.

I've been using React for small projects in my personal time, and I haven't needed anything like Flux at all. Maybe you'll need it for complex apps, but React can be used for small ones without that added complication.

I still firmly believe Angular 1 got the right pieces into the framework (directives and services), but that the community latched onto some of the extraneous pieces (controllers, controllerAs, etc), which don't offer enough cost/benefit and simply make things much harder to grok. You often end up babying references and being bitten by implementation details of JS and somewhat-confusing names for things (e.g. $scope does not behave like the variable scope of any ES version).

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.

Is the comparison fair? I haven't tried Angular 2, but it seems much more full-featured than React. For example, I guess that Angular 2 includes a router, while React doesn't, and just a few days ago there was a vitriolic thread just here on HN about the state of react-router.

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

It's not a fair comparison. React is just a view layer. It's not trying to offer everything that you'd need to write a web application.

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.

Ember shares this problem, imo.

"tiny" nope.

import React from 'react'; import ReactDOM from 'react-dom';

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

I believe they are complaining about the ~150kb minified filesize, rather than the API surface area.

It's under 40kb gzipped. If that's a sizeable percentage of your total JS code, you probably didn't need React in the first place.

If that's pretty much all there is, you'd be better off saving ~150kb and just using ES6 template strings.

The surface area you have to learn to be useful in React is tiny, much so compared with Angular2.