Thread about ES6 on reddit

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Aug 12 12:49:36 PDT 2014


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 Regards



On Tue, Aug 12, 2014 at 8:41 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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.
>
>
>
>
> On Tue, Aug 12, 2014 at 8:28 PM, C. Scott Ananian <ecmascript at cscott.net>
> wrote:
>
>> 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,
>>
>> https://github.com/google/traceur-compiler/issues/909
>>
>> > 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.
>>   --scott
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140812/b229934c/attachment-0001.html>


More information about the es-discuss mailing list