Thread about ES6 on reddit

C. Scott Ananian ecmascript at
Tue Aug 12 10:42:49 PDT 2014

I wonder to what extent the "clean break with the past" folks actually
write/maintain client-side software used by millions of people on the
web.  I work at the Wikimedia foundation, and I can testify that in
backend code we *love* es6 (and es6-shim), but if the front end code
isn't ES3-compatible there are millions of people, often disadvantaged
ones, who can't use our work.  We keep statistics, and we deprecate
browser support when we can, but our current standard is that we
support all browsers with > 0.1% market share.  (It used to be 0.01%.)

for a longer discussion of our browser support policy.

On Tue, Aug 12, 2014 at 6:27 PM, Christoph Martens <cmartensms at> wrote:
> On 12.08.2014 11:01, Andrea Giammarchi wrote:
>> I see Python 3 as an excellent example plus Mozilla has JavaScript
>> versioning since quite ever plus we have WebComponents and the ability to
>> put <es6-script> in place or flags in nodejs ... you name it, we had way to
>> think about the "how to" but it was possible.
>> Accordingly, it's not that I am talking about Disneyland or I live in
>> wonderland (thanks in advance @horse_esdiscuss), I am just saying there was
>> a chance to fix the broken part and we didn't take it while other languages
>> did but we have also way more tooling **and** we are pushing for tooling
>> regardless because of syntax incompatibility.
>> Once writing scripts won't be that straightforward anymore and multiple
>> tools and layers **must** be used in the middle, we are in the same position
>> Dart, CoffeeScript, TypeScript, or AnyOtherScript transpiler are, except
>> these fixed annoying known inconsistencies and they have, indeed, their own
>> counter-part library translated for their dialects.
>> Last but not least, I'd like to underline that my disappointment does not
>> come from ES6 or even ES7 ideas and features, rather the fact ES6 could have
>> been much more than just sugar, it could have been a better JS in its whole.
>> I also understand this rant, at this point, is quite pointless ... but
>> worth writing it down for the sake of laughing about it in the future, or
>> regretting we didn't do this way already.
>> Best Regards
> I think I have pretty much the same view as Andrea.
> Back then, the w3c discussions about HTML5 were pretty much the same.
> On one side, they introduced an all-new invalid-to-old-browsers doctype
> (<!doctype html>) which was SGML based and not valid against any xml-based
> schema validator. There was a huge discussion about the quirks mode
> behaviours, but from my view it was the ideal chance to make a cut to the
> old shitty APIs. As this was the single dependency for new html5 modes
> inside browsers (that were later on introduced in all browsers), it was also
> the ideal place to make a cut.
> If they would've decided to deprecate <marquee> and all that shit, we now
> would have a better DOM, a better BOM and a better markup in the first
> place. But the reason for not breaking it was "what happens with old IE that
> doesn't know HTML5 doctype" question.
> I mean, seriously? Is a crappy old software a valid reason for preventing an
> evolution of a specification or language? Should it be that way? I think
> not.
> On the other hand, I think the idea behind IE's different engine modes were
> a genius idea to fix the legacy problem. But the implementation and usage
> was a hard fail. Decisions like "all websites from a local area network are
> served by MS exchange anyways" is like totally idiotic.
> That's why I lately came up with the question why "use strict" was not
> something like "use es5" in another thread. Mostly all languages that
> successfully didn't break legacy code have either a modular extension system
> (e.g. ARB extensions in OpenGL) or version identifiers where you can
> validate your API usage against.
> I personally see no other ways on how to fix legacy problems otherwise.
> Humans are not perfect, they make mistakes. But you can fix mistakes only
> later in time. If you limit yourself by preventing to fix those mistakes in
> a language design (that is used by probably millions on the planet), you
> will end in either function signature hell (where we are right now) or in
> amount(static_methods) > 65k.
> I also think that the existence of transpilers is only valid because the
> underlying language designs failed to merge it into the core of the language
> and the language itself is not modular enough.
> If you need traceur or typescript in order to "really use" ES6 nowadays, I
> see it as a design flaw in the language. Of course, it is hard to locate the
> problems, but I think with a modular system like in OpenGL extensions, we
> may have a valid solution for it.
> Imagine sth. like require('Array', 'es5.1'); - but in order to get something
> like that we need features for the parsers to "ignore" a code block, similar
> to macros in other languages. Also, it is time to have a spec for operators.
> Otherwise we will never be able to really implement custom Primitives
> ourselves.
> Cheers,
> ~Chris
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list