ES2015 Is Here. Now What?

ECMAScript 2015 (ES6) was officially finalized this week. After six years since ES5, JavaScript has classes, modules, arrow functions, promises, and dozens of other features. This should feel momentous, but the reality is most developers have been using these features for months via Babel.

The standard finalizing doesn't change what we write—it changes the legitimacy of writing it.

What Actually Changed

From a developer's perspective, nothing changes today. Browser support remains spotty. Transpilers are still necessary. The code you write tomorrow looks like the code you wrote yesterday.

What changed is certainty. Features that were "proposed" or "in development" are now "standard." Code written with ES2015 won't become obsolete because the spec changed. This stability matters for long-lived applications.

The yearly release cycle also changes. Instead of waiting years for the next version, we get annual updates. ES2016 is already being developed. This cadence keeps JavaScript evolving without massive disruptive changes.

The Browser Support Reality

Current browser support for ES2015 features is incomplete:

Chrome: ~50% of features
Firefox: ~70% of features
Safari: ~55% of features
Edge: ~75% of features (Microsoft's new browser)
IE11: ~15% of features

Full browser support is years away. Even when browsers implement ES2015, supporting older browsers means transpiling indefinitely.

This makes ES2015 a compile target, not a runtime assumption. Like CoffeeScript before it, except ES2015 is the standard and CoffeeScript is just a language that compiles to JavaScript.

The Features That Matter

ES2015 includes dozens of features. Which ones are actually valuable?

Arrow functions – Cleaner syntax, lexical this

const double = x => x * 2;

Template strings – String interpolation finally

const message = `Hello, ${name}!`;

Destructuring – Extract values cleanly

const { name, age } = user;
const [first, ...rest] = array;

let and const – Block scoping fixes var's weirdness

let x = 1;
const y = 2;

Classes – Syntactic sugar over prototypes

class Rectangle extends Shape {
  constructor(width, height) {
    super();
    this.width = width;
  }
}

Modules – Native import/export

import { foo } from './module';
export default MyClass;

Promises – Standardized async pattern

fetch('/api/user')
  .then(response => response.json())
  .then(data => console.log(data));

These seven features cover 90% of real-world usage. The remaining features (generators, symbols, proxies, etc.) are powerful but niche.

The Module System Question

ES2015 modules are the standard, but they don't work in browsers yet. So we're in a weird state:

Write: ES2015 modules (import/export)
Compile: To CommonJS (require/module.exports)
Bundle: With webpack or browserify
Run: Transpiled CommonJS in browsers

This works but feels like we're going in circles. We're writing future syntax, compiling to current syntax, bundling for deployment. Multiple transform steps for what should be simple.

When browsers support ES2015 modules natively, we can skip transpilation. But that's years away, and even then bundling might be necessary for performance.

The Classes Debate

ES2015 classes are controversial. They're syntactic sugar over prototypes, not a new object model. Proponents say they make JavaScript look like other languages, easing adoption. Critics say they hide prototypes' flexibility and create false expectations.

My take: classes are fine for typical object-oriented patterns. But understanding prototypes still matters for advanced usage. Classes are convenience, not replacement.

The debate reveals tension between "JavaScript should be like Java" and "JavaScript's prototypes are its strength." ES2015 tries to serve both, which satisfies no one completely.

The Learning Curve Expansion

ES2015 adds dozens of features. New developers must learn both ES5 (what runs) and ES2015 (what's written). Tutorials mix them inconsistently. "Modern JavaScript" becomes a moving target.

This creates fragmentation. Old code uses var and function. New code uses const and arrow functions. Same language, different idioms. Reading others' code requires understanding both.

Over time, ES2015 becomes the baseline. But the transition period is confusing, especially for beginners.

What's Next

The yearly release cycle means ES2016 is already being developed. Proposed features include:

async/await for cleaner async code
Decorators for metadata and transformation
Class properties
Object spread/rest

These build on ES2015's foundation. The pace of evolution accelerates rather than slows.

This is good for language development but exhausting for developers. JavaScript is no longer stable—it's constantly evolving. Keeping up is work.

Practical Implications

For teams building applications:

Keep transpiling. Browser support isn't here. Babel remains essential.

Learn ES2015 gradually. Focus on high-value features first (arrows, const/let, destructuring, promises). Advanced features can wait.

Update tooling. Ensure linters, editors, and build tools understand ES2015.

Consider trade-offs. Using every feature isn't necessary. Pick what improves your code.

Expect change. ES2016, ES2017, etc. are coming. The language evolves continuously now.

Looking Forward

ES2015's finalization is significant symbolically but not practically. We've been using these features; now they're official.

The real change is JavaScript's transformation from static language to evolving platform. Annual releases, active development, continuous improvement—this is new for JavaScript.

Whether this benefits developers or creates churn depends on how the community manages change. Stability matters as much as features. The balance will define JavaScript's next era.

For now, celebrate ES2015's finalization, then get back to writing Babel-transpiled code. The future is here; it's just not evenly distributed yet.

Resources:

ES2015 Specification – Official spec
ES6 Compatibility Table – Browser support tracking
Understanding ES6 – Book by Nicholas Zakas