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.giammar...@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 <ecmascr...@cscott.net> > wrote: > >> On Tue, Aug 12, 2014 at 8:17 PM, Andrea Giammarchi >> <andrea.giammar...@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 >> > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
