Eli Perelman
8 years ago
committed by
GitHub
2 changed files with 18 additions and 18 deletions
@ -1,11 +1,26 @@ |
|||
# FAQ |
|||
|
|||
### What is the added value versus all the boilerplate projects out there like [create-react-app](https://github.com/facebookincubator/create-react-app)? |
|||
### Why not a boilerplate or alternative? |
|||
|
|||
The proliferation of boilerplate and metapackages is one thing we are trying to reduce. These types of projects |
|||
Boilerplates are great resources for scaffolding out application-specific code which |
|||
would be difficult or tedious to generate for every project. Unfortunately many projects |
|||
also bake in build configuration into this process, causing a lot of duplication. If you |
|||
need to make a change to your build steps, you are forced to make that change across all |
|||
your similar projects. Using a preset rather than a boilerplate keeps this process DRY. |
|||
|
|||
Tools like [Create React App](https://github.com/facebookincubator/create-react-app) have |
|||
been fantastic improvements to the tooling ecosystem, but unfortunately only work on specific |
|||
environments like React, and do not allow simple extensibility of the build configuration. To |
|||
answer this, new and similar projects are cropping up to build different types of projects, |
|||
often duplicating efforts which miss out on the best practices to share with the other project |
|||
types. |
|||
|
|||
### What is the added value versus all the boilerplate projects out there? |
|||
|
|||
The proliferation of boilerplate and meta-packages is one thing we are trying to reduce. These types of projects |
|||
are great, and do serve a purpose. But what if you wanted to make a configuration change across all your |
|||
projects? You must make config changes in many places, including the original boilerplate, whereas presets |
|||
give you the power to confine these changes to a single package. Some of these projects also make a tradeoff |
|||
give you the power to confine these changes to a single package. Some of these projects also make a trade-off |
|||
between ease of set up and black-boxing the configuration. Once you decide to make a configuration change, |
|||
you are forced to maintain the entire configuration and its dependencies in perpetuity. We believe Neutrino |
|||
represents a good balance between ease of set up and future extensibility. |
|||
|
Loading…
Reference in new issue