Can script determine if window.onload has already fired?
in [JavaScript]
|
From: Thomas 'PointedEars' Lahn on 26 Nov 2009 18:57 beegee wrote: > On Nov 25, 4:04 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Realize that lazy loading of scripts is often indicative of lazy >> programmers trying to hide that they are using much too general (and >> therefore bloated) scripts. Or it may be Ajax-itis (the compelling >> need to cram every app into one document). > > I think this was a *lazy* reply. There is a compelling case to be > made to a web user experience that resembles a stand-alone > application. Really? > Users generally get nervous when they are directed off the home page. Is there a usability study (say, by Nielsen) to support your opinion? > Even web 2.0 experiences like Facebook (basically 2 pages) are confusing > to many. And this does not make you think in the right direction? > Now, Ajax in it's current state may not be the way to get to the one-page > application but the trend is to get there. And incompetence like this makes the Web even more of an accessibility nightmare, in a medium that should be open to as many people as possible. > The YUI Loader component is an attempt (unsuccessful in my opinion) to > implement the component approach of application development. Yes, it is still much too bloated. > In the end, the suggestion of testing a global variable is exactly what > the OP is going to have to do. Or the property of an object referred to by a global variable. > Every single script he downloads is going to have to know of this variable > or function. That IS the current state of browser script load > notification. I don't believe saying that the need for such an approach > shows bad design is correct. There is no need if you use the modular approach properly. It's been done. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: David Mark on 26 Nov 2009 20:50 On Nov 26, 10:43 am, beegee <bgul...(a)gmail.com> wrote: > On Nov 25, 4:04 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > Realize that lazy loading of scripts is often indicative of lazy > > programmers trying to hide that they are using much too general (and > > therefore bloated) scripts. Or it may be Ajax-itis (the compelling > > need to cram every app into one document). > > I think this was a *lazy* reply. There is a compelling case to be > made to a web user experience that resembles a stand-alone > application. I know. I've been writing such applications since IE4. The key word is "resembles" though. The user doesn't know or care how how much navigation is involved (unless the design is so bad or the implementation so bloated as to make navigation a problem). > Users generally get nervous when they are directed off > the home page. I have no idea what that means. What home page? The average user won't even notice moving from one page to the other if the two pages are similar. > Even web 2.0 experiences like Facebook (basically 2 > pages) are confusing to many. Don't know what that means either. Users are more used to navigating from one document to the next than to single-page docs that try to work like apps (sporadically failing, which they do notice). > Now, Ajax in it's current state may not > be the way to get to the one-page application but the trend is to get > there. What trend? I've seen a lot of blithering about single page apps out there, but no explanation as to why Web developers think that is a general goal. > > The YUI Loader component is an attempt (unsuccessful in my opinion) to > implement the component approach of application development. It's an attempt to fill a perceived need. > In the > end, the suggestion of testing a global variable is exactly what the > OP is going to have to do. Right. > Every single script he downloads is going > to have to know of this variable or function. Depends on what those scripts have to do. Context is king with this stuff. Making broad generalizations usually leads to failure. > That IS the current > state of browser script load notification. I don't believe saying > that the need for such an approach shows bad design is correct. I don't follow. Show me a single-page "app" that is too slow to load (ostensibly requiring a hare-brain scheme to make it usable) and I'll show you a more appropriate multi-page design that isn't. Lately it's becoming a career. ;)
From: Garrett Smith on 27 Nov 2009 01:56 Matt Kruse wrote: > There is a discussion going on in the jquery-dev mailing list that > piqued my curiosity. I'm interested to know if the smart people here > have a good answer. > > Is there a cross-browser way, in script, to determine if window.onload > has already fired? > > If a script is lazy loaded and needs the DOM to be ready, it can > attach to the window's load event. But if that has already fired, then > the script's code will never run. Alternatively, it can just fire its > code inline, but the DOM may not be ready. > > Thoughts? > A follow-up to my previous message in this thread. Solution: The loaded script must not listen to any window load or readystatechange events and must not call document.write (no jQuery.ready). A Loader adds a load callback to a script element, then appends that script, triggering the browser to load the script. When the script's onload fires, the callback calls callback function. Decoupling the loaded scripts from the loader avoids the tight coupling and allows flexibility in loading. The module may provide an init() method, so that the module can be re-inited if/when document innerHTML changes. In contrast, if the callbacks get attached in a hidden-in-module-scope onload, they fire only on load. This is a problem when innerHTML changes, and in your case where the onload may have already fired. A dynamically loaded script must be designed in a way that it can be loaded at any time without problems. It must not call document.write, and must not listen for any load or readystatechange events. Does this make sense? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Jorge on 27 Nov 2009 04:04 On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > (...) > A Loader adds a load callback to a script element, then appends that > script, triggering the browser to load the script. When the script's > onload fires, the callback calls callback function. > IIRC, I've seen a couple of strange things happen when doing so. In some browser(s) the onload may not even fire for <script>s. And in some browsers I've seen both the <script>'s source being parsed/run synchronously and the onload event being handled synchronously too (when the <script> was cached and got fetched immediatly, on-the fly, from the cache). Is it me, is it too much coke, or has somebody else seen any of these too ? -- Jorge.
From: David Mark on 27 Nov 2009 04:28
On Nov 27, 1:56 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Matt Kruse wrote: > > There is a discussion going on in the jquery-dev mailing list that > > piqued my curiosity. I'm interested to know if the smart people here > > have a good answer. > > > Is there a cross-browser way, in script, to determine if window.onload > > has already fired? > > > If a script is lazy loaded and needs the DOM to be ready, it can > > attach to the window's load event. But if that has already fired, then > > the script's code will never run. Alternatively, it can just fire its > > code inline, but the DOM may not be ready. > > > Thoughts? > > A follow-up to my previous message in this thread. > > Solution: > The loaded script must not listen to any window load or readystatechange > events and must not call document.write (no jQuery.ready). > > A Loader adds a load callback to a script element, then appends that > script, triggering the browser to load the script. When the script's > onload fires, the callback calls callback function. I know you don't mean the load event of the SCRIPT element. That's something to avoid, even in fantasy designs. ;) "Jorge" actually got one right. I can't believe I'm saying this, but have a look at his response. |