What Changed with ES6 and Later?

ES2015 was the largest single revision of the language, and it is the release that most people mean when they say ES6. The headline changes were block-scoped declarations, arrow functions, classes, template literals, destructuring, default and rest parameters, the spread syntax, modules with import and export, the new Map and Set collections, Symbol, generators, Promises, and the for...of loop.

// The older ES5 style.
var greetOld = function (name) {
  return 'Hi ' + name;
};

// The ES2015 style.
const greet = function (name = 'there') {
  return 'Hi ' + name;
};

console.log(greetOld('Ada')); // Hi Ada
console.log(greet());          // Hi there
console.log(greet('Bob'));     // Hi Bob

Two big ideas sit underneath most of those changes. The first one is that the language stopped treating functions as the only way to build reusable behaviour. Arrow functions made callbacks shorter, and classes gave object-oriented programmers a syntax they already knew. The second one is that moving data around became a first class job. Destructuring and spread let you pull values out of objects and arrays and put them back together, and that replaced a lot of index arithmetic and manual copying.

The later editions kept going in the same direction instead of replacing what came before. ES2018 added async iteration and object rest and spread. ES2020 added optional chaining and nullish coalescing. ES2021 added logical assignment operators. ES2022 added class fields and the at method on arrays. ES2023 added array methods such as findLast and toSorted. The theme is steady. There is less boilerplate, missing values are handled more safely, and working with collections feels more comfortable.

Because changing var would have broken the web. The keyword had been in every browser since 1995, and by 2015 an enormous amount of working code depended on its exact behaviour, including the strange parts that developers had learned to work around. Function scoping, hoisting, the global object as the default target, and the ability to declare the same name twice were all doing real work in real projects. Changing any of them in place would have turned a routine upgrade into a silent behaviour change on every site on the internet.

So the committee took the additive route. let and const arrived as new declarations with better rules, and var was left exactly as it was so that old code kept working. This is the normal pattern for a language with a huge installed base. You never change old behaviour, you add new syntax instead, and if you have to remove something you do it slowly.

The follow-up question you should be ready for is why both let and const were needed instead of just one new keyword. They differ in one important respect. A let binding can be given a new value, but the same name cannot be declared twice in the same scope. A const binding cannot be given a new value at all, so the name stays tied to that one value forever. That gives you two clear tools. Use let for values that really do change, and use const for bindings that never change.

There is also a benefit at runtime. The engine can tell a const binding apart from a let binding, and it can read a const binding faster because it already knows that the value can never change.