Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
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.):
- bloated, have tons of unnecessary features
- not versioned and could be updated only by a new fork/re-pull
- live as a repository, not a module
- not maintained properly, most starters have many unresolved issues
- code is unreadable, guides and FAQs aren’t helpful
- non-modular, users can’t easily migrate from a boilerplate or extend it
Starter environments (CRA, razzle, nwb) and frameworks (Next, Nuxt):
- contain only the most important functionality
- exist as an npm module
- versioned and maintained by a big professional community
- have awesome docs and guides
- 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. And you need to maintain your starter, resolve issues and add new features. Even after you’ll archive and forget 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, that could be easily extended if it needs.
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 exactly 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 totally 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 a 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 “really awesome list” for the particular ecosystem (i.e. really-awesome-react) maintained by professionals.
- Include only the best tools.
- 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
Next.js, Razzle, CRA. Why you should use them for a next project. was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.