For starters, consider that Pete Hunt asked why React is overwhelming for beginners:
If you use React, you probably share the same experiences with Vjeux:
There is a major problem in the React community that cripples beginners and hinders experts alike.
At work this past quarter, we painstakingly started three new projects at work. I say “painstakingly” because every project required decisions to be made around tooling depending on the scope & needs.
Ultimately, the problem is that by choosing React (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
Yeoman & Plop can alleviate the amount of copy & pasting you do between projects.
However, generated is never a one-to-one match, nor can it be.
At scale with enough projects, it is exceedingly difficult to back-port features & improvements from one application to the rest, since the common code is not abstracted into an independently updatable dependency.
When a generator is good solution for repetitious code, a better solution is to abstract it into a simpler API.
Otherwise, the generator becomes a confusing, logic-riddled application itself due to permutations of possible use-cases, forever in a race to stay relevant with the applications it created.
I’ve experienced this first-hand with several generators, including my own evolution/wordpress.
An example of this can be seen in Mark Dalgleish’s excellent react-fetcher, libraries such as Redux, React Router, Webpack, and the React ecosystem have, largely, opted for discrete modularization at the cost of terse APIs by offloading their architectural underpinnings to the user and, as a result, worsen the developer experience in aggregate.
Alone, the APIs are small, but even less than a handful yield a nearly incomprehensible mess of code to each new set of eyes.
Even if contained in a “boilerplate” project, scaffolded by a generator, or tucked away in a finalCreateStorev3SeriousThisTime.js file, we’ve created a rat’s nest of wiring that would make WordPress plugins blush.
Of course, these APIs are a requirement for having smaller, decoupled, testable, and therefore, high-quality libraries.
However, we need an abstract middle-ground between wiring dependencies and generating boilerplates.
Abstractions are necessary to reduce the cognitive load of how things work so you can focus on creating.
Any significantly-scoped project will already have a substantial amount of code behind it.
Application developers should not have to become experts in the underpinnings of the library just to use it.
Therefore, instrumenting tooling should aim to be as minimal as possible.
Consider this hastily-compiled list of alternatives:
Until a large part of the ecosystem adopts terse APIs, conventions, and strives for significantly reducing implementation details for end-users, abstract tooling may be our only outlet.
Following the Twitter threads above, many rightfully concede that there is no one-size-fits-all solution.
However, if we start with the intent to just build a prototype, the underlying abstractions don’t matter.
Related, Vjeux challenged the community to devise tooling for quick prototyping, even at the cost of customization.
In the meantime, I’m aware of a few options you can use today to jumpstart your next project: