Learning Javascript the proper way in 2017 — Part 1: The ecosystem
It is 2017. You want to jump into the ever-growing crowd of Javascript developers. And why not. Finally the world has a truly cross platform, full-stack language with which we can build anything. Or so it is said.
The platforms
- Plain old Javascript — that works on the web. Supported by Chrome, Firefox, IE/Edge and almost all browsers.
- Node.js — Javascript outside the browser, straight on your metal. i.e. server-side apps are possible.
- Electron — A webkit+v8 container (portable lightweight Chrome), which lets you create Javascript desktop applications for Windows, MacOS, Linux.
- Cyclon.js — Javascript framework for IoT : Now you can code your robotics/electronic platforms in Javascript
- IonicFramework — A webkit+v8 shell for mobiles. Create mobile apps in Javscript with HTML/CSS ui. Works on Android/iOS/Windows 10
The ‘languages’
While that makes Javascript all so exciting, we now take a look at the situation of the ecosystem. At this point of time, if you pick some of the top Javascript projects across the spectrum, and look at the languages they are using, you’ll find most of them are not in pure canonical Javascript. The reason being, ‘pure canonical Javascript’ itself is a relative term. In 2015, ECMA International, Technical Committee 39 (tc39) ratified the ECMAScript 6 standard (that is the standard which defines the Javascript language). As of mid-2017, one of the most important parts of ES6, importand export are not yet supported by default on any of the above mentioned platforms. And we already are talking about ES2016, ES2017 and future ES APIs. As of today, the ES5 specification is what all platforms have 100% support for.
If we consider ES5 as vanilla JS, then some of the most popular projects in Javascript are neither written, nor intended to be coded in vanilla JS. Among many others, the most commonly used languages (either entirely new, or variants of JS) that you’ll come across in the wild are -
- ES6/ES2015 : The standard we just discussed above. Since it is not 100% supported, we transpile it into ES5 and use it. As of 2017, everything except
import,exportare supported, andimport,exportas of now implemented via transpilers (using dynamic sync ES5require) are not exactly how the ES6 spec needs it to be (async and static). - Typescript: A language by Microsoft that is a super set of ES2017 (or ESnext), i.e. anything that will in future be surely part of Javascript, is already part of Typescript. It brings static+strong type checks into Javascript. The type checking happens during transpiling. So like Java/C#/ObjC, a new compile layer has been added to make the language safer
- Coffeescript: A relatively older ‘transpile to Javascript’ language, that tries to make writing Javascript code a little less painful by bringing in additional syntactical helpers. It has make breaking changes from ES6 API (for example the
for..ofimplementation). - Dart: Another transpile-to-JS language by Google. Has strong types. Was intended to be used in a browser called Dartium, which was like Chrome, but had runtime support for Javascript. Didn’t take off well, but Google is still pushing it for their new Fuchisa mobile OS and Flutter cross-platform SDK.
- JSX: A Javascript extension/DSL, that aims to create XML from Javascript. The syntax is close to (but not same as) Javascript, and the output of JSX is XML (which further can be used to generate HTML). A product of ReactJS ecosystem for creating web components purely using code (not writing HTML/CSS separately).
The ‘setups’
There was a time when using Javascript meant writing code in <script>tags.
<html>
OMG MY NICE HTML PAGE !!
<script>
document.body.innerText += "Now it is not nice anymore. Bwahaha"</script></html>
Now a days, most Javascript projects will involve your code passing through 3–4 entities, and turning into something you don’t recognise before loading piecemeal into your browser and then running in an order you didn’t define. How did we get here ? Let’s take a step back and figure out.
- Node vs Browser — The way to handle multiple js files is different. In Node we use
module.exportsandrequire. In browsers we simple insert multiple<script src='/path/to/file.js'>tags to use multi-file JS. The internal technical difference is that there are modules and scripts. Browser always evaluates in script form (unless you are reading this post 2017, and your browser already has module support). NodeJS almost always tries module form. - Babel — So developers figured, since ES2016 and ES2017 are being discussed, and we already know what will come in future JS versions, why not start writing them today ? After all, once the spec is ready, Google, Mozilla and Microsoft will have to implement it some day. So we already have started writing code in ES6, ES2016, ES2017 and ESnext. But how to run on current platforms? Babel transpiles your future Javascript into current-day ES5 form.
- Webpack (or Rollup or Browserify)— Developers like modularising. But network has latency. How about we modularise. And then when using the website, all the js is in once script.js, all the CSS in one style.css file ? Webpack (and it’s competitors), do that for you. It creates chunky bundles with consolidated code. Tree-shaken (look up the dependency graph and remove libraries/files not linked to or used), flattened, module-less large bundles are created.
We’ll continue with NPM, and other features of the language in the next part.
Next part is out — https://medium.com/@championswimmer/learning-javascript-the-proper-way-in-2017-part-2-the-tools-e500ea6efb57
