[mindcrime]

Is it just me, or does anybody else think that it's a problem that the world even needs this in the first place?

I expect splash screens and slightly longer load times from desktop apps... if I click on a link to something in my browser, not so much. TBH, if a page/app takes more than a second or two to load, I assume there's something wrong with it (or my net connection).

[jhdavids8]

For SPAs, something like this can be quite useful for a few reasons: branding (see Slack's and Asana's cool examples), having in-app authentication on any page (see the login form example on the demo page), and yes, showing some sort of notification while a good bit of data loads in the background.

For the majority of sites, I agree this may be overkill, but if you have a SPA that needs to load a good bit of data on the user's first use of your app (and verify authentication), this can (hopefully) be useful.

[masukomi]

You missed the point. If you "need to load a good bit of data on the user's first use" you've already failed. I've been coding professionally for about 20 years now and the only reason i've ever seen for loading a bit of data on the initial hit, is that the developer didn't spend the time to think about how to load the necessary pieces incrementally, as they were needed by the user. Instead they designed a system that needed a whole pile of crap on startup even if the user didn't.

[jalpino]

I tend to disagree with the statement that you've already failed if you decide to eagerly load resources before they are used or needed. Take queue from Google or others who pre-fetch resources based on anticipated usage. In the world of SPAs and client-side heavy apps, combining resources into a single or logically grouped set of resources is common practice to cut down on the amount of overhead that many http(s) calls impose.

Also, the intended use of PleaseWait.js doesn't have to be used to stall while client side resources are brought down. This concept could easily be used for long running, server side processing.

[jhdavids8]

I certainly agree. There are almost always ways to avoid "loading a good bit of data on the user's first use". But for your traditional SPA, it's quite common that you need to make a few AJAX calls to your backend API in order to fetch some data to show to the user. This was built for mostly that case, not for the "let's block the user's screen for 5+ seconds while we do unnecessary data fetches" case.

Edit: I misspoke when I said "a good bit of data" in my original response. I simply meant any API calls to your backend.

[at-fates-hands]

Agreed.

There's so many tools right now to find out exactly what your page or app is using and how to minimize what you're serving. Sure, it takes some effort, but your users will thank you in the end.

[zaidf]

It's very common for certain features in enterprise apps to take 5-30seconds to load. Most enterprise report generation features require a few seconds for a lot of the queries, for example.

[detaro]

Shouldn't these then show loading indicators for the data areas, and not the entire page? (covering up menus etc., where the user might abort the process or change parameters)

[leviathan]

Reminds me of Parallels Plesk and their horrible ui

[adnanh]

Some (legacy?) web applications written in flash (using Flex SDK for example) still require some time to download, considering that the binary of 2mb takes at least a few seconds to download, showing a splash screen to a user instead of the blank page would be much better than having user to wonder if the page/app is going to load at all, like in [1].

[1] http://www.socialexplorer.com/6f4cdab7a0/explore

[xatnys]

Certainly, with web applications you would want the least amount of latency possible. This is a normal UX scenario -- as you indicated, there are factors which can simply be out of the hands of the application such as network connectivity.

In cases like that, indicating to the user that something is happening makes for a better experience than not doing anything, or in the worst case (which certainly shouldn't happen these days) blocking the user's browser.

[mQu]

Not realy. A user with a slow connection will know that and wait (because the problem will be global). Adding a preloader is just bloat that will make the site load even longer (and just piss off the user as he'll know that some of his scare bandwith was lost on the shiny spinning wheel).

[xatnys]

Aside from the reality that a user won't always know their connection is slow / has slowed (particularly when it comes to bad routing between server and client), this is also typically used in cases where you are utilizing XHR.

Given that they're done in the background, the browser won't indicate them being made outside of dev tools. If they're asynchronous, again ideally they will take place as quickly as possible. This is unfortunately not something that can be relied upon.

[Animats]

Is it just me, or does anybody else think that it's a problem that the world even needs this in the first place?

I agree. If you need this, go back and look at what you're loading. Do you really need all that CSS? Does that Javascript really need to be executed? Do you need it just to get started? Do you really need 15 tracking cookies and a Flash bug?

[ranty]

Exactly. Splash screens are so 1995 - we need to be getting users to something useful as fast as possible.

[RobertKerans]

Games fair enough; I understand the temptation, but Jesus, just spit out a static page and load the rest in as and when needed.