Most libraries and frameworks have a command-line tool that, with one command, will spin up skeleton projects for us to quickly create whatever our little hearts desire. This will often include a start script (sometimes with an auto re-loader), build scripts, testing structures and more. These tools are relieving us of a lot of redundant file making when we create new projects. Let's look at few more things some command line tools are taking off our plates.
Configuring your webpack build process and really understanding what you were doing, was probably one of the more daunting learning curves of 2017. Thankfully, they had one of their core contributors, Sean Larkin, running around the world supplying us with great talks and really fun and helpful tutorials.
Many frameworks nowadays not only create the webpack config files for you, but even populate them to the point that you may not even have to LOOK at it 😮. Vue's CLI tool even has a webpack-specific template giving you a full-featured Webpack setup. Just to give you the full idea of what command line tools are providing, here’s what this Vue CLI template includes, straight from the repo:
npm run dev: first-in-class development experience
vue-loaderfor single file Vue components
npm run build: Production ready build
npm run build --reportto build with bundle size analytics
npm run unit: Unit tests run in JSDOM with Jest, or in PhantomJS with Karma + Mocha + karma-webpack
npm run e2e: End-to-end tests with Nightwatch
The preact-cli, on the other hand, takes care of the standard webpack functionality. Then if you need to customize your webpack configurations you just create a
preact.config.js file which exports a function that makes your webpack changes. So many tools, so much help; developers helping developers 💞.
These images of these charts aren't legible because I wanted to showcase just how green they are! For full detail click the links below the images to inspect the charts further.
In the first graph those red chunks on the left are compilers (e.g. es-6 shim, Closure, etc.) and older browsers (i.e. Kong 4.14 and IE 11). Then the five mostly red columns on the right are the server/compilers PJS, JXA, Node 4, DUK 1.8 and DUK 2.2. On the lower graph that red section that kind of looks like a bad drawing of a dog looking at a messed up exclamation point are servers/runtimes with only Node 6.5+ having green streaks. The makeup of the left red square are the compilers/polyfils and IE 11. More importantly, LOOK AT ALL THAT GREEN! In the most popular browsers, we have practically all green. The only red mark for 2017 features is on Firefox 52 ESR for Shared Memory and Atomics.
To put some of this into perspective here are some browser usage percentages from Wikipedia.
Okay, turning off Babel may be a long ways aways because when it comes down to it we want to make a concerted effort to be accessible to as many users as we can. It is interesting to consider that we may be able to get rid of that extra step. You know, like before, when we didn't use transpilers 😆.
To hear it straight from the source, check out this quote from Brian Terlson:
TypeScript & Flow eliminate ~15% of your production bugs! Still think type systems are not useful? https://t.co/koG7dFCSgF— Minko Gechev (@mgechev) December 11, 2017