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

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

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
• aren’t maintained properly, most starters have many unresolved issues
• code is unreadable, guides and FAQs are not helpful
• are non-modular, users can’t easily migrate from a boilerplate or extend it

Toolkits (CRA, razzle, nwb) and frameworks (Next, Nuxt, 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

zeit/next.js_next.js - Framework for server-rendered or statically-exported React apps_github.com

jaredpalmer/razzle_razzle - ✨ Create server-rendered universal JavaScript applications with no configuration_github.com

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

NYTimes/kyt_Starting a new JS app? Build, test and run advanced apps with kyt 🔥_github.com

📦 Parcel_Blazing fast, zero configuration web application bundler_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?

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 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:

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? That was a good idea (7.5k ⭐)️, but … any real product still doesn’t exist.

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.
• 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, 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: @MetnewTwitter: @vladimir_metnew