Is JavaScript still dead?

TLDR; Yes. But its successor is still called JavaScript, except when it isn't.

The long, slow death and resurrection of JavaScript

Back in my 2015 programming languages post I observed that, while JavaScript had pushed its way back into the top 10 programming languages, over at TIOBE, it was still a dead language walking. My reasoning was that the JavaScript of 2016 was going to be a very different language from that of 2013 - something more like Typescript than the JS we knew of old.

So what is the JavaScript of 2017? Basically, it is 95-97% of ECMAScript 6 (ES6).

Most current "evergreen" browsers have very high levels of support for ES6, and unless you have audience-specific reasons to support very old browsers, you can bet on ES6. (Even if you have to support IE11, you can use Typescript + core-js for the most common subset of ES6 features).

What does ES6 give us that previous versions didn't? Well, loads. Amongst other things, proper support for classes, modules, collections, promises, arrow functions (lambda-like syntax).

ES6 is starting to feel like a language designed for "everyday use" by "developers" using "tools". And that is really the big change in the last year or so - tooling support. Visual Studio (with or without ReSharper), VS Code, Sublime, WebStorm all offer increasingly high-quality JS development tooling with intellisense/completion and refactoring. Debugging and inspection are getting better, and the changes being made to the language are often designed to support better tooling.

That said, there is a long way to go. The (optional) static typing offered by Typescript makes tooling much simpler to build (and, arguably, code more maintainable), for example, but type annotations in ES.Future are a hotly contended topic, and the approach to annotations in e.g. Typescript and Clojure are quite different: the miraculous escape from the car crash that was standardized Promises is unlikely to happen again, and the consequences of that need to be well thought through.

Standard libraries, examples, and the problem of copy and paste

Websites download hundreds of kilobytes of JS just to do things that have been part of the standard DOM for years now. Yes, JQuery does a lot of useful stuff, normalizing across quirky browser implementations for all sorts of situations, but still most people use it 99% of the time to do querySelector() or querySelectorAll(). Libraries for Module loading and collection manipulation are other principal offenders in download size.

"It's only a few hundred kilobytes" people say - and that's true. But it is the time to parse and execute all that at startup that is the real issue. How many sites do you visit that take forever gazing at a white screen before they can render any above-the-fold content? On mobile that can be particularly bad, and is the antithesis of progressive enhancement.

But why do people not take advantage of the facilities available to them in all current, popular, supported browsers? Culture. There is a huge amount of example code out there on the web (StackOverflow) that uses legacy techniques and libraries; hundreds of components that depend on JQuery or Module libraries or whatever. And developers just copy and paste it in, dragging the libraries through.

We need to encourage more "dependency free" libraries, and ES6-native implementations, and we need those driving the standards bodies to accelerate the process of expanding the standard libraries so no one has to download that stuff (good progress is being made in ES7 and beyond, on that front).

Polyfills

Polyfills seem like a panacea - new features in old browsers. The problem is that usually they are expensive, badly implemented (or, more generously, not "fully featured") and heavyweight. Try to avoid using features that require polyfilling on one or more evergreen browsers.

Typescript and transpiled languages

Last year, I predicted the demise of Coffeescript (which is certainly on the way out), and other transpiled languages, but focused more on Typescript. In many ways, Typescript has become the proving ground for future ECMAScript features (arrow functions, strong typing, native modules etc.), and is a great way of writing code in a forward-compatible way. The TS you wrote a year or so ago, and transpiled to ES5 can now be transpiled to ES6 and take advantage of the new native features.

In 2017, and beyond, I would still recommend using Typescript for all your projects; it is a great programming experience with modern tooling, and has that baked-in future proofing. ECMAScript is an evolving language, still closer to its infancy after all this time, than it is to its maturity.

Call to action

1. Use ES6
2. Use modern DOM features
3. Verify supported features using caniuse and ES6 Features
4. Don't drag in massive polyfills for unsupported features - find another way
5. Use modern tooling
6. Treat it like any other code. Lint it, curate it, don't hack it. Be warning free.
7. Use Typescript
8. Don't use external libraries unless there is no other choice
9. Deprecate old answers on Stack Overflow that use the old idioms
10. Think before you copy and paste