Live data from Hacker News

I think I kind of hate lazy loading

shkspr.mobi

161–170 of 182 posts

Re: I think I kind of hate lazy loading

#161
post #158

Earlier quoted context omitted.

Competitors use them to ever so slightly undercut your prices, get a higher position on said comparison sites, and run you out of business.

If you aren’t on comparison sites at all because of your anti-scraping measures, is that better?

Not to defend the practice but I think the intent is to allow scraping (or API access) only by the price comparison site but not by competitors. (Why wouldn't the competitors then just scrape the price comparison site? Because that site also has anti-scraping measures in place...)

Re: I think I kind of hate lazy loading

#162
post #51

Hardly any app is designed for subway riders. If they were, we'd have widespread preloading (like half an hour of tweets pre-loaded), seamless delayed posting (sending a new post when the internet comes back online), and visibility into what's downloading and uploading so users can make informed choices. As with all accessibility affordances, this will help people beyond the targeted group - like air travelers, folks…

I dunno, a number of apps I use on the subway are designed for such uses, including audiobook apps, podcast apps and many news apps (e.g. The Economist). But yes, other apps that could be designed that way may not work as well as they should. But even Netflix and YouTube can suggest downloads in advance now. Some apps will never be fully updated - for example, while the standard Mail app works great offline (it's get…

I'm with you - a lot of them are, but too many are not. I personally use the NYT and FT news apps in the subway quite a bit.

In terms of pain points, the biggest is Safari. It gets rid of website state pretty quickly. I have tons of disk storage on my phone, why not serialize to disk? It could even be a "frozen" mode that still lets you scroll saved articles. It wouldn't be so useful for web apps, of course.'

Re: I think I kind of hate lazy loading

#163
post #51

Hardly any app is designed for subway riders. If they were, we'd have widespread preloading (like half an hour of tweets pre-loaded), seamless delayed posting (sending a new post when the internet comes back online), and visibility into what's downloading and uploading so users can make informed choices. As with all accessibility affordances, this will help people beyond the targeted group - like air travelers, folks…

It's the subway where you are that's not designed for apps. On Korean subways I stream video at max res throughout the ride.

We're always going to have situations with intermittent network connections. It's best to design for that from the first. An offline-first experience is good even if you have a good network connection: lower latency (read from disk) and lower energy (the phone radio will be on for less time).

Re: I think I kind of hate lazy loading

#164
post #51

Hardly any app is designed for subway riders. If they were, we'd have widespread preloading (like half an hour of tweets pre-loaded), seamless delayed posting (sending a new post when the internet comes back online), and visibility into what's downloading and uploading so users can make informed choices. As with all accessibility affordances, this will help people beyond the targeted group - like air travelers, folks…

I'm not surprised that this is the case (I've made that same decision myself). But there are some apps that I just done understand: airline ticketing apps, theme park apps, etc. How is handling offline usage not ofne of the first requirements.

Gmail does not cache email attachments so ticket attachments are always iffy at busy venues. I usually just screenshot the ticket QR code now so I have it no matter the network situation at a crowded event.

Re: I think I kind of hate lazy loading

#165

Earlier quoted context omitted.

Instead of all the complexity and code and branch predication, how about just send the page and the images? If lazy loading is super important, the browser can lazy load and render off screen. Don't make thousands of solutions for thousands of platforms on the server side.

I don't understand your comment at all. Before the loading attribute on img, developers did have lots of custom solutions for lazy loading. A major point of lazy loading is to save resources on the server that would be wasted when serving an image that is never seen.

I like the loading attribute, but it hasn't been supported in Safari until very recently, so the solution has had to be a bespoke server + javascript solution to please Google. Still think a better solution is for the browser to optimize what is "below the fold" and make the decision based on user preference (I want to load the whole page). And most importantly, Google shouldn't weigh in on how to implement pages.

Re: I think I kind of hate lazy loading

#166
post #92

Earlier quoted context omitted.

If you have Youtube's paid version, you can have the app automatically preload content it thinks you'd like. This has saved my ass plenty of times when my ADHD brain needed content in places where I didn't have internet.

That sounds like paying a subscription for a crack dealer in a rehab centre :p

I need that CONTENT! :<

Re: I think I kind of hate lazy loading

#167
On my blog, I have a script that goes through lazy loaded images (which is all of them) and flips one to eager (in order down the page) every 5 seconds. Keep a page open for a minute, all images will be loaded, but if you close after 10 seconds, almost nothing extra is loaded.

Re: I think I kind of hate lazy loading

#168
post #5
post #2

It's curious that some folks hate the side effects of insufficient infrastructure while missing that the lack of modern infrastructure is the root problem. It is entirely possible to get a cell signal on a train, even in tunnels. We as a society just choose not to build out the necessary infrastructure.

As a software developer I have very little control over rail infrastructure. However I have almost total control over the HTML attributes I emit.

As a user, I have very little control over 99.999% of all sites' infrastructures. We were talking about lazy loading on a train. Most users have no control over the HTML attributes they receive.

As software developers make up a vanishingly small amount of all users on trains, it seems prudent to highlight their collective experience, not the portion of a one-off that you can control as an individual contributor.

I'm well aware that you or I as individuals have very little control over public transit infrastructure. It's a shame we cannot team up as a group to solve these issues rather than fixate on our experiences solely through a personal lens.

Re: I think I kind of hate lazy loading

#169
post #10
post #2

It's curious that some folks hate the side effects of insufficient infrastructure while missing that the lack of modern infrastructure is the root problem. It is entirely possible to get a cell signal on a train, even in tunnels. We as a society just choose not to build out the necessary infrastructure.

Ah, it's the users who are wrong! In all seriousness, as engineers we of course can't assume the happy path is common, and to ensure good UX more often than not we need to account for these cases.

I'm not sure how you possibly got that reading from what I wrote.

I'm am discussing a solution rather than a series of ephemeral and incomplete fixes. Not that developers can solve public transit issues but that society at large is the only one that can truly solve these issues.

The users are not wrong in my assertion nor do I think disabling lazy loading is the solution. Disabling lazy loading is an ephemeral and incomplete fix that helps some scenarios while degrading the experience in other scenarios.

The solution is improved infrastructure. I don't see why this position is controversial.

Re: I think I kind of hate lazy loading

#170

Earlier quoted context omitted.

I wish browsers did this automatically so that the back button works properly instead of being just a guess on whether you pressed it or not.

I wish the back button would bring back the rendered view of a page from a cache so that it would be (a) instant, and (b) not make any network requests. It seemed to me that older versions of the Opera browser did this, and the text-based "links" browser seems to do this today.

I'm confused - my browser does exactly that, and so do others' around me.

I've even had an issue on a project recently caused exactly by the rendered view being saved for the back button. I've also had to demonstrate a possible issue with full page loaders on a regular website twice for the same back button reason - because apparently people (or at least several of my colleagues) don't find browsers' native request loading indication enough anymore... Rotten by JS loaders and SPA's, I guess?

Post reply on HN