When you factor in the learning curve of the usual tools that go with React like Flux/Redux, Webpack, Router and whatnot, the combined cognitive load becomes a lot.
Yeah, additionally React has a serious paradox of choice problem.
Which of the dozens of CSS solutions should I use? Inline styles or not? Which of the dozens of Flux libraries? Isomorphic/universal or client side? If Isomorphic, Express or Koa? Does react-router work with the choices I've made? Webpack or Browserify? It goes on and on...
I love React, but the environment and best practices are unclear to say the least.
There is also a lack of best practices, combined with constantly breaking changes. Every tutorial before the last month is already outdated, and everybody has a different way of setting up webpack / isomorphism / templating.
I call bullshit on you calling bullshit on every point of this comment.
> How many 'best practices' do you need?
Actually, there should only be one way to do something in a framework. While not a framework, think about the Go language. Go is a very strict, almost paternal language that 'enforces' best practices in the language itself by giving you only one way to do something. Angular, on the other hand, provides numerous ways to create a service. Because of this confusion, the Angular team provides best practices. It's like saying, 'we screwed up in designing this thing, so you have to read all the documentation to find out the subtle differences in all this bullshit.' It's not the lack of best practices that concerns me, it's the abundance of them that gets shipped with a bloated framework that wasn't designed well.
>Every large release?I seriously doubt it.
Think of all the pain involved in removing all of the digest cycle code when switching from Angular 1.4 to Angular 2.0.
> No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.
Seriously? There are no small differences between Django templates, Soy templates (client and server side), and Angular templates to name a few. They are all very different yet they do essentially the same thing. At least Soy templates can be used outside of a framework (with either JS or Java).
You don't need Flux/Redux to use React. React without a Flux-alike is very much like Sinatra compared to Rails. If your goal is to learn React, Flux gets in the way, and you shouldn't bother.
Browserify/Webpack is a giant pain and my least favorite part of this programming environment, but I'm not clear what it has to do with React. Is the concern here that React is packaged in such a way that you can't use it with a simple script inclusion, and that you must use a bundling system?
Router libraries are even less essential to React than Flux. I've never used one.
Webpack is used for hot reloading otherwise Gulp can suffice to provide you with a command to compress your css and jsx files. You could do it manually with the cli to begin with but I'd use a build automation tool going forward.
You get the advantage of choosing any of those libraries/tools that make up an application (e.g. choosing a router library that makes sense to you [or the team] and/or for your app). Thus, intrinsically the learning curve is much more digestible than grokking why certain parts of a monolithic framework (e.g. Angular) are designed the way they are.
However, that may also lead to being kind of paralyzed by the amount of choice you have. I know I'm not alone in sometimes preferring to have most of the[1] choices already made for me. (Especially when I'm not really a domain expert nor interested in trying to keep up with all the newest goings-on in the area.)
This is a good point, but to be fair you need to learn and implement similar solutions in an Angular-based project. You still need to implement a layering architecture that separates application/model state from view state (e.g. Flux/Redux), a module system (e.g. Webpack, Browserify), and a router (e.g. ui-router, react-router).
