flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik de Bruin <e...@ixsoftware.nl>
Subject Re: Google Closure Events (was Re: [FalconJx] progress update)
Date Sun, 31 Mar 2013 07:36:17 GMT
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 <aharui@adobe.com> wrote:
>
>
>
> On 3/30/13 10:39 PM, "Erik de Bruin" <erik@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

Mime
View raw message