Thread about ES6 on reddit
I think there are books with high value and quality out there and not necessarily talking Web and jQuery only but I also agree that once decided ES7 would have broken native syntax compatibility with older engines, it could have been a chance to also fix all the well known gotchas of the languages because transpilers could fix those too.
We can create generators in ES3 engines, we don't want to fix inherited broken specs or features ... I never understood this, regardless what I think about ES7 in its whole.
Christoph Martens wrote:
But on the other hand I sold all my JS books, because they are worthless.
Sorry you bought the wrong books. Try these:
Andrea Giammarchi wrote:
but I also agree that once decided ES7 would have broken native syntax compatibility with older engines, it could have been a chance to also fix all the well known gotchas of the languages because transpilers could fix those too.
We've been over this many times. Making a versioned break means opt-in versioning, which means now you have two big problems. You still have to compile to ES3 for old browsers, but that's vacuously true in any case. The problems of old code enduring, and intersection-compatible "any version" code likely predominating, don't go away.
1JS won for many reasons but this is the high-order-bit reason.
I'd like to point to the grand experiment of python 3 to introduce a new language, that breaks with the old one. This didn't work out to be exactly popular, and to this day, python 3 struggles to gain acceptance.
A major roadblock for python 3 is that you cannot combine it with python 2 modules. This makes it impossible to perform a piecewise transition of your code. You're faced with either of two choices, support the old version and go trough the hassle of transpiling/breaking it on the new version. But at least it works for most people. Or target the new version, and go trough the hassle of transpiling/breaking it in the old version, but as a reward, you get nearly zilch people for whom it'll run.
This all could've been avoided if it had been possible to combine the python 2 and python 3 in a single VM.
And I believe that'd be a promising thing to do for javascript. If you really want to make a new version, that's incompatible with the old version, then make sure people have a viable migration strategy. And that strategy is being able to continue using whatever code has not been updated to the new version, while starting to write code for the new version.
On Aug 11, 2014 2:22 PM, "Brendan Eich" <brendan at mozilla.org> wrote:
Christoph Martens wrote:
But on the other hand I sold all my JS books, because they are
worthless.
Sorry you bought the wrong books. Try these:
www.informit.com/store/effective-javascript-68-specific-ways-to-harness-the-9780321812186
/be
Flanagan's Rhino book is excellent IMO.
Brian Kardell wrote:
[No reply text from you?]
On Aug 11, 2014 2:22 PM, "Brendan Eich" <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote:
Christoph Martens wrote:
But on the other hand I sold all my JS books, because they are worthless.
Sorry you bought the wrong books. Try these:
www.informit.com/store/effective-javascript-68-specific-ways-to-harness-the-9780321812186
Last link was in lieu of
which had a DNS outage -- it's back now.
"Many times", and still does not make sense to me.
CoffeeScript and TypeScript added new things and solved others while new ES6 syntax is simply broken not only in ES3 but in ES5 too and requires same technique (transpiler) others used to solve many other gotchas too.
Why "we" demand the web to transpile but "we" don't solve problems
known since 1999 is still a mystery to me ... specially every time you end
your replies writing 1JS ... in my opinion a meaningless utopia the
moment TC39 decided to break backward compatibility.
Best
Andrea Giammarchi wrote:
"Many times", and still does not make sense to me.
CoffeeScript and TypeScript added new things and solved others while new ES6 syntax is simply broken not only in ES3 but in ES5 too and requires same technique (transpiler) others used to solve many other gotchas too.
Rehashing, I addressed this explicitly in words you bottom-cited.
In your proposed alternative, as in ES6, a compiler is needed to target old browsers. No difference.
Why "we" demand the web to transpile but "we" don't solve problems known since 1999 is still a mystery to me ... specially every time you end your replies writing
1JS... in my opinion a meaningless utopia the moment TC39 decided to break backward compatibility.
You can't "solve the problems known since 1999". You again ignored what I wrote about "old code enduring, and intersection-compatible "any version" code likely predominating".
Please read before you reply.
Brian Kardell wrote:
Flanagan's Rhino book is excellent IMO.
Ah, found your reply text (adjacent lines both >-prefixed and what's
with the trailing dunder-run?).
Yes,
shop.oreilly.com/product/9780596805531.do
is good too. 7th edition coming, I think!
I read that and still not convinced this is good for the web or developers.
Code will migrate to ES6, specially the one still maintained, and I am personally against unmaintained code used in new projects ... so we simply disagree in this basic concept: you believe that broken unmaintained library from 2000 should work in ES6, I believe that such code should not interfere with the future of the language specially after the language decided to "break up" with its past (syntax) ...
this looks like a "one way toxic relationship" to me, metaphorically speaking, a situation where only old code can benefit from instead of new comers and/or the future of the language itself.
Once again, my 2 cents ... we had a chance to make it better all over, we decided that old code should compromise the spec instead ... it's like still supporting IE6 when nobody would spend a second to fix IE6 instead, look how good that has been for the Web history.
Best
Andrea Giammarchi wrote:
I read that and still not convinced this is good for the web or developers.
Well, forget me. What did you think of Florian's argument citing Python 3 vs. 2 uptake problems? I see Perl 6 (full of great ideas that required a compat break) vs. 5 in the same light. Evolution is hard to beat.
I'd like to point out a example where using different sources (from older and newer versions of a language) inside one runtime environment is used fairly successfully.
Each OpenGL version comes with a new version of the GLSL language, which may break things. On top of my head this was the case in:
- varying -> in/out
- gl_FragColor -> gl_FragData[n]
- removal of builtins (such as gl_ModelView)
The first version of GLSL for a platform does not require marking up with a version (as in OpenGL 2.0, OpenGL ES 2.0). Subsequent versions required the version directive "#version XXX" on top of the source file, if they wanted to use later iterations of GLSL.
The advantage of that was that all engines/libraries/snippets you might've used keep working, even as you start using the newer version and gradually fade out support/development/dependencies for older versions.
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
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
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.
On Tue, Aug 12, 2014 at 10:27 AM, Christoph Martens <cmartensms at gmail.com> wrote:
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>)
<!doctype html> was "invalid" per spec, but accepted by all browsers
as valid. It was the minimum sigil that was accepted by existing browsers and produced standards-mode. It was not an innovation that took any time to adapt to.
which was SGML based and not valid against any xml-based schema validator.
No major browser has ever been SGML-based or used an XML schema validator in any capacity, so this is irrelevant.
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,
They did deprecate <marquee>. It's still required to be supported, as
it's used on the web, but it's not valid for authors to use. A number of other old features are treated the same.
we now would have a better DOM,
Deprecating <marquee> would have no real effect on the DOM. It's just
one self-contained interface; it doesn't affect anything else. There are some improvements that would have made the DOM much better, but they're less obvious (like killing document.write, for example).
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.
And all other old browsers.
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.
Regardless of what's valid for new things in the future, old things still exist, and there are a LOT of old things. That means you have to support the old things as well as the new things; all those deprecated things still have to sit in your code if you want to render the old things correctly. The cost of making an incompatible version is that you now have to maintain two code branches, one for the old stuff and one for the new stuff, and keep them synchronized for security fixes and the like. It's rarely worth the benefit.
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.
IE is handicapped by their decision; they have to send 6 or so rendering engines in their browser now, or spend time emulating an older rendering engine in a newer one, reproducing its bugs and quirks as well as they can.
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.
The "nowadays" you mention doesn't mean "now, and forevermore", it's "now, and for a short time as support catches up to the new features".
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 lists.wikimedia.org/pipermail/wikitech-l/2014-July/077824.html for a longer discussion of our browser support policy.
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 break.
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
damn if (typeof obj === 'object' && obj === null) of course ...
On Tue, Aug 12, 2014 at 8:17 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
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.
I look forward to a transpiler that will support >= 99.9% of our
visitors. We feel this is a moral imperative for our work.
And I completely agree with that and either fixing or non fixing ES3 known problems you will still looking forward for that transpiler.
Bad news, it would be very easy to fix ES3 in ES6 while it's kinda
hard/improbably to implement Object.observe, generators and await in
ES3 ... so this is the major point I am talking about: ES6 has broken with
its past already deciding to adopt incompatible Syntax and patterns
(generators/await "pauses" or Proxy and Object.observe feature)
ES6 requires tools in the middle by default because nobody wants to break the web ... this tooling could have been the key to also solve, in modern code, old gotchas, because modern code must be transpiled into old one ... if we can spit between old code, do not transpile it, and new one, must be transpiled, there won't be any "old library must work" problem because the old library code won't be touched, only the new code will ... and the the new code, using the old library in it, will trust its new nature and specs, and it will be transpiled to live happily ever after in ES3 and hopefully soon only ES5 browsers too.
Having compatibility with jurassic code in ES6 because we are apparently unable to transpile only new modules it's ... well, a pretty dumb assumption. I actually wouldn't mind a convention where me, as developer, put "use es6" as closure directive, and instruct the transpiler to parse only that code, instead of everything, if merged into one file.
I mean, that's the way I'd go anyway ... traceur does not suppport it? It can be added or fixed if necessary.
The only "not nice for browsers and engines" part I see is, potentially, a dual mode syntax/parser/execution with probably a double engine, the one already available compatible with ES3 and ES5, and the one eventually fully spec compliant with new specifications.
Not talking about 6 engines, but two ... enough for a graceful migration, not necessarily that bad to implement ... look at Dart and NaCLI, I mean Chrome already ships with multiple engines ... right? before and after ES6 would be just another one.
Once again, I think it's late, but also I think this was a huge opportunity for JavaScript.
Last thing before flames, reading back my last reply ... yes, I am simplifying the problem, but I've stated already we had time to think through this and make it work in a way or another ... "just another engine" does not bring justice to the work that need to be done in order to make this migration as graceful as possible the way I imagine (dream of).
Best
www.reddit.com/r/javascript/comments/2d4wed/can_you_explain_to_me_something_about_es6
This should please people worried about ES6 being perceived negatively: the tone in this thread is quite upbeat.