I've briefly used Angular 1 a few years ago, and have been involved in the React ecosystem for the last two years. I really like React, it gets a lot of things right and I think it has a bright future.

But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development. As soon as you get past a "hello world" Todo app, even trying to figure out what questions to ask to get to a scaleable app design can be tough. There are good, stable solutions to most common problems like state management (Redux) and routing (React Router), as well as a ton of other goodies like server-side rendering and hot module reloading available, but if you don't know what you're looking for you're in for a lot of contradictory and sometimes outdated advice about what tools to use for what, and the best way to wire all of them up.

That said, this is an issue that the community is acutely aware of (there's been a lot of chatter on Twitter about it recently, although there's definitely still more questions than answers) and one that I think will get better with time.

> But I don't envy people who come into the React ecosystem today as their first experience with large-scale front-end development.

Totally agree. Doing anything large-scale is hard, and comes with a massive learning curve. No React or Angular can save you from learning what it means to go from "hello world" to working on a project with a team of, say, 10 people.

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.

Just look at how many starter kits there are and how big they tend to be: http://andrewhfarmer.com/starter-project/

Can only imagine how many of the choices made are going to be deprecated in a couple months.

Edit: Heh, and now that I've read the article, I see they hit on this issue. :)

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.

>lack of best practices

How many 'best practices' do you need? What about 'higher order components'? Use proptypes in development? 'Avoid local state'?

>constantly breaking changes

I call bullshit, what was the last breaking change? Every large release still supports the old deprecated syntax, but with warnings.

>Every tutorial before the last month is already outdated

That is a big exaggeration; I wouldn't advice anyone to use 'pre es6' tutorials, but the concepts still apply.

>everybody has a different way of setting up webpack / isomorphism / templating.

No they don't, maybe a small differences and what do you mean with 'templating'? It's not Angular.

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

My comment is about React. I am not defending AngularJS.

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.

s/compress/compile/;

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

[1] Ultimately probably insignificant, overall.

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

All of that is included with angular and is documented quite well in angular 2 (at least with the current typescript docs)

I had the complete opposite reaction. I learned a bit of React through a rails + react tutorial and I was lost pretty much the entire time. Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare. Granted the testing options of both beat out angular, but even at a surface level React just wasn't appealing.

> Having to write HTML using either JSX or the ReactDOM syntax was a complete nightmare.

Can you expand on this? I find writing JSX to be a breeze. JSX is basically HTML with a few small tweaks (e.g., for => htmlFor, class => className). If you use a linter, it will catch those mistakes for you while you're learning.

I think that in order to start seeing the appeal, you have to have seen the alternative. Before angular, I was writing a lot of backbone apps, and generally, they were well organized and easy to maintain.

With angular, I've found that my apps have devolved into a huge tag soup very quickly. It didn't take me long to realize that the templating syntax was a huge part of what made angular suck really bad, and its like the article says: "Angular 2 continues to put 'JS' into HTML."

So to me, JSX is at the core of what makes React feel manageable, since I can use OO and encapsulation techniques of javascript to deal with complex rendering and still keep my code organized and easy to follow.

The more I think about it, angular reminds me a lot of Coldfusion in its approach.

I used backbone a lot too, and despite their obvious differences, react feels like backbone's spiritual successor in terms of being 'Just Javascript' that solved problems, rather than a fullblown framework.

For the longest time I totally saw react as replacing backbone views, but in practice that was unwieldy and the stateful, unidirectional approaches (Jesus that needs a catchy acronym!) made more sense given what I was trying to achive.

Do you count time for learning all third-party libraries needed to create an app with React?

If you're just building components, the learning curve for Angular2 is no different.

All in all, it takes about 20 lines of code to define a simple web component.

If you're using either Angular2 or React for anything beyond trivial examples (ex, routing, AJAX, lazy loading, isomorphic rendering, etc), things become more complex.

Yeah, the thing is you can't build a fully functioning app with just React. That's the "problem".