<div dir="ltr">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).<div>
<br></div><div>Best Regards<br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 12, 2014 at 8:41 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">And I completely agree with that and either fixing or non fixing ES3 known problems you will still looking forward for that transpiler.<div>
<br></div><div>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)</div>

<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>I mean, that's the way I'd go anyway ... traceur does not suppport it? It can be added or fixed if necessary.</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Once again, I think it's late, but also I think this was a huge opportunity for JavaScript.</div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br>
<br><div class="gmail_quote">On Tue, Aug 12, 2014 at 8:28 PM, C. Scott Ananian <span dir="ltr"><<a href="mailto:ecmascript@cscott.net" target="_blank">ecmascript@cscott.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Tue, Aug 12, 2014 at 8:17 PM, Andrea Giammarchi<br>
<<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br>
</div><div>> the new software will be<br>
> transpiled in ES3 compatible code ... it's not the other way round Scott,<br>
<br>
</div><a href="https://github.com/google/traceur-compiler/issues/909" target="_blank">https://github.com/google/traceur-compiler/issues/909</a><br>
<div><br>
> and I am not sure why you thought about it.<br>
<br>
</div>I look forward to a transpiler that will support >= 99.9% of our<br>
visitors.  We feel this is a moral imperative for our work.<br>
<span><font color="#888888">  --scott<br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>