TL;DR: don’t write and use custom starters. CRA core + universality = Razzle Dear developers, please, stop writing and using “starters”. Starters ( ): react-redux-universal-hot-example, React-starter-kit, 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 , guides and FAQs are not helpful unreadable are non-modular, users can’t easily migrate from a boilerplate or extend it Toolkits ( ) and frameworks ( ): CRA , razzle , nwb 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 , , will be used by some people in . Moreover, you need to your starter, resolve issues and add new features. Even after you’ll your repo, your code still will be . your buggy starter doesn’t matter is it full-featured or lightweight REAL PRODUCTION PROJECTS maintain archive 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 create a development environment and approach, which could be if it needs. CRA and Next.js versioned, standard, unified easily extended _create-react-app - Create React apps with no build configuration._github.com facebookincubator/create-react-app _next.js - Framework for server-rendered or statically-exported React apps_github.com zeit/next.js _razzle - ✨ Create server-rendered universal JavaScript applications with no configuration_github.com jaredpalmer/razzle _Nuxt.js is a minimal framework for creating Vue.js applications with server side rendering, code-splitting, hot…_nuxtjs.org Nuxt.js - Universal Vue.js Applications _Starting a new JS app? Build, test and run advanced apps with kyt 🔥_github.com NYTimes/kyt _Blazing fast, zero configuration web application bundler_parceljs.org 📦 Parcel 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 — boilerplate generator. Let me clarify: Yeoman was a very progressive idea when it appeared. Yeoman 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, obviously Webpack config is 90% of starter’s success. already predefine your webpack config, but the most important: razzle/Next.js 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 list — . , some of which have And this is one of the best lists. awesome-react 31 31 entirely different boilerplates 400+ issues. I wrote this “manifest” few month ago, but haven’t published until today.Today I was searching for routing for and accidentally saw this: hyperapp 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 at least boilerplates and build tools, make , standardize really awesome lists and don’t hype. Don’t hype Do you remember ? That was a good idea (7.5k ⭐)️, but … React-IDE any real product still doesn’t exist. Own opinion on standardization Make a “really awesome list” for the particular ecosystem (i.e. ). maintained 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 , and I’m sure that we should deal with this “old-fashioned starters epoch”. even built a popular one 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 **Github: Twitter: people stop writing software for stars, and start collaborating on really progressive projects. @Metnew @vladimir_metnew
