.NET Tips and Tricks

Blog archive

Guru Tip: Avoid the HTML5 FOUJUI Experience

As I continue to incorporate more JavaScript into my applications and, especially, as I try to leverage the new JavaScript/HTML 5 technologies, I'm discovering a new problem: It's now possible for users to see raw, uninitialized HTML in their browser before my JavaScript properly arranges things. I asked Todd Anglin, VP for HTML5 Web & Mobile Tools at Telerik, if there was a solution to this problem. Here's what he said:

This is a new problem that can ruin the fancy, new experience of your HTML5 app. I think of it as FOUJI, or Flash of Uninitialized JavaScript UI: Users see the ugly HTML briefly and then, suddenly, the page looks right. One solution for this problem is to use a JavaScript loading screen that "hides" the page HTML as it initializes.

For instance, this HTML displays some gif (probably animated) that lets users know that their page is being prepared:

<div id="preLoad">
  <div>
    <img src="styles/BlueOpal/loading-image.gif"  alt="Loading Image"
 style="width:48px;" />
    <br />Loading...
  </div>
</div>
I use it with this CSS:
#preLoad{            
    width:100%;
    height:100%;
    background:#FFF;
    position:absolute;
    top:0;    
}        
 
#preLoad div{
    position:absolute;
    top: 50%;
    left: 50%;
    height:60px;
    margin-top: -30px;
    margin-left: -24px;
}

To make the loading screen "go away" when I've finished setting it up, I trigger a new event when the JavaScript that initializes my page is complete:

$(document).trigger("APP_READY");
In my main page, I wire up code to that event to hide my loading screen:
$(document).bind("APP_READY",function(){ 
    $("#preLoad").fadeOut(); 
});

Now users see the loading screen until my app finishes initializing. Then the loading screen fades out to reveal the UI -- without FOUJUI.

The richness of HTML5 Web apps is great, but it includes extra challenges like FOUJUI as you make the transition to the client. One of the things that we're doing with the Kendo UI is provide another solution: server-side helpers that render the HTML on the server before sending it to the user. In the meantime, you have to check your apps for any unintended flashing.

Todd had more to say on improving this solution (including incorporating CSS3 Transitions) on his blog.

Posted by Peter Vogel on 03/25/2012 at 1:16 PM


comments powered by Disqus

Reader Comments:

Fri, Apr 6, 2012 Peter Vogel Canada

Henry: There's no doubt that Flash is a powerful tool. But, if you want a Web app that runs everywhere, Flash won't do it for you and you'll need HTML5. Of course (especially for intranet applications) you may not need your app to run everywhere. Mark: Not only JavaScript but people are very excited about this whole web thing, also. It's worth investigating.

Thu, Apr 5, 2012 Mark

I'm amazed that people are excited about Javascript. Come on, is this article a spoof?

Tue, Apr 3, 2012 henry

I am exicited about HTML5 but Flash can do all these things http://html5socket.com/ DOT can do in a better way.Creating slideshow in HTML5! wow! what, flash did that 10 years ago! It is very easy to create a flash animation, for example a ball bouncing in flash professional in less than am minute. Javascript is a mess when compared to AS3.

Wed, Mar 28, 2012 Jeff Bowman Alaska

Update: I see now that Print View is available for articles but not for blog posts. Not to worry; thanks as always for the great content.

Wed, Mar 28, 2012 Peter Vogel Canada

Actually, you could say that the problem started with CSS: your page looked funny until the CSS was downloaded and applied to the page. I also remember seeing pages "adjust" themselves as the browser downloaded a table that controlled the page layout. Two things have exacerbated the issue, I think. First is download time. CSS sheets were so small and browsers so fast in applying them, that the problem was pretty minor. But, as Richard pointed out, so much of the initial HTML5 display is now dependent on JavaScript executing. The JavaScript libraries (even minimized) are getting larger and these libraries depend on other libraries which depend on...So the downloads take longer than it did with just CSS. The second problem is a deliberate delay: To handle waiting for the libraries developers use the jQuery ready function to ensure that absolutely no JavaScript runs until !!everything!! is downloaded (remember that pages used to adjust themselves as the table downloaded--with the ready function nothing is done until everything is ready). Also JavaScript is procedural rather than rule-based (like CSS) so the browser has to compile and execute it line-by-line: a lot less flexibility than with CSS. Put the two together (longer downloads and a deliberate wait until everything is present, followed by execution) and the problem gets worse.

Wed, Mar 28, 2012 Jeff Bowman Alaska

Hi Peter, any chance of getting Print View back? Thanks!

Tue, Mar 27, 2012

Is this really an HTML5 problem? Doesn't it exist in HTML/JavaScript too?

Tue, Mar 27, 2012 Peter Vogel Canada

Richard: An interesting perspective! As a programmer, I assume that everything is better with code, of course. But you can still do a lot "declaratively" with these new technologes: while the JS-enabled stuff gets the focus (especially in a magazine aimed a programmers) HTML5 does include lots of new tags and CSS3 adds many new features. However, once you start doing complicated stuff, it's a question of how much control you want to give the developer. A "procedural" approach that uses JS gives the developer absolute freedom to manipulate the objects any way he/she/it wants; a declarative approach (new tags with attributes that lets you customize the tag's behavior) inherently restricts you to those options that are offered. It appears that, in many cases, HTML5 has gone for flexibility with a procedural approach. That favors application developers over site designers, of course.

Tue, Mar 27, 2012 Richard

What happened to the idea of sites which would run without JavaScript? I see far too many sites which only work if you enable JS, even though they're not doing anything special with it.

Requiring JS in an *application* is fine; requiring it in a *site* is not.

Tue, Mar 27, 2012 Peter Vogel Canada

Henry: You're right, of course. But if you want to write an app that runs on everything--including iOS and Android--you're stuck with HTML + JavaScript. But I also think far too many developers are figuring that they have to write their apps to "run on everything" than is actually the case.

Tue, Mar 27, 2012 henry CHENNAI

I am exicited about HTML5 but Flash can do all these things http://html5socket.com/ DOT can do in a better way.Creating slideshow in HTML5! wow! what, flash did that 10 years ago! It is very easy to create a flash animation, for example a ball bouncing in flash professional in less than am minute. Javascript is a mess when compared to AS3.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.