you know, I tried replicating this "error" but couldn't. However I didn't try to load a lib from Google and like More locally though.. Especially for intranets I just dump everything in the head on one server and start ondomready... Didn't need the lazy loading for separated app scripts yet.. those few kb's can be loaded just as well right away ;)
On May 19, 9:41 pm, Ger Hobbelt <[email protected]> wrote: > On Thu, May 19, 2011 at 2:10 AM, Barry van Oudtshoorn < > > [email protected]> wrote: > > I'm not quite sure why you're running into these issues. It may be worth > > while hopping onto the Firefox mailing lists and asking there, though... In > > the interim, have a read of > >http://www.softwareishard.com/blog/firebug/script-execution-analysis-.... I > >have a feeling that it may be relevant to your problem. > > That one most probably is, yes. Thanks for the pointer. > > The joke of it all was it's happening when loading library code > (mootools-core, more, sometimes mochaUI as a bonus addition) and it's > happening inside the library code which is (sensibly) interdependent in that > way. I don't need to write a single line of code to make it happen; all it > needs is a series of scripts being loaded either the old-fashioned way or > through a classic lazyloader AND you got to have it all in a relatively fast > Intranet (internet servers have longer travel times for their messages than > fast servers that are located on the same 1G/s Ethernet and jacked into the > same switch as the client/browser). > > Make the server serve their stuff slower and the problem goes away as you > reduce the chance of next load finish vs. prior parse run overlap (or at > least that's my assumption; only a very thorough code scan of FF and the > others would make sure of it). Switching to fetching mootools from a public > internet CDN, for instance, may /sound/ like something that's fast but in > actuality it's way slower than serving the stuff straight off your servers > as long as you're in a Intranet situation (and some reasonably fast > equipment). Each millisecond counts, unfortunately: every millisecond spent > in travel (sending the data from server to client) reduces the error rate on > this one. > > I was wondering if other people encountered this behaviour and how they > coped with it if they did. > mootools is big enough (both core and more) to stretch the parse phase long > enough to give this sort of thing a chance if it's lurking in shadows. > > > I can't help but think that a lot of your problems, though, could be > > solved by decoupling your code more. Perhaps some sort of message sink > system. We use a bespoke one that I wrote here at work, but I believe that > Mark Obcena has some good stuff in this area. Check > outhttp://keetology.com/blog/2010/10/01/modules-and-callbacks-going-holl...http://keetology.com/blog/2011/03/15/sondheim-meets-mootools. > > Gonna check those out! Thanks! > > -- > Met vriendelijke groeten / Best regards, > > Ger Hobbelt > > -------------------------------------------------- > web: http://www.hobbelt.com/ > http://www.hebbut.net/ > mail: [email protected] > mobile: +31-6-11 120 978 > --------------------------------------------------
