### TL;DR: don’t write and use custom starters.

![](https://hackernoon.com/hn-images/1*3R6Xjt0TX6rlYF6h3Xiybg.png)

CRA core + universality = Razzle

**Dear developers, please, stop writing and using “starters”.**

Starters (**_React-starter-kit,_ react-redux-universal-hot-example,** _etc_**.**):

*   are bloated, have tons of unnecessary features
*   aren’t versionated and could be updated only by a new fork/re-pull
*   live as a repository, not a [module](https://hackernoon.com/tagged/module)
*   aren’t maintained properly, most starters have many unresolved issues
*   code is [unreadable](https://hackernoon.com/tagged/unreadable), guides and FAQs are not helpful
*   are non-modular, users can’t easily migrate from a boilerplate or extend it

Toolkits ([**_CRA_**](https://github.com/facebookincubator/create-react-app)**_,_** [**_razzle_**](https://github.com/jaredpalmer/razzle)**_, nwb_**) and frameworks ([**_Next_**](https://github.com/zeit/next.js)**_,_** [**_Nuxt_**](https://nuxtjs.org/)**_,_** [**_after.js_**](https://github.com/jaredpalmer/after.js)):

*   contain only the most essential functionality
*   exist as an npm module
*   are versionated and maintained by a professional community
*   have awesome docs and guides
*   are modular, users can easily migrate and extend own setup

Remember that **your buggy starter**, _doesn’t matter is it full-featured or lightweight_, will be used by some people in **REAL PRODUCTION PROJECTS**. Moreover, you need to **maintain** your starter, resolve issues and add new features. Even after you’ll **archive** your repo, your code still will be **running on someone’s servers and in browsers**.

> Don’t waste other developer’s time.  
> Don’t try to resist the future.   
> Better be a contributor, if you can’t bring new ideas.

Tools like **CRA and Next.js** create a **versioned, standard, unified** development environment and approach, which could be **easily extended** if it needs.

[**facebookincubator/create-react-app**  
_create-react-app - Create React apps with no build configuration._github.com](https://github.com/facebookincubator/create-react-app "https://github.com/facebookincubator/create-react-app")[](https://github.com/facebookincubator/create-react-app)

[**zeit/next.js**  
_next.js - Framework for server-rendered or statically-exported React apps_github.com](https://github.com/zeit/next.js/ "https://github.com/zeit/next.js/")[](https://github.com/zeit/next.js/)

[**jaredpalmer/razzle**  
_razzle - ✨ Create server-rendered universal JavaScript applications with no configuration_github.com](https://github.com/jaredpalmer/razzle "https://github.com/jaredpalmer/razzle")[](https://github.com/jaredpalmer/razzle)

[**Nuxt.js - Universal Vue.js Applications**  
_Nuxt.js is a minimal framework for creating Vue.js applications with server side rendering, code-splitting, hot…_nuxtjs.org](https://nuxtjs.org/ "https://nuxtjs.org/")[](https://nuxtjs.org/)

[**NYTimes/kyt**  
_Starting a new JS app? Build, test and run advanced apps with kyt 🔥_github.com](https://github.com/NYTimes/kyt "https://github.com/NYTimes/kyt")[](https://github.com/NYTimes/kyt)

[**📦 Parcel**  
_Blazing fast, zero configuration web application bundler_parceljs.org](https://parceljs.org/ "https://parceljs.org/")[](https://parceljs.org/)

**UPD: I’ve received dozens of comments about the negative tone of the article. Let me clarify few things:**

*   You could you use any boilerplate if you’re sure that nobody except you will work with this code.
*   Initial project setup could become a standard like a code style conventions (styleguide).
*   “Copy-pasting” projects could continue forever until unified initial setup with extendable webpack config appears.
*   I don’t engage people to ignore internals. Even vice versa — learn as much as possible. But there is no guarantee that it’s a “good” boilerplate.
*   Initial project setup could become a standard like a code style convention. Creating a project using such tools is like to follow a styleguide.

#### Why do starters exist at all?

Every time something new gets published, most people start searching for a boilerplate. That’s right; they want to try a new lib. And if there is no boilerplate — you could try to write it and make popular (_and then fix this sh#t till you won’t have 400+ issues in your repo_).

### Where did starters appear at all?

![](https://hackernoon.com/hn-images/1*YdSEELtHmONHPGsdHPHJxw.gif)

I think “boilerplate epoch” has been started since **Yeoman** — boilerplate generator. Let me clarify: Yeoman was a very progressive idea when it appeared.

Yeoman generators were useful mostly due to file processing complexity and poor development environment at that time. Projects were powered by a subset of Gulp scripts those integrate very different tools: **_browsersync_**_,_ **_livereload_**_,_ **_browserify_**_, etc._

> For example, AngularJS doesn’t have out-of-box support for lazy loading and minification in v 1.3. There wasn’t any helpful info about LL + minify + es6 for AngularJS on StackExchange, so cloning a starter with these features was the only way to start development. It was 2014.

### Starters today

Nowadays, we have awesome Webpack that solves all issues with file processing and lazy loading, have plugins for SSR in Angular and Vue, have solutions like CRA/razzle/Next.js/nwb. Is there any reason to build a starter?

#### Myth — starter could speed up development

That’s mostly a myth. You have to spend even more time to start working with a starter. What part of a starter speeds up development? The most obvious answer — code organization + Webpack config. And if code organization could be an open question, **Webpack config** obviously **is 90% of starter’s success.**

**razzle/Next.js** already predefine your webpack config, but the most important: **They’re doing it in a unified way and allow storing custom config separately. Or even distinct it into an npm module.**

When you’re using CRA/razzle/etc., you always know that your colleague or other developers that would work with your code won’t have to spend their time on researching unreadable buggy setup.

#### Myth — if starter has <libName>, it already integrated as you want

Most starters have every feature starting from GraphQL to rarely seen Redux addons. That results in a bloated, unreadable, but most importantly — unusable starter. Especially for developers those searching for a something not too complex and lightweight.

> That also explains why people infinitely write new “lightweight” starters.

#### Please, stop it!

Just count how much boilerplates exist in [_awesome-react_](https://github.com/enaqx/awesome-react) list — **31**. **31 entirely different boilerplates**, some of which have **400+ issues.** And this is one of the best lists.

I wrote this “manifest” few month ago, but haven’t published until today.  
Today I was searching for routing for **hyperapp** and accidentally saw this:

![](https://hackernoon.com/hn-images/1*Kslov2UdCqWd2GbeHRlkfw.png)

Just search “hyperapp” on Github

People already have been starting spam Github with buggy starters while you’re reading this. Completely useless “awesome-lists” with libs that have zero support from maintainers will appear soon.

> Don’t write software for ⭐️.  
> Write software to bring something new.

We need to **standardize** at least boilerplates and build tools, make **really awesome lists**, **and don’t hype.**

#### Don’t hype

Do you remember [React-IDE](https://github.com/reactide/reactide)? That was a good idea (7.5k ⭐)️, but … [any real product still doesn’t exist.](https://github.com/reactide/reactide/issues/126)

#### Own opinion on standardization

*   Make a **maintained** “really awesome list” for the particular ecosystem (i.e. `really-awesome-react`). [Also, there is good awesome list of toolkits.](https://github.com/reyronald/awesome-toolkits)
*   Highlight maintenance level and popularity in awesome lists.
*   Ignore any attempt to build “yet another integration of Bootstrap with React”.

> I’ve researched many popular boilerplates and [even built a popular one](https://github.com/Metnew/suicrux), and I’m sure that we should deal with this “old-fashioned starters epoch”.

> Also, some starters are great. Not all starters are so bad as described above.

**Thanks for reading, hope it really changes something.   
Repost this article — make _people stop writing software for stars, and start collaborating on really progressive projects._  
**Github: [@Metnew](https://github.com/Metnew)  
Twitter: [@vladimir\_metnew](https://twitter.com/vladimir_metnew)

NuxtJS

Progressive

Twitter

Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

Next.js, Razzle, CRA. Why you should use them for a next project.

Too Long; Didn't Read

Companies Mentioned

@vladimirmetnew

RELATED STORIES