I'm not sure that it makes sense to include an EventDispatcher with the vanilla transpiler. So many JS libraries have their own implementations of events. I wonder if developers would be expecting one to be included, or if they'd prefer pull in an existing library.
- Josh On Thu, May 28, 2015 at 11:14 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 5/28/15, 10:43 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote: > > >ES5 is my preference too. I think ES6 would be interesting because the > >code > >would look a bit closer to AS3, but with the polyfills and the > >implementations in browsers being pretty new still, I'm wary of adopting > >it > >at this point in time. > > OK, so I think that means that we use some other thing instead of > goog.inherit. > > Do we also want to trade in goog.require/provide for RequireJS, AMD, or > something else? > > What should we do about dispatching events on non-DOM objects? We have > that in AS and I think folks will want that in JS. Early on, I had a > simple implementation of EventDispatcher for non-DOM objects. We could go > back to that, but then that’s just another chunk of code that needs to be > debugged. Events for non-DOM objects is pretty simple because it doesn’t > have to worry about bubbling. > > Erik points out that the Closure JSDoc annotations help the minifier. I > think the output of FalconJX can still generate the Closure JSDoc, or is > there some other minifier that we want to use that uses different > annotations? > > So, in the net, we are only swapping out goog.inherit for now? I think > that’s ok with me. > > -Alex > >
