On Thu, May 28, 2015 at 12:29 PM, Alex Harui <aha...@adobe.com> wrote:
> In one post on another thread today, Josh indicated it would be acceptable > to have a dependency on goog at least for now just to have something to > play with. And having a limited amount of goog in the output meets my > needs so there are two customers who at least want to try the same thing. > > IMO, you have to find a way to control the order all of these classes get > set up, and you can roll your own or wait for ES6 or use one of the > established mechanisms. And as soon as you choose one of the established > ones, you have a framework dependency and aren’t quite so vanilla anymore. > In randori, I wrote a binary tree dependency check that sorted and worked, putting the non dependents ABOVE the dependnets in a list. The problem here is that was one monolithic file, the other config Mike had for individual files used his own custom loader system. Since people will want individual files for at least debugging, it seems goog is the only option for now. > > I will not be surprised if FlexJS customers start asking for RequireJS > instead of goog.require and then we’ll probably create an emitter for > that. Unless everybody moves to ES6 modules first. > The way it is,the dependency emit should be encapsulated from the rest of the emitter IMO. That way we can switch out down the road, but I need to get into this code and see how embedded goog is in the rendering structure. > > I think we could choose to stick with goog.require and not use > goog.inherit and use Object.create instead. > Ok, I will do this, that is the Babbel output. Mike > > -Alex > > > On 5/28/15, 9:12 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote: > > >So staying on ES5 means still using goog correct? Josh did mention he > >would > >prefer not to have that dependency, so that means there has to be > >alternatives to all your list items. > > > >So really in the JXEmitter's(Josh's use case) case I see an inheritance > >and > >accessor "solution"(Babble outputs) but I don't see a dependency loader > >solution. I am missing something? > > > >I wish I was more knowledgeable in this area but sadly I am not. :) > > > >Mike > > > >On Thu, May 28, 2015 at 12:05 PM, Frédéric THOMAS > ><webdoubl...@hotmail.com> > >wrote: > > > >> You probably right, actually I was a bit dreaming I think :) > >> In more it would mean that all the JS libraries we would use under the > >> wood would have to be packed in ES6 modules, not sure we could do that. > >> > >> Now yes, I 'm curious too on what others think about emiting in ES5. > >> > >> Frédéric THOMAS > >> > >> > From: aha...@adobe.com > >> > To: dev@flex.apache.org > >> > Subject: Re: [FalconJX][FlexJS] Do we still want to use Google Closure > >> Library? (was Re: [FalconJX] JXEmitter accessors) > >> > Date: Thu, 28 May 2015 15:58:15 +0000 > >> > > >> > > >> > > >> > On 5/28/15, 8:40 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> > >>wrote: > >> > > >> > >Oops, > >> > > > >> > >Hmm, so at this point, why not emiting ES6 syntax and use ES6 > >>polyfills > >> > >from babel ? > >> > > >> > Possible. I’m willing to go in this direction if that’s what folks > >>want > >> > to do, but I always get nervous when I hear about polyfills. I’d > >>rather > >> > avoid polyfills and just stay on ES5 unless there is a huge win. That > >> way > >> > you don’t have to: > >> > > >> > 1) figure out when to load the polyfill > >> > 2) worry about bugs in the polyfill > >> > 3) have different debug experiences in different browsers > >> > 4) bundle the polyfills in the release > >> > 5) manage the licenses and other documentation around the polyfills. > >> > > >> > > >> > Also, IIRC, way back, it seemed like many folks have locked into a > >> > favorite JS loading mechanism like RequireJS. We are using > >>goog.require. > >> > Going to a different ES6 module scheme may cause more resistance from > >> > folks wedded to a particular loading scheme. > >> > > >> > But I’ll go with what the majority wants. > >> > > >> > -Alex > >> > > >> > > >> > >> > >
