Thread about ES6 on reddit

Andrea Giammarchi andrea.giammarchi at
Tue Aug 12 12:17:15 PDT 2014

I work at Twitter, mobile Web first and lately in TweetDeck, and while I am
not representing my company in this ML at all I write code for millions of
users daily and I don't see any problem in having an ES6 that solves old
ES3 gotchas because here the catch you probably missed: there's nothing you
have to do for your ES3 compatible browsers but the new software will be
transpiled in ES3 compatible code ... it's not the other way round Scott,
and I am not sure why you thought about it.

A very basic/simple example:
// your new ES6 code
if (typeof obj === 'null') {
  // obj === null, do stuff

// will be transpiled into
if (typeof obj === 'object' && obj !== null) {
  // obj === null, do stuff


So there's no clean break for the old browser we **all** want to keep
supporting, but there is rather a nicer, graceful, migration to a better
JavaScript, during which time browsers and engines will update and follow
new specs and syntax.

The moment you decide to serve full ES6 without transpiling it will be your
company, service, or dev choice, that day you decided regardless to break
with old browsers because the first one that will see a generator will

Do you want to use your old code within the new syntax mixing up both ?
Then you have to maintain such old code to play as you basically always
wanted with new ES standards so this would also be an occasion to clean up
some old code and if it's legacy you fear, you should have legacy tests in
place too to validate against and port that code, **only if you want to**,
to the new spec and transpile such old code too.

Otherwise you can serve what's ES6 as transpiled code, and what's legacy as
legacy ... the moment you'll use legacy in your new ES7 ready code, it's
part of the ES7 code indeed and as such will be, must be, transpiled into
ES3 or ES5 compatible browsers.

This way it's a win-win, the way TC39 decided, it's a lost for new comers,
the future of the language, and web potentials, also for all these
ever-green browsers that nowadays could catch up pretty easily on those
syntax differences.

Best Regards

On Tue, Aug 12, 2014 at 6:42 PM, C. Scott Ananian <ecmascript at>

> 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%.)
> See
> for a longer discussion of our browser support policy.
>   --scott
> 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
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list