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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
