…or, it could mean that for all of the problems that React has solved in terms of performance and action-management with nested views / components, it’s community still doesn’t have any officially recommended cow-paths or best practices about how to architect the larger application. There are a few micro-framework patterns which compete and evolve, but everyone that builds a React application is at some level building their own framework at the same time.
That’s great for some teams and some applications, but a ton of boilerplate and years of experience is required to keep that application from becoming a tightly coupled rats nest of libraries and code as it grows.
As an Ember developer (in my spare time anyway), I don’t really have the same problems outlined in the article. There are still lots of other problems to tackle when developing for the web, but strong conventions and abstractions can make for easier / quicker construction of an application, it’s long-term maintenance, training of the team, documentation of best-practices, and reuse of modules across projects.
For me, that means that during the time I’m able to spend developing my own projects, I actually get to spend more of it on solving problems that I find interesting, rather than burning through my creative energy on repetitive tedium.