Thread about ES6 on reddit

Christoph Martens cmartensms at gmail.com
Tue Aug 12 10:27:45 PDT 2014


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


More information about the es-discuss mailing list