On 4/24/13 9:26 PM, "Erik de Bruin" <e...@ixsoftware.nl> wrote:
> Alex,
>
>>> I'm not going to debate on the basis of a 6k difference, honestly. 6k
>>> is not a 'hit'. 6k takes not even half a second to download... on a
>>> 128kb modem! On an average broadband connection (I don't believe I'm
>>> actually taking the time to type this) it takes around 1/100th of a
>>> second.
>> We said that very thing for current SDK and Hello World apps. We said it so
>> often, that HelloWorld is now well over 200K. So, I am probably overly
>> sensitive to this kind of rationale, but I don't like increasing the size of
>> things without truly understanding what we're getting for it.
>
> You have to trust me on this, because I'm not willing to spend a lot
> of time detailing all the reasons why this is a good idea. I've spend
> a large part of my carrier building and maintaining large JS
> frameworks and honestly, we need all the help we can get. The Closure
> Library offers many things that this project needs, such as a solid
> event handling foundation, allowing us to focus on building cool
> components instead of re-inventing the wheel for the internals.
Decisions are supposed to be made on technical merit. I trust that you are
a smart and good guy, but in order to switch I think there has to be a
technical benefit.
For example, you chose goog's foreach, but it couldn't handle break/continue
without try/catch wrapping and I switched to an implementation that doesn't
have that limitation. I consider that a technical decision.
Once the technical limitations of my event implementation start to appear,
we can make a decision about whether it is easier to fix what is there or
switch. That's why I wish you'd separated the code cleanup from the
goog.events change, so we could reserve the goog.events change in case we
need it.
This old post [1] indicates that goog has support for IE6 and IE7 in it. If
that is contributing to the 6K, I'd rather not carry it around. I don't
have as much experience you have with JS, my small sample of the
BrowserManager js code is all I really have to look at, but a look at it
shows that as you shed older browsers you can shed some really awful code.
It could be, that in 2013 when you no longer need to support IE6 and IE7,
that a simple small implementation like the one I have is sufficient.
In fact, that's one reason I separated IE8 out into a separate class, so
folks can purge that code if they no longer need it. Recent data I saw
indicates that IE8 is a very small piece of the pie in the real world, but
remains a big factor in the enterprise, but probably not forever, and once
you get to IE9 and IE10, just about all the major browsers have the same
event API.
>
>>> What we get for this is a really clean framework (no IE8Utils,
>>> FlexGlobals etc.).
>> FlexGlobals is independent of goog.events isn't it?
>
> No, 'createProxy' is used extensively in event management in the
> pre-'goog.events' version.
Yes, but you would have switched to goog.bind whether we changed to
goog.events or not?
>
>>> We don't have to spend time on fixes for the
>>> 'roll-your-own' solution.
>> How do you know it needed fixing?
>
> Because there are all kinds of 'utils' classes and customised browser
> dependant paths in the code that are neither inclusive nor generic.
That sounds more like style than functional technical issues. But yeah, as
a code minimalist, I'm going to try to leverage what the browsers can
already do instead of writing or borrowing a whole new subsystem.
>
>
> Frankly, the framework was (already) getting sloppy. Too many
> copy-paste errors, too many variables declared improperly or not at
> all, ending up in the global namespace. Too much of the code wasn't
> properly formatted, making reading difficult to read and potentially
> inviting/causing errors. Instead of trying to fix everything manually
> I turned to the Closure Linter and JSLint for help. The former
> strongly suggests specific whitespace handling, hence all the myriad
> changes in that. The latter requires very strict 'block' bracketing,
> adding to the changes. They did help me catch so many issues though,
> so I think it was worth it. For this particular contribution it might
> be easier to actually read the code than it is to read the diffs, if
> you want to see what's changed ;-)
>
Definitely thanks for doing the cleanup. Any way we can just apply the
clean up and save the goog.events change in case we truly technically need
it?
[1]
https://groups.google.com/forum/?fromgroups=#!topic/closure-library-discuss/
cpHlaWAkFag
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
