The year 2015 was pretty tiring in the JavaScript world. This was widely acknowledged and read to JavaScript Fatigue being “a thing” and there were memes on how hard it was to make a hello world in JavaScript.

I also chimed in about not learning any JavaScript, just because learning modern PHP seemed like more stable investment for my time.

Luckily midway through to 2016 it seems like the JavaScript world is coming more attractive again. The constant flow of new build tools has stopped as has inventing languages that compile into JavaScript. The 60 FPS thingamajig of the week no longer sparks the excitement it did a year ago.

There will always be people that will be attracted by technologies like Clojurescript, Elm or whatever is up on Hacker News — and we need these people! But for the large mass of developers that just want to get sh*t done in a rightish manner the cutting edge is irrelevant. In fact, it can be downright harmful for creating projects that need to be maintained for years to come.

The JavaScript landscape is becoming productive again, with things no longer deprecating in a weeks time.

The language and ecosystem have come of age

The JavaScript hype train has ran out of steam and the community has started sharing many core concepts and methods. This is a pattern that was repeated not that long ago in the JavaScript community, when everyone pretty much standardised on jQuery over Prototype.js or MooTools.

Now in 2016 JavaScript is exciting again since instead of constant yak shaving, we can finally focus on solving real problems. If you’ve not been working with JavaScript for a while, then I suggest you forget everything you knew.

Below are some concepts and tools that are now what constitute the core of contemporary, post 2015 JavaScript:

Transpiling : JavaScript has become a compiled language. Instead of compiling down to binaries or bytecode, we compile down to a widely supported version of JavaScript. Currently ES5 is the version broadly supported by browsers. The three major transpilers Babel, Traceur and TypeScript* are all very similar in practise.

: JavaScript has become a compiled language. Instead of compiling down to binaries or bytecode, we compile down to a widely supported version of JavaScript. Currently ES5 is the version broadly supported by browsers. The three major transpilers Babel, Traceur and TypeScript* are all very similar in practise. ES6 Syntax : ECMAScript is the language specification behind JavaScript. ES6 (also known as ES 2015, but the name never catched on) introduced a number of needed improvements to the core JavaScript language, from syntax tweaks to large features like Classes (see below) ES6 makes writing JavaScript less painful. Thanks to transpilers you can (and should) use this syntax and features starting from today.

: ECMAScript is the language specification behind JavaScript. ES6 (also known as ES 2015, but the name never catched on) introduced a number of needed improvements to the core JavaScript language, from syntax tweaks to large features like Classes (see below) ES6 makes writing JavaScript less painful. Thanks to transpilers you can (and should) use this syntax and features starting from today. Classes : A part of ES6 was the introduction of old school classes to the JavasScript language. While it maybe just syntactic sugar and JavaScript continues to be prototypal behind the scenes, the community seems to have agreed that the traditional class syntax in JS (with extend and all) is easier to reason about and immediately familiar to developers with an OOP background.

: A part of ES6 was the introduction of old school classes to the JavasScript language. While it maybe just syntactic sugar and JavaScript continues to be prototypal behind the scenes, the community seems to have agreed that the traditional class syntax in JS (with extend and all) is easier to reason about and immediately familiar to developers with an OOP background. Build tools : There are a number of build toolchains out there, these do everything from transpiling, linting to minifying the code. Grunt, Gulp and WebPack are not direct equivalents but are the big three of this genre. If a project already has one of these, changing it will likely yield little results. For new projects I’d use the default one your library or framework suggests.

: There are a number of build toolchains out there, these do everything from transpiling, linting to minifying the code. Grunt, Gulp and WebPack are not direct equivalents but are the big three of this genre. If a project already has one of these, changing it will likely yield little results. For new projects I’d use the default one your library or framework suggests. UI components : On the UI end of JavaScript, it’s now widely accepted that application interfaces should be built out of a tree of components. Ranging from Angular2 to Riot.js to React to native web components (with polyfills), you should now design your UI to be a set of components that are hierarchical. Not a random input box here, another one there; a common anti-pattern in the jQuery era.

: On the UI end of JavaScript, it’s now widely accepted that application interfaces should be built out of a tree of components. Ranging from Angular2 to Riot.js to React to native web components (with polyfills), you should now design your UI to be a set of components that are hierarchical. Not a random input box here, another one there; a common anti-pattern in the jQuery era. Asynchronicity **: For async handling this there are a number of methods like Callbacks, Promises, Generators, Observables and Async/Await. Out of these Callbacks are now obsoleted and it’s widely agreed that Generators are powerful and necessary for library development, but other options are more accessible in higher level development. Async/await superb, but not yet widely supported.

**: For async handling this there are a number of methods like Callbacks, Promises, Generators, Observables and Async/Await. Out of these Callbacks are now obsoleted and it’s widely agreed that Generators are powerful and necessary for library development, but other options are more accessible in higher level development. Async/await superb, but not yet widely supported. Package management and Modules: For packet management in JavaScript NPM is now the standard for both Node.js and Front End development. The browser-only Bower slipping to be a marginal player. For creating modules the ES6 module specification and Node.js’s CommonJS format continue to be widely used. Browsers are also making progress in native ES6 module loading.

The above list is not comprehensive and there are tons of other things that could be included. Everything from Flow and TypeScript to functional programming concepts are relevant, but not required to work in the modern JavaScript ecosystem. The above things together with the improvements in browser APIs is what moved mainstream JavaScript beyond jQuery. I’ll take this over CoffeeScript any day of the week!

On top of these there are heated discussions on superiority of frameworks and libraries. It’s worth noting that these are all higher level issues than the common conventions used at a lower level. Comparing to the PHP world — there are still developers working with Laravel, Zend of Symfony. But all of them have standardised on low level recommendations (PSRs) for autoloading and Composer for package management.

Choosing between Babel and TypeScript for transpiling or preferring between an opinionated framework like Angular2 or a collection of libraries like React*** is continues to be a matter of taste. But which ever one of these you choose now all build on the ES6 syntax that is compiled down to ES5.

The fragmentation and volatility that was present for a years is fading away and concepts familiar to PHP developers are taking hold. And with the backwards compatibility of JavaScript itself, we can rest assured that our horrible JavaScript legacy kludges from 2015 will continue to work in the future as well.

The JavaScript reboot is over. Now move forward and build great things!