larlet-fr-david-cache/cache/0b71ff2646d3188a520822252420844f/index.md

title: How to JavaScript in 2018
url: https://www.telerik.com/blogs/how-to-javascript-in-2018
hash_url: 0b71ff2646d3188a520822252420844f

<p><span class="featured">From command-line tools and webpack to TypeScript, Flow and beyond, let's talk about how to use JavaScript in 2018.</span></p>
<p> Last year many people, including myself, were <a href="https://developer.telerik.com/topics/web-development/javascripts-journey-2016/" title="" class="" target="">talking about JavaScript fatigue</a>. No, the ways to write a JavaScript application have not really slimmed down, BUT with a lot of command-line tools doing much of the heavy lifting, transpiling becoming less crucial and TypeScript trying to minimize type errors, we can relax a little.<br/>
<br/>
Note: This blog post is part of our whitepaper, "<a href="https://www.telerik.com/campaigns/kendo-ui/wp-javascript-future-2018" title="" class="" target="">The Future of JavaScript: 2018 and Beyond</a>", which offers our future-looking analysis and predictions about the latest in JavaScript.</p>
<h2><span>Command-line Tools</span></h2>
<p><span>Most libraries and frameworks have a </span><a href="https://www.telerik.com/campaigns/aspnet-mvc/net-cli-reinvented"><span>command-line tool</span></a><span> 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.</span></p>
<h3><span>Webpack Configurations</span></h3>
<p><span>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, </span><a href="https://twitter.com/thelarkinn"><span>Sean Larkin</span></a><span>, running around the world supplying us with </span><a href="https://www.youtube.com/watch?v=4tQiJaFzuJ8&amp;t=3526s"><span>great talks</span></a><span> and </span><a href="https://www.twitch.tv/videos/209664650?t=1h57m40s"><span>really fun and helpful tutorials</span></a><span>.</span></p>
<p><span>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 </span><span>😮.</span><span> </span><a href="https://github.com/vuejs/vue-cli"><span>Vue's CLI tool</span></a><span> even has a </span><a href="https://github.com/vuejs-templates/webpack"><span>webpack-specific template</span></a><span> 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:<br/>
</span></p>
<ul>
    <li>
    <code>npm run dev</code>: first-in-class development experience
    <ul>
        <li><span>Webpack + </span><code>vue-loader</code><span> for single file Vue components</span></li>
        <li><span>State preserving hot-reload</span></li>
        <li><span>State preserving compilation error overlay</span></li>
        <li><span>Lint-on-save with ESLint</span></li>
        <li><span>Source maps</span></li>
    </ul>
    </li>
    <li><code>npm run build</code><span>: Production ready build</span>
    <ul>
        <li><span>JavaScript minified with </span><a href="https://github.com/mishoo/UglifyJS2/tree/harmony"><span>UglifyJS v3</span></a></li>
        <li><span>HTML minified with </span><a href="https://github.com/kangax/html-minifier"><span>html-minifier</span></a></li>
        <li><span>CSS across all components extracted into a single file and minified with </span><a href="https://github.com/ben-eb/cssnano"><span>cssnano</span></a></li>
        <li><span>Static assets compiled with version hashes for efficient long-term caching, and an auto-generated production </span><span>index.html</span><span> with proper URLs to these generated assets</span></li>
        <li><span>Use </span><code>npm run build --report</code> <span>to build with bundle size analytics</span></li>
    </ul>
    </li>
    <li><code>npm run unit</code><span>: Unit tests run in </span><a href="https://github.com/tmpvar/jsdom"><span>JSDOM</span></a><span> with </span><a href="https://facebook.github.io/jest/"><span>Jest</span></a><span>, or in PhantomJS with Karma + Mocha + karma-webpack</span>
    <ul>
        <li><span>Supports ES2015+ in test files</span></li>
        <li><span>Easy mocking</span></li>
    </ul>
    </li>
    <li><code>npm run e2e</code><span>: End-to-end tests with </span><a href="http://nightwatchjs.org/"><span>Nightwatch</span></a>
    <ul>
        <li><span>Run tests in multiple browsers in parallel</span></li>
        <li><span>Works with one command out of the box:</span>
        <ul>
            <li><span>Selenium and chromedriver dependencies automatically handled</span></li>
            <li><span>Automatically spawns the Selenium server</span></li>
        </ul>
        </li>
    </ul>
    </li>
</ul>
<p><span>The </span><a href="https://github.com/developit/preact-cli#webpack"><span>preact-cli</span></a><span>, on the other hand, takes care of the standard webpack functionality. Then if you need to customize your webpack configurations you just create a </span><code>preact.config.js</code><span> file which exports a function that makes your webpack changes. So many tools, so much help; developers helping developers 💞.</span></p>
<h2><span>Babel On or Off</span></h2>
<p><span>Get it? Sounds like Babylon </span><span>😂</span><span>. I crack myself up. I'm not <em>exactly</em> tying Babel to the ancient city of Babylon, but there has been </span><a href="https://medium.freecodecamp.org/you-might-not-need-to-transpile-your-javascript-4d5e0a438ca"><span>talk</span></a><span> of possibly removing our reliance on transpiling. Babel has been a big deal for the past few years because we wanted all the shiny that ECMAScript was proposing but didn't want to wait for the browsers to catch up. With ECMAScript moving to yearly small releases browsers may be able to keep up. What is a JavaScript post without some of the awesome </span><a href="https://twitter.com/kangax?lang=en"><span>kangax compatibility</span></a><span> charts.</span></p>
<p><span>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.</span></p>
<p><span><a href="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/compatibility-es6.png?sfvrsn=81c1b8d1_1"><img border="0" src="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/compatibility-es6.png?sfvrsn=81c1b8d1_1" alt="look at all that green" data-displaymode="Original" title="look at all that green" data-openoriginalimageonclick="true"/></a></span></p>
<p><a href="http://kangax.github.io/compat-table/es6/"><span>Compatibility for es6</span></a></p>
<p><u><span><a href="http://kangax.github.io/compat-table/es6/"><span/></a><a href="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/compatibility-2016.png?sfvrsn=43f89061_1"><img border="0" src="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/compatibility-2016.png?sfvrsn=43f89061_1" alt="still looking green" data-displaymode="Original" title="still looking green" data-openoriginalimageonclick="true"/></a></span></u></p>
<p><a href="http://kangax.github.io/compat-table/es2016plus/"><span>Compatibility for 2016+</span></a></p>
<p><span>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.</span></p>
<p><span>To put some of this into perspective here are some browser usage percentages from </span><a href="https://en.wikipedia.org/wiki/Usage_share_of_web_browsers"><span>Wikipedia</span></a><span>.</span></p>
<p><span><a href="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/browser-user-statistics.png?sfvrsn=896a6611_1"><img border="0" src="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/browser-user-statistics.png?sfvrsn=896a6611_1" alt="browser user statistics" data-displaymode="Original" title="browser user statistics" data-openoriginalimageonclick="true"/></a></span></p>
<p><span>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 </span><span>😆.</span></p>
<h2><span>TypeScript Talk</span></h2>
<p><span>If we're talking about how to JavaScript we must talk about </span><a href="https://www.typescriptlang.org/"><span>TypeScript</span></a><span>. TypeScript came out of the Microsoft office five years ago but has become the cool kid in town </span><span>😎</span><span> in 2017. There was rarely a conference that didn't have a "Why We Love TypeScript" talk; it's like the new dev heartthrob. Without writing a sonnet to TypeScript, let's talk a bit about why developers are crushing hard.</span></p>
<p><span>For everyone who wanted types in JavaScript, TypeScript is here to offer a strict syntactical superset of JavaScript which gives optional static typing. Pretty cool, if you're into that kind of thing. Of course, if you take a look at the newest results from the </span><a href="https://stateofjs.com/2017/introduction/"><span>State of JavaScript</span></a><span> survey, it seems that a lot of people ARE, in fact, into that kind of thing.</span></p>
<p><span><a href="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/js-flavors-comparison.png?sfvrsn=14077aa8_1"><img border="0" src="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/js-flavors-comparison.png?sfvrsn=14077aa8_1" alt="JS Flavors Comparison" data-displaymode="Original" title="JS Flavors Comparison" data-openoriginalimageonclick="true"/></a></span></p>
<p><em><span>From </span></em><a href="https://stateofjs.com/2017/introduction/"><em><span>State of JavaScript</span></em></a></p>
<p><span>To hear it straight from the source, check out this quote from Brian Terlson:</span></p>
<blockquote>Speaking as someone who proposed types for JavaScript in 2014: I do not believe types are in the cards for the near future. This is an extremely complex problem to get right from a standards perspective. Just adopting TypeScript as the standard would of course be great for TypeScript users, but there are other typed JS supersets with pretty significant usage including closure compiler and flow. These tools all behave differently and it’s not even clear that there’s a common subset to work from (I don’t think there is in any appreciable sense). I’m not entirely sure what a standard for types looks like, and I and others will continue to investigate this as it could be very beneficial, but don’t expect anything near term - <span><a href="https://hashnode.com/ama/with-brian-terlson-cj6vu9vjv01nmo1wu8vmtt1x9#cj6vuspfq01oso1wuhjo5zvd6">HashNode AMA with Brian Terlson</a></span></blockquote>
<h3><span>TypeScript ❤s Flow</span></h3>
<p><span>In 2017, you have probably seen many </span><a href="http://thejameskyle.com/adopting-flow-and-typescript.html"><span>blog posts</span></a><span> discussing the TypeScript + Flow combo. </span><a href="https://flow.org/"><span>Flow</span></a><span> is a static type checker for JavaScript. Flow, as you can see in the State of JavaScript survey chart list above, has about as many people interested as they do uninterested. More interesting is the stats showing how many of the people surveyed haven't heard of Flow, yet </span><span>⏰</span><span>. As people learn more about Flow in 2018 maybe they will find it as beneficial as </span><a href="https://twitter.com/mgechev/status/940131449025347589"><span>Minko Gechev</span></a><span> does:</span></p>
<blockquote class="twitter-tweet" data-lang="en">
<p lang="en" dir="ltr">TypeScript &amp; Flow eliminate ~15% of your production bugs! Still think type systems are not useful? <a href="https://t.co/koG7dFCSgF">https://t.co/koG7dFCSgF</a></p>
— Minko Gechev (@mgechev) <a href="https://twitter.com/mgechev/status/940131449025347589?ref_src=twsrc%5Etfw">December 11, 2017</a></blockquote>

<h3>Angular ❤s TypeScript</h3>
<p><span>One may notice that all the code samples in Angular documentation are written in TypeScript. At one point, there was an option that you could choose to walk through the tutorial in JavaScript or TypeScript, but it seems Angular's heart has been swayed. Looking at the chart below connecting Angular to JS flavors we can see that there are actually a tiny bit more users connecting Angular to ES6 (TypeScript: 3777, ES6: 3997). We'll see if all of this affects Angular in 2018.</span></p>
<p><span><a href="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/angular-connections.png?sfvrsn=192c96f4_1"><img border="0" src="//d585tldpucybw.cloudfront.net/sfimages/default-source/blogs/2018/2018-02/angular-connections.png?sfvrsn=192c96f4_1" alt="angular connections" data-displaymode="Original" title="angular connections" data-openoriginalimageonclick="true"/></a></span></p>
<p><em><span>From </span></em><a href="https://stateofjs.com/2017/introduction/"><em><span>State of JavaScript</span></em></a></p>
<p><span>For expert advice on how to choose the right JavaScript framework for your next application, check out <a href="https://www.telerik.com/campaigns/kendo-ui/wp-javascript-future-2018" title="" class="" target="">this great whitepaper</a>.</span></p>
<p>
Undoubtedly, the way we JavaScript will evolve in 2018. As programmers we like to make and use tools that make our lives easier. Unfortunately, that can sometimes lead to more chaos and too many choices. Thankfully, command line tools are relieving us of some grunt work and TypeScript has satiated the type-hungry who were sick of type errors.
</p>
<h3>The Future of JavaScript</h3>
<p>Curious to dive deeper into our take on where JavaScript is headed? Check out our new paper, The Future of JavaScript in 2018 and Beyond.</p>