Hacker News Reader

Comment by wodenokoto | Hacker News Reader

I am of the opposite conviction of the author. I hate it when content is the last part to be loaded.

You'd prefer to see nothing (or nothing but a spinner) until everything is available to be shown?

You can't really win with web apps. A native app that painted either way would be called 'broken' and not pass QA. Yet we swallow things like this without blinking.

Not totally sure I get you, native apps tend to use a combination of placeholders and spinners too (when loading network content). Are you saying people are harsher in their judgement of web-apps, or more accepting?

Vastly more accepting of web apps. Web apps stall, spin (or worse yet don't spin yet are unresponsive), paint in embarrassing frames and masks with old content showing through the holes, and on and on. A native app that did that would be criticized roundly; web apps get a pass for some reason.

Not really. See Launch Images in iOS: https://developer.apple.com/library/ios/documentation/UserEx...

That's ok at launch (to cover up how awful web apps paint). But what then? Change forms or screens and it fails again. Or hit a button - no visual indication you hit it; app hangs; screen updates in spurts.

Not all web apps, but certainly a large fraction.

Badly implemented apps are badly implemented, native apps aren't immune to this phenomenon.

Yes. Asynchronous image loading and rendering is already built into the browser, and the rest of the content shouldn't take long to load to begin with. Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints as the data trickles in, cause far worse performance, latency, and usability problems than rendering a single chunk of HTML ever did.

Nobody says this has anything to do with 'Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints ...'

The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

I'm looking at my desktop Spotify app and seeing places where this approach is applicable. Of course it loads so fast to me it seems unnecessary, but that will not be the case for everyone in the world.

> The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

Would probably be better to spend developer time on more aggressive preloading then.

If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

> Would probably be better to spend developer time on more aggressive preloading then.

That should be considered regardless, it's not an either-or situation.

> If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

I said simple app, not completely trivial app! :)

I hate when "fonts" are lazy loaded

.. whenever the fonts are loaded, the whole page changes, and I cannot longer keep a sane reference of what I was reading

Reply on news.ycombinator.com