Archive for the ‘JavaScript’ Category
JQuery PeriodicalUpdater in JSMag July 4, 2012 | 08:43 pm

The jQuery PeriodicalUpdater, which is undoubtedly my most popular open source project to date, is featured in this month’s JSMag. It’s actually a part of a two-part series, the first on jQuery PeriodicalUpdater in particular, and the second on witing jQuery plugins, using jQuery PeriodicalUpdater as an exemplar. So keep an eye out for that next month, too.

The jQuery PeriodicalUpdater is responsible for long-polling the backend from the client. When people usually write this code, it tends to be like some little kid: “Can I have it now? What about now? How about now? Now? Now? Now? Now?” This leads to exasperated servers. The PeriodicalUpdater handles this with much more grace, leading to happy servers while keeping the client up-to-date.

Like last month’s GroovyMag article, I’m offering a free copy of this month’s JSMag if you drop me a tweet asking for it. (There’s also a few more GroovyMag article codes for those tweets.)

jQuery: Timing of Selector Resolution June 17, 2012 | 07:05 pm

I was curious how eager or lazy jQuery was with its selector resolution. So when you say $(".foo"), does it walk the DOM immediately looking for things of class “foo”, or does it wait? After all, it could wait until a call comes in to modify an element before resolving the elements, which could be an optimization in some cases. This would also handle mutations to the DOM, which would be nice in certain cases (such as the bound version of PeriodicalUpdater). It could also be that that jQuery detected changes to the DoM via jQuery, and perhaps threw signals to keep things in sync.

However, it turns out that selector resolution is eager in jQuery. I checked it twice: once using a timer as a simplified version of what JQuery PeriodicalUpdater does and once using direct DOM modifications. In both cases, you see the straight eager behavior.

So there you have it: selector resolution is eager in jQuery. So don’t ask for elements until you’re sure you want them, and not until you’re sure they exist.

JQuery PeriodicalUpdater (AJAX long polling/server polling) June 25, 2009 | 08:54 am

I’m working on an app that is using the JQuery JavaScript framework. Time came for a bit of AJAX long-polling (which I can no longer say without snickering thanks to WebDevGeekly), and so I went looking for a way to do that in jQuery: specifically, I wanted something like Prototype’s Ajax.PeriodicalUpdater, which has a nice decay to pull load off the server if not a lot is changing.

Unfortunately, such a beast doesn’t exist within the core JQuery code. I bitched about the lack of one on Twitter (cite), and ddelponte resisted routing me to http://letmegooglethatforyou.com/?q=jquery+periodicalupdater and instead pointed out the #1 hit on Google: 360innovate’s port.

That port didn’t do quite what I wanted, and I saw a few places to eke efficiencies out of the code, so I did. The new version of the code is hosted at http://github.com/RobertFischer/JQuery-PeriodicalUpdater/. Specific advantages over the 360innovate version are:

  • Any option in jQuery’s $.ajax can be used, including any callbacks. The only exception is the flag that treats modifications as errors. That’s always going to be true (see the next bullet).
  • 304 Not Modified pages are now treated like they weren’t modified (that is, timeout increases). Their treatment before was as errors, which caused the timeout to reset to the base value.
  • The settings passed into the function are now deep-copied, which means the setting object can be mangled after the call without hosing up the entire works.
  • As much work as possible is done up front, so the actual polling AJAX call is fairly fast and lightweight. This is important so that it doesn’t clog up the limited resource that is JavaScript user processing threads.
  • The first poll begins once the document has finished loading, which should speed initial page load and avoid issues caused by the AJAX response returning before the page is totally rendered.

The code for the PeriodicalUpdater is pretty cool. One stunt which people should definitely pay attention to is using executable code blocks for factoring out loop-invariant checks. In this case, it’s demonstrated in the logic to boost the decay:

        // Function to boost the timer (nop unless multiplier > 1)
        var boostPeriod = function() { return; };
        if(settings.multiplier > 1) {
          boostPeriod = function() {
            timerInterval = timerInterval * settings.multiplier;
 
            if(timerInterval > settings.maxTimeout)
            {
                timerInterval = settings.maxTimeout;
            }
          };
        }

In this case, this behavior is either a nop (for multipliers <= 1), or it's got some involved logic. The 360innovate version did the multiplier check each time the interval was going to be boosted, but that multiplier isn't going to change. Since the multiplier isn't going to change, the code can be factored out and the check can be saved. The same functionality could be done by the function null unless there is logic attached, but then call points look like this:

if(boostPeriod) boostPeriod();

And I’ll take the overhead of a call to the nop method to get easier-on-the-eyes, more maintainable code.