Programming Archives

Recently, when working on a DHTML slideshow based on Prototype and script.aculo.us, I ran into a problem with JavaScript and updates to the page UI. I intended the portfolio code to do the following:

1. hide the current image
2. replace the current image with a new image
3. fade in the new image

However, in my first implementation, I saw the following behavior:

1. the current image would disappear
2. the new image would flash immediately in its place
3. the new image would disappaer
4. the new image would fade in

Effectively, the portfolio code performs the following steps (simplified for example):

1. Element.hide( id );
2. $( id ).src = source of new image
3. $( id ).onload = function() { new Effect.Appear( id ) }

The problem was that in some browsers I tested (Firefox 2.0.0.6 on Windows and Mac, IE 6/7 on Windows), line 1 of the portfolio code would not appear to execute until after line 2. It turns out that for these two sets of browsers, UI rendering occurs in the same thread as JavaScript execution. The browser “queues” DOM manipulations until after the JavaScript yields. In my example, the Element.hide does not take effect until after the src attribute of the image has been changed. So, the new image suddenly replaces the old image, the new image is hidden, and then it slowly fades in.

The trick I used to solve this was to use setTimeout to effectively “yield” control so that the browser could update the page UI (again code simplified for example):

1. Element.hide( id );
2. setTimeout( function() { $( id ).src = source of new image }, 0 );
3. $( id ).onload = function() { new Effect.Appear( id ) }

Here’s a complete, yet simple example. Refresh your browser to reset the state of the page. You can also play with the example here.

    


        
    

    

            ready
        

            
                click me (without setTimeout)!
            
        

            
                click me (with setTimeout)!
            
        

    

If you click on the first link, nothing will appear to happen for 3 seconds or so, then the message will change to “go!” However, if you click on the second link, the message will immediate change from “ready” to “set…” and after 3 seconds, to “go!”

Be careful with this setTimeout trick. It is easy to abuse it. I have implemented a queue where setTimeout is used to yield control to the browser UI between commands previously enqueued commands. The code became unmanageably complex. Yielding control in this fashion does not make JavaScript threaded, but does introduce asynchronous behavior which may cause your code to execute in an unexpected order.

Smashing Magazine has done it again, with an article that lists over eighty AJAX solutions that include widgets, tool sets, libraries, and effects. I know the list is a bit overwhelming, but if you’re a professional web programmer I recommend at least trying out 5-6 of the listed solutions. For a quick highlight list, just go to these sites. I’ve used these tools extensively and find them to be very useful:

• script.aculo.us
• Lightbox
• MooTools

Two interesting recent articles on the virtues of keeping things (products, projects, etc) small and simple. Be humble, think about your users, create great projects and better code.

We don’t often write about specific technologies here at Bust Out, as we tend to be fairly agnostic and pragmatic about such matters, but we recently sent a contingent off to Portland, OR to attend RailsConf 2007 and we are feeling pretty darn excited about the Rails framework and its future.

What’s the cause of this excitement?

Rails, or Rails adoption rather, is maturing, as was evidenced by the number of talks at RailsConf dealing with what we’ll call “big application” issues, such as server virtualization, scalability “without bounds” and large-scale caching. It was great listening to developers who are pushing the framework into new territory and are devising interesting and creative solutions to resolve whatever performance or scalability issues they run into. It was also interesting to hear how many times Erlang was mentioned during these talks as a very scalable, high performance language that can be leveraged in Rails environments (web servers, messaging etc) to potentially help improve solution scalability.

Now, we’re fans of the Pragmatic Programmers, we follow the trends, read plenty of other blogs and we’ve read (at least half) of The Tipping Point during various bathroom breaks, so we get that Erlang is growing in popularity as well as vaguely how that sort of growth would show itself in a venue like RailsConf.

As such, in anticipation of next years language du jour, we here at Bust Out Solutions feel there’s an intriguing opportunity looming on the horizon. Forget Haskell. And Scala. And Lua. And OCaml. It’s Java.

Got scalability issues with your JRuby on Rails application? You COULD use Erlang-based services, but that’s so last year. Throw it on a cluster of WebSphere App Servers running on some monster AIX boxes, fire up your Tibco ESB for some distributed JMS-ing, WS-ing, JBI-ing or straight up BPEL-ing, get a copy of Oracle Coherence for your distributed caching needs (you can even toss out the database with a big enough grid) and you’ll be all set. There are a lot of choices, which makes the whole experience all sort of infuriatingly fun and lucrative for others if you’re the generous type.

If anyone is interested, we’re open to speaking at next year’s conference. If we get rejected, even better, as I heard RejectConf was more stimulating than the real thing. Or maybe we can write a book….Java for Rails Developers?

As an aside, hats off to the community at RailsConf for donating over $30,000 to charity. It was a great idea and wonderful gesture from the community. Next year, we can surely do even better.