[mQu]

Why is this any different than Flash preloaders just a moment ago? And even worse - it doesn't show any progress so there isn't any user feedback. Every (bad) pattern seems to repeat itself. Just using current-cool-tech.

I would much more appreciate that dev time would be put into a framework that allows graceful enchancement by deferring loading more heavy components and to allow user to interact with the site ASAP.

Having a skeleton project for gulp (or any other system) that shows how to properly split big, non essential, components and lazy load them would go much further to ease developing big applications and smoothen UX.

EDIT: typos.

[espadrine]

> Why is this any different than Flash

I agree and raise you the point that this is Chrome-only, and doesn't even bother to mention it. Half of the spinners fail to work in Firefox stable.

I know they didn't write the spinners, but the company seems targeted at teaching:

> Pathgather is an NYC-based startup building a platform that dramatically accelerates learning for enterprises

Platform lock-in on the Web is an odd thing to teach.

[ryanSrich]

Like what Facebook's web app does? They load the page first leaving the comments and photos "spinning" (it's more of a gradient fluctuation, but indicated loading). This free's you up to interact with the rest of the site.

[ZoF]

Yes, that's what he means.

[jhdavids8]

Using PleaseWait to actually show progress can be achieved by simply updating the loading HTML to show a number percentage, but we may update the API to make this easier in the future.

And I agree that a skeleton project to show proper modularization of different components would be great! Our blog just started an Angular series, so we'll try to write one on how we split up our large Angular enterprise app in this regard :)

[mQu]

But it's missing the point - just like other comments said - if you need this you're doing it wrong.

I sure was guilty of big sites just as much as the next guy. It just saddens me that insted of promoting what we've learned it the past years and applying to current projects we're doomed to repeat bad UX from before.

[jhdavids8]

Maybe you're right, but I certainly think there are some valid cases where this could be useful. I'm not saying use it in every project, or use it as a workaround to a larger architectural issue, but if you have a single page app that does not render templates on the server, showing something like this while you make a few AJAX calls and compile the data returned into your client-side templates isn't the worse thing in the world. Slack and Asana do similar things, and I would hardly say that their engineering teams did a ton wrong. We actually built this because we're customers of both and enjoyed the screens they showed, so we wanted to see if we could make a generic library that others could use to do the same.

[pdabbadabba]

I for one think this is exactly the right attitude.

Sure. Maybe it's literally always a Bad Thing to show a loading screen. But plenty of apps have made that choice, for some reason or other. Maybe the developers are incompetent, or maybe they have a combination of technical and resource constraints that make this the best choice for them. It doesn't matter. At least this loading page can improve users' experiences with apps that have, for whatever reason, made the choice to go this route.

[mtrpcic]

I agree with you on this. There's a large subset of the web development community who are shifting towards building desktop applications with web technology (atom-shell, node-webkit, brackets-shell, etc.). In a lot of these cases, the app bootstrap process is actually loading data/content that is required for proper app functionality. Desktop apps commonly use loading screens on boot to indicate this process (Photoshop is the example that comes to mind). I think this is a great tool, and will fit well with that subset of the web-dev community particularly well.

[sqrt17]

The point is: most of these applications (say, Photoshop, Gimp, Eclipse, OpenOffice, probably others) are things that you load once to work with them for a couple hours, and don't mind when they consume a lot of your system resources.

If you look at web applications, Google's music app ("My Music" in Google Play) uses a load screen (complete with progress bar) because it's seriously bloated, while Amazon's Cloudplayer just loads and does its thing (which is, playing music).

Needing a load screen is a sign that your app is not, or aims at not being, a Web app anymore - in the sense that you'd also want to loosen the other restrictions - give it its own window, possibly have local file storage or FS caching, etc.; In that case, something like TideSDK ( http://www.tidesdk.org/ ) may come in handy to deliver a desktop app to power users that is based on the same codebase. And, maybe you'd still want a web app that is functional and lean. (As an example for two apps with non-identical possibilities, Google's My Music allows you to change song metadata on desktop browsers but not in the Android app - yet another sign that My Music is meant as a desktop-y app).

In many cases it can be a sign of hubris or lazyness that you cannot get rid of the bloat. Be real and think whether your users actually enjoy waiting that time, since they'll be doing it more often, on machines with less resources and/or slower connection, than yours.

[plorkyeran]

Asana's absurdly long load time was one of the main reasons I was glad to stop using it. It's definitely not something I would considered well implemented.

[madeofpalk]

> by simply updating the loading HTML to show a number percentage

Note, this isn't always easy to do. If you use on-the-fly gzip compression (which is how most people set their nginx or whatever up), you won't get a Content-Length, so you can't show progress.

[mQu]

Ofc a blog describing your experience would be just that knowledge promoting that i have in mind so kudos for that (and i'll be keeping an eye for it because it is a hard problem to get right).

[nostromo]

No need to be dogmatic, there are valid reasons to use these.

For example, we have some heavy reports that take a few seconds to load, so we show a screen similar to this while we crunch the numbers.

[straws]

What are your thoughts then about putting only that region of the page behind some kind of loading/awaiting indication?

My issue with whole-page takeover loaders is that they lose your control and spatial sense of the app. You can't, for example, page away if you decide the report is taking too long to load, or you went to the wrong section of the site when hunting around for a piece of information.

[xatnys]

It all depends on the implementation. What you're describing is pretty common, particularly on blogs comment systems and YouTube.

This can likely be extended to only be utilized on part of a widget. If it's something like an ajax call you can easily add an option to cancel the request e.g. underneath a spinner.

For your report example in particular the service could be developed in such a way that the processing occurs independently of the user session. You can mix this in with an additional request which returns the actual progress of what has been calculated in the report such that whenever a user browses to that page, they can see just how much time there is to go before their report is generated.

[gumballhead]

Right? Does this seriously need to be a js library?

[Kiro]

Yeah, because I really want people to interact with my game before everything is fully loaded. Great idea.

[Kiro]

Rightfully getting downvoted but I still believe my argument is valid: there are certainly use cases for these kind of loading screens.

[Marazan]

Flash won.

HTML 5 is the web remaking itself in the image of Flash.

[Marazan]

Ah, good old down votes rather than explaining why you think I'm wrong.

HTML 5 is an attempt to turn the web browser into a replacement for the Flash Player. Punch the Monkey Flash ads are replaced with Punch the Monkey HTML 5 ads.

Javascript framework after framework comes and implements the Flash way of doing things in the browser.

And the irony is that Flex is still the best way of producing RIAs years after Adobe killed it.

[umyaaaa]

typical HN response. complain first.

[DINKDINK]

Why is complaining bad? If no one ever complained, we'd still be riding horses.

[bbcbasic]

Typical HN response is honesty.