Hacker News Reader

Comment by charriu | Hacker News Reader

I'm a bit worried about ES6 making the language harder to understand.

For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?!

On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.

View on HN

Can someone explain the reasoning behind having any kind of backwards compatibility? Who would pick a worse-but-compatible ES6 over a better incompatible version?

For example, the scoping rules: why have two separate scoping rules for let and var? To put it another way, would ES6 have let and var with differing scoping rules if it was designed today? If not, then it's a flaw (any difference from what a clean redesign would look like I consider a flaw).

Why not just make a simple and consistent syntax?

What about it is not simple and consistent? Two different syntaxes, and two different expectations and rules. Var is function scope, and let is block scope.

I feel like in a new design you would pick one or the other, as a second scoping rule would not carry its own weight in terms of what problems it solves vs the complexity of implementing runtimes or learning the language. In that case I'm almost certain you would go for block only as it is the default in nearly all curly braced languages.

Yes, as a matter of style you could just use let everywhere, and know that var is there for legacy compatibility reasons.

I think they have selected one over the other - let. var exists for compatibility, but there is zero reason to use it in new code.

Python 3

Exactly what came to my mind

> Can someone explain the reasoning behind having any kind of backwards compatibility?

Not breaking millions of websites.

*billions.

Maybe even orders of magnitude more than that.

In what way would a cleaner ES6 break websites? Browsers aren't going to stop supporting ES5.

Browsers aren't likely to implement two separate languages either. Furthermore, forcing people to pick between "ES5" and "ES6" if they just want to use a single ES6 feature is pretty bad.

So your fundamental choices are really an ES6 that is backwards-compatible or an ES6 that is not used.

On the other hand forcing newcomers to learn the warts of ES5 when they could learn what is becoming a reasonably elegant language isn't ideal either. Two scoping rules, for example.

An ES-latest runtime + transpilers would be all that browsers needed.

This has in fact been debated back and forth on the es-discuss mailing list and in TC39, especially given experiences with strict mode. The decision was generally made to not have more modes and to just have a single JS language.

You don't have to agree with that decision obviously, but this isn't something that happened willy-nilly.

> I'm a bit worried about ES6 making the language harder to understand.

Welcome to C++.

Reply on news.ycombinator.com