Alex, Sounds like you're currently not interested. Too bad. I'll leave the branch on the public repo in case you change your mind.
After Marmotinni and 'goog.events' - which combined represent a couple of man-weeks work - have been denied by the project lead of FlexJS, I'm not at all motivated to make further contributions to that project. If I decide to keep contributing to Apache Flex at all, I'll focus on developing the VanillaSDK for AS->JS, a library that promises to have a much shallower learning curve for application developers than FlexJS. It's been fun, sort of, EdB On Thu, Apr 25, 2013 at 8:29 AM, Alex Harui <aha...@adobe.com> wrote: > > > > 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 > -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
