damn if (typeof obj === 'object' && obj === null) of course ...
On Tue, Aug 12, 2014 at 8:17 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> 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 Regards
>
>
>
>
> On Tue, Aug 12, 2014 at 6:42 PM, C. Scott Ananian <ecmascr...@cscott.net>
> wrote:
>
>> 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 http://lists.wikimedia.org/pipermail/wikitech-l/2014-July/077824.html
>> for a longer discussion of our browser support policy.
>> --scott
>>
>> On Tue, Aug 12, 2014 at 6:27 PM, Christoph Martens <cmarten...@gmail.com>
>> 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@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
