And as the article points out, it's just JavaScript.
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.
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.
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. :)
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.
> 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).
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.
[1] Ultimately probably insignificant, overall.
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.
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.
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.
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.