You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Alex Harui <ah...@adobe.com> on 2013/03/31 06:20:28 UTC
Google Closure Events (was Re: [FalconJx] progress update)
I read up a little on Google Closure Events. I was hoping to find some
information on why it takes that much javascript to implement a brand new
event model when it appears (at least from my perspective) that the only
rogue browser is IE8.
I think I'm going to forge ahead with my custom approximation of events in
IE8 and maybe I'll discover why Google Closure Events are better. I would
rather use a DOM Events API surface since that's what AS has and folks are
used to.
On 3/30/13 9:15 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Hi,
>
> From [1]: "Closure Library provides the advantage of a consistent
> event model that works the same way in all browsers."
>
> And the GC Compiler takes care of any overhead, it can very
> efficiently re-compile "goog" based Javascript. More so than "manual"
> JS like FlexGlobals. And we're using the GC Library anyways.
>
> I plan to look at the "insides" of FlexJS Javascript code next week,
> see what I can come up with. Maybe start a branch, we can do that
> easily now in git :-P
>
> EdB
>
>
>
> On Sat, Mar 30, 2013 at 5:00 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>
>>
>> On 3/30/13 7:54 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>
>>> I left out FlexGlobals on purpose, I plan to bring the Google Closure
>>> way of dealing with events to FlexJS. The GC way is not dependent on
>>> DOM based events and fits very snugly with the way Flex handles
>>> events.
>> BTW, do we need a DOM event for MouseEvents?
>>
>> Also, I was going to work on IE8 compatibility soon. Does Google Closure
>> events work well on ie8? How much overhead is there for using it?
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> One certainly could. But I don't know jQuery and I do know the Closure tools.
>>
> I will choose not to interpret this as your "my way or the highway"
> declaration. :-)
Just pointing out my limitations :-P
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Alex Harui <ah...@adobe.com>.
On 3/31/13 7:46 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>>> any day. And it's there for us to use, since we already require (pun
>>> intended) the Closure Library.
>> But one could use the same argument to say we should start with Jquery.
>
> One certainly could. But I don't know jQuery and I do know the Closure tools.
>
I will choose not to interpret this as your "my way or the highway"
declaration. :-)
I can certainly see that if I was to write a JS app that I would choose a
framework like Jquery or the closure library, but I see a different angle:
We are writing a parallel framework, so for me, I would rather use
addEventListener in both AS and JS and remember to use createProxy in JS
than use addEventListener in AS and listen() in JS or shim addEventListener
with listen() in AS. I think for those debugging generated code it will be
easier to see addEventListener in there as well, even though it has that
createProxy added to it. But that's just me. And it still depends on if I
can get the current code to work on ie8 in a day or two.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
>> any day. And it's there for us to use, since we already require (pun
>> intended) the Closure Library.
> But one could use the same argument to say we should start with Jquery.
One certainly could. But I don't know jQuery and I do know the Closure tools.
EdB
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Alex Harui <ah...@adobe.com>.
On 3/31/13 12:36 AM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Ok, I agree on the minimalist approach very much, but that doesn't
> exclude the use of a large library (sounds silly, but read on).
>
> On the merits of using 'goog' events: Gmail, Google Plus, Google Drive
> etc. This is a cross-platform, cross-browser, tremendously tested and
> proofed implementation. It drives some of what maybe the most used
> online applications. I'll take that over a "roll your own" solution
> any day. And it's there for us to use, since we already require (pun
> intended) the Closure Library.
But one could use the same argument to say we should start with Jquery.
>
> As to the code bloat: looking at the file sizes in the events
> directory is plain silly. That only goes for the 'intermediate/debug'
> release anyway, where size and speed play second fiddle to readability
> and ease of debugging. For the release we use (in both FalconJS and
> FalconJx) the Google Closure Compiler in advanced mode. This is a true
> compiler. The resulting output of that compiler only contains classes
> and methods that are actually used by the code, unlike what minifiers
> do, those include all the code, just reworked to remove whitespace and
> refactored to replace long names.
>
> I will build a FlexJS branch where I use the closure events so we can compare.
That would be great. And like I said, maybe as I try to get IE8 working
I'll realize why the Google version has what it has. For me, no matter who
else is using it and how well tested it is, I want to know what is in it and
that we aren't taking more than we need.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Ok, I agree on the minimalist approach very much, but that doesn't
exclude the use of a large library (sounds silly, but read on).
On the merits of using 'goog' events: Gmail, Google Plus, Google Drive
etc. This is a cross-platform, cross-browser, tremendously tested and
proofed implementation. It drives some of what maybe the most used
online applications. I'll take that over a "roll your own" solution
any day. And it's there for us to use, since we already require (pun
intended) the Closure Library.
As to the code bloat: looking at the file sizes in the events
directory is plain silly. That only goes for the 'intermediate/debug'
release anyway, where size and speed play second fiddle to readability
and ease of debugging. For the release we use (in both FalconJS and
FalconJx) the Google Closure Compiler in advanced mode. This is a true
compiler. The resulting output of that compiler only contains classes
and methods that are actually used by the code, unlike what minifiers
do, those include all the code, just reworked to remove whitespace and
refactored to replace long names.
I will build a FlexJS branch where I use the closure events so we can compare.
EdB
On Sun, Mar 31, 2013 at 8:11 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
>
> On 3/30/13 10:39 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
>
>> Alex, just checking before I spend too much time on this: with FlexJS, is
>> it always going to be "your way or the highway"?
> I don't think so. What gave you that impression? If it was the tone of my
> last post, I apologize. I am actually trying to start a discussion on
> technical merits.
>
> I do have a particular point of view. I am a code minimalist. I watched
> the current SDK get fatter and slower with all of this just-in-case code,
> and have helped dozens of folks try to optimize their apps after they wrote
> or added rich and powerful libraries and application frameworks that they
> didn't actually need. I definitely want to try to avoid that.
>
> I like to think I am open to input from others, but I am going to ask why
> your choice is the best choice. When you suggested moving to base.js, I
> looked at that file and didn't see any obvious reason to not use it, and we
> are.
>
> If I had opened up the events folder in google closure library and it was
> one 10K file, I wouldn't have even looked inside it, but it was 41K and
> required a whole bunch of other files, and then I saw that the API was
> different from DOM Events. I haven't tried it yet, but I still think it
> will not take that much code to handle IE8. I know you're busy this week,
> so my trying to hack IE8 might show me the excellence of Google's library.
>
> Sorry if I seem too obstinate. I definitely need everyone's help and input.
>
> -Alex
>
>>
>> EdB
>>
>>
>>
>> On Sunday, March 31, 2013, Alex Harui wrote:
>>
>>> I read up a little on Google Closure Events. I was hoping to find some
>>> information on why it takes that much javascript to implement a brand new
>>> event model when it appears (at least from my perspective) that the only
>>> rogue browser is IE8.
>>>
>>> I think I'm going to forge ahead with my custom approximation of events in
>>> IE8 and maybe I'll discover why Google Closure Events are better. I would
>>> rather use a DOM Events API surface since that's what AS has and folks are
>>> used to.
>>>
>>>
>>> On 3/30/13 9:15 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> From [1]: "Closure Library provides the advantage of a consistent
>>>> event model that works the same way in all browsers."
>>>>
>>>> And the GC Compiler takes care of any overhead, it can very
>>>> efficiently re-compile "goog" based Javascript. More so than "manual"
>>>> JS like FlexGlobals. And we're using the GC Library anyways.
>>>>
>>>> I plan to look at the "insides" of FlexJS Javascript code next week,
>>>> see what I can come up with. Maybe start a branch, we can do that
>>>> easily now in git :-P
>>>>
>>>> EdB
>>>>
>>>>
>>>>
>>>> On Sat, Mar 30, 2013 at 5:00 PM, Alex Harui <aharui@adobe.com<javascript:;>>
>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 3/30/13 7:54 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
>>> wrote:
>>>>>
>>>>>> I left out FlexGlobals on purpose, I plan to bring the Google Closure
>>>>>> way of dealing with events to FlexJS. The GC way is not dependent on
>>>>>> DOM based events and fits very snugly with the way Flex handles
>>>>>> events.
>>>>> BTW, do we need a DOM event for MouseEvents?
>>>>>
>>>>> Also, I was going to work on IE8 compatibility soon. Does Google
>>> Closure
>>>>> events work well on ie8? How much overhead is there for using it?
>>>>>
>>>>> --
>>>>> Alex Harui
>>>>> Flex SDK Team
>>>>> Adobe Systems, Inc.
>>>>> http://blogs.adobe.com/aharui
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Alex Harui
>>> Flex SDK Team
>>> Adobe Systems, Inc.
>>> http://blogs.adobe.com/aharui
>>>
>>>
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Alex Harui <ah...@adobe.com>.
On 3/30/13 10:39 PM, "Erik de Bruin" <er...@ixsoftware.nl> wrote:
> Alex, just checking before I spend too much time on this: with FlexJS, is
> it always going to be "your way or the highway"?
I don't think so. What gave you that impression? If it was the tone of my
last post, I apologize. I am actually trying to start a discussion on
technical merits.
I do have a particular point of view. I am a code minimalist. I watched
the current SDK get fatter and slower with all of this just-in-case code,
and have helped dozens of folks try to optimize their apps after they wrote
or added rich and powerful libraries and application frameworks that they
didn't actually need. I definitely want to try to avoid that.
I like to think I am open to input from others, but I am going to ask why
your choice is the best choice. When you suggested moving to base.js, I
looked at that file and didn't see any obvious reason to not use it, and we
are.
If I had opened up the events folder in google closure library and it was
one 10K file, I wouldn't have even looked inside it, but it was 41K and
required a whole bunch of other files, and then I saw that the API was
different from DOM Events. I haven't tried it yet, but I still think it
will not take that much code to handle IE8. I know you're busy this week,
so my trying to hack IE8 might show me the excellence of Google's library.
Sorry if I seem too obstinate. I definitely need everyone's help and input.
-Alex
>
> EdB
>
>
>
> On Sunday, March 31, 2013, Alex Harui wrote:
>
>> I read up a little on Google Closure Events. I was hoping to find some
>> information on why it takes that much javascript to implement a brand new
>> event model when it appears (at least from my perspective) that the only
>> rogue browser is IE8.
>>
>> I think I'm going to forge ahead with my custom approximation of events in
>> IE8 and maybe I'll discover why Google Closure Events are better. I would
>> rather use a DOM Events API surface since that's what AS has and folks are
>> used to.
>>
>>
>> On 3/30/13 9:15 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
>> wrote:
>>
>>> Hi,
>>>
>>> From [1]: "Closure Library provides the advantage of a consistent
>>> event model that works the same way in all browsers."
>>>
>>> And the GC Compiler takes care of any overhead, it can very
>>> efficiently re-compile "goog" based Javascript. More so than "manual"
>>> JS like FlexGlobals. And we're using the GC Library anyways.
>>>
>>> I plan to look at the "insides" of FlexJS Javascript code next week,
>>> see what I can come up with. Maybe start a branch, we can do that
>>> easily now in git :-P
>>>
>>> EdB
>>>
>>>
>>>
>>> On Sat, Mar 30, 2013 at 5:00 PM, Alex Harui <aharui@adobe.com<javascript:;>>
>> wrote:
>>>>
>>>>
>>>>
>>>> On 3/30/13 7:54 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
>> wrote:
>>>>
>>>>> I left out FlexGlobals on purpose, I plan to bring the Google Closure
>>>>> way of dealing with events to FlexJS. The GC way is not dependent on
>>>>> DOM based events and fits very snugly with the way Flex handles
>>>>> events.
>>>> BTW, do we need a DOM event for MouseEvents?
>>>>
>>>> Also, I was going to work on IE8 compatibility soon. Does Google
>> Closure
>>>> events work well on ie8? How much overhead is there for using it?
>>>>
>>>> --
>>>> Alex Harui
>>>> Flex SDK Team
>>>> Adobe Systems, Inc.
>>>> http://blogs.adobe.com/aharui
>>>>
>>>
>>>
>>
>> --
>> Alex Harui
>> Flex SDK Team
>> Adobe Systems, Inc.
>> http://blogs.adobe.com/aharui
>>
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: Google Closure Events (was Re: [FalconJx] progress update)
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Alex, just checking before I spend too much time on this: with FlexJS, is
it always going to be "your way or the highway"?
EdB
On Sunday, March 31, 2013, Alex Harui wrote:
> I read up a little on Google Closure Events. I was hoping to find some
> information on why it takes that much javascript to implement a brand new
> event model when it appears (at least from my perspective) that the only
> rogue browser is IE8.
>
> I think I'm going to forge ahead with my custom approximation of events in
> IE8 and maybe I'll discover why Google Closure Events are better. I would
> rather use a DOM Events API surface since that's what AS has and folks are
> used to.
>
>
> On 3/30/13 9:15 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
> wrote:
>
> > Hi,
> >
> > From [1]: "Closure Library provides the advantage of a consistent
> > event model that works the same way in all browsers."
> >
> > And the GC Compiler takes care of any overhead, it can very
> > efficiently re-compile "goog" based Javascript. More so than "manual"
> > JS like FlexGlobals. And we're using the GC Library anyways.
> >
> > I plan to look at the "insides" of FlexJS Javascript code next week,
> > see what I can come up with. Maybe start a branch, we can do that
> > easily now in git :-P
> >
> > EdB
> >
> >
> >
> > On Sat, Mar 30, 2013 at 5:00 PM, Alex Harui <aharui@adobe.com<javascript:;>>
> wrote:
> >>
> >>
> >>
> >> On 3/30/13 7:54 AM, "Erik de Bruin" <erik@ixsoftware.nl <javascript:;>>
> wrote:
> >>
> >>> I left out FlexGlobals on purpose, I plan to bring the Google Closure
> >>> way of dealing with events to FlexJS. The GC way is not dependent on
> >>> DOM based events and fits very snugly with the way Flex handles
> >>> events.
> >> BTW, do we need a DOM event for MouseEvents?
> >>
> >> Also, I was going to work on IE8 compatibility soon. Does Google
> Closure
> >> events work well on ie8? How much overhead is there for using it?
> >>
> >> --
> >> Alex Harui
> >> Flex SDK Team
> >> Adobe Systems, Inc.
> >> http://blogs.adobe.com/aharui
> >>
> >
> >
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl