Kyle Simpson

Recent Blog Comments By Kyle Simpson

• You Can throw() Anything In JavaScript - And Other async/await Considerations

  Posted on Feb 25, 2022 at 9:00 PM

  I wonder if part of the reason that throw() felt awkward or unnatural to you is because it's not actually a function-call, and therefore does not generally need the the (..) part surrounding what you throw ? It's just a keyword/operator. You correctly name it a "throw statement&quo... read more »

• Keep Overflow Content Scrolling Unresponsive Until Clicked Using jQuery

  Posted on Jan 7, 2014 at 9:19 AM

  Makes sense to me. But I think it should be a toggle. You click into the area, then it's scrollable. Click out of the area, it becomes un-scrollable again. Rinse, repeat. :)... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 10:37 AM

  @Ben- "That said, it seems like my misunderstanding here was that of how the DOM works, not with how LAB.js works?" I'd say that's a fair statement. I really think Andrea's objections were just that the title of the post is about DOM-ready, and then you also do this splitting thing, which... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 10:23 AM

  @Ben- Specifically in the case of older IE's, the problem is that it depends on what you did inside that inline script tag. For IE, the fatal crash would come if you tried to modify an element that had not yet closed. So, if your script tag was inside the body, even at the bottom, and what you did ... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 10:15 AM

  @Ben- As I pointed out in my previous comment, I believe it's a faulty assumption to say that because the .wait() is found at the end of the body, that basically DOM-ready listener is not really necessary. If that is true in practice, it's an indirect behavior (accident) at best. Position in the DO... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 10:08 AM

  Benjamin- "which I believe may have been your other point is that LABjs - and @kyle, correct me if I am wrong - evaluates all the scripts before everything is loaded and the jQuery call would fail (and has in my testing)." Correct. In your case, because you need to use jQuery to check you... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 10:03 AM

  Andrea- Agreed that it's perhaps a little confusing here why Ben split the chain. If he did so specifically because of DOM-ready, then you're correct that this is a misunderstanding. A little clarification as to why the chain is split would be helpful. Moreover, there is a common misconception (unf... read more »

• Using The LAB.js Script Loader With jQuery's DOM-Ready Event

  Posted on Jul 29, 2011 at 9:44 AM

  I think Andrea's point is correct (though from twitter conversations I think he may be misunderstanding Ben's reasons on this page). 1. You can split the $LAB chain (as Ben does here), or not (as Andrea does)... shouldn't be any different. Definitely doesn't matter with respect to DOM-ready -- same... read more »

• Using Deferred Objects As An Asynchronous Script Loader In jQuery 1.5

  Posted on Feb 12, 2011 at 3:17 PM

  While this technique is quite useful for some purposes (and it's much nicer syntax with deferreds than previously!), it's important for readers to understand that it doesn't fully fit the general script loader use-case. There are 5 relevant dimensions: 1. multiple scripts 2. remote-domain scripts (... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 13, 2010 at 9:39 AM

  I haven't had a chance to look at the no-304 issue yet, but my initial guess is that maybe the use of XHR is what's exposing this bug. Perhaps set the "UseLocalXHR" setting to false and try again, see if that "fixes" it.... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 11, 2010 at 12:17 PM

  @Ben -- It's a good idea, the problem is it won't work. :) What's happening underneath the covers is that every time an API function executes, like .script(...), what's returned is *not* just another instance of $LAB, but actually a new object (new closure!) with what happens to be an identical loo... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 8, 2010 at 7:46 PM

  @Ben -- yes, you're correct, LABjs is totally separate of any framework, therefore I don't bake anything into it that is framework specific. However, it's possible to wrap the $LAB API when necessary additional functionality is desired. For instance, fLABjs wraps the API to be adapted to handling p... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 8, 2010 at 6:31 PM

  @Steve -- you're right, you can always roll your own approaches and usually get the code much smaller than LABjs. If you're in a position to do so, great. However, it's VERY common for web applications to grow in complexity, and as they do, things like remote scripts (or scripts you don't control) ... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 7, 2010 at 9:12 AM

  Also, wanted to comment on $.getScript() -- yes, it will load things in parallel using "async", but the thing it *won't* do is allow you to sequence the execution of the scripts. So, if you call getScript() on 3 scripts, you can't control which one loads and executes first. If the 3 scripts in ques... read more »

• How Javascript Loading And Blocking Works By Default

  Posted on May 7, 2010 at 8:59 AM

  FYI: LABjs with jQuery 1.4+ is perfectly safe and correct for $(document).ready() checks. I use LABjs on several sites with jQuery and ready() and it works fine. Prior to 1.4, jQuery was incorrectly checking the dom-ready event (specifically, it wasn't properly checking in FF if the dom-ready had a... read more »