On Wed, Apr 24, 2013 at 11:50 PM, Erik de Bruin <e...@ixsoftware.nl> wrote:
> 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 > > > I have been following all your discussions, but have not got a chance to participate yet. Before I jump in for a bit here, I want you to know that I greatly appreciate the hard work you guys have been putting in. Erik, to be fair, you said that you are not interested in debating over a 6k difference. I dont think Alex is raising this issue as a 'lead', rather a justified technical question. As a comparison, the dojo and jquery frameworks are 41KB and 32KB (minified) In these terms, 6KB of minified JS seems like a big enough percentage to merit a technical discussion. Dont you agree? Alex, personally, I dont mind the additional 6K. I would rather take IE6&7 support in return for it. Especially since it neatly abstracts the browser differences for us. But I agree that we need to keep the file size to a minimum as much as possible. I am not sure if this is the best place to look for gains. Is this something you can relent for now? Thanks, Om > > 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 >
