Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I think I kind of hate lazy loading

shkspr.mobi

Post reply on HN
Print view View original

171–180 of 182 posts

Re: I think I kind of hate lazy loading

#171

Post by JohnFen »

forgotmypw17 wrote: post #7

Lazy loading breaks a lot of functionality. For example, I open a webpage and then go offline. Later, I scroll down, but the content is missing. Another time, I open a webpage and save it. But most of the content is not saved, because it has not been loaded. The network activity is actually higher for a page with lazy-loading elements. All-around, it does not make any sense to me, personally.

> I open a webpage and then go offline. Later, I scroll down, but the content is missing.

This bites me often, too. It's always infuriating.

Re: I think I kind of hate lazy loading

#172

Post by ttfkam »

vorpalhex wrote: post #6
ttfkam wrote: 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.

Right, because it's expensive and difficult and would make the train cost more. You could have truly wireless electricity power your phone and never have to recharge. You just need to invest in more infrastructure.

> Right, because it's expensive and difficult and would make the train cost more.

That you (and others) think network connectivity is anything higher than a rounding error in terms of rail infrastructure costs is likely part of the problem.

Re: I think I kind of hate lazy loading

#173

Post by chrismorgan »

iggldiggl wrote: post #160
chrismorgan wrote: post #58

> There's no way to disable Lazy Loading on Android Chrome or Android Firefox. I haven’t tested it, but I would expect that Firefox for Android would still support going to about:config and changing… hmm, looks like dom.image-lazy-loading.enabled is no more, so I suppose you can just set dom.image-lazy-loading.root-margin.bottom to an enormous number (probably don’t need to worry about top/left/right, but you can do…

If you'd tested, you would have found that unfortunately access to about:config has been disabled on the release (and I think Beta, too?) versions of Firefox for Android.

Back when I was using Android, I ran Firefox Nightly, just like I do on my laptop, so I knew about:config worked! I was not aware it was disabled on release, which seems pretty roundly just a silly and unreasonable restriction.

Re: I think I kind of hate lazy loading

#174

Post by kwhitefoot »

viraptor wrote: post #83
lancefisher wrote: post #80

Earlier quoted context omitted.

It’s a data driven decision. They a/b tested and found users were more interested in clicking on ads when images were lazy loaded.

Or a more mundane reason: You need to add the dimensions to the image to reserve the page side and prevent skipping. That takes extra effort and is not something people think about. If there are any places that a/b tested changing layouts specifically, I expect it's extremely few. It's much easier to make the background a clickable ad area and some pages do that explicitly.

Why does anyone need to add the dimensions? Surely the build process can do this ahead of time or the server can do it on the fly. It only needs to be thought of once.

Re: I think I kind of hate lazy loading

#175

Post by sfn42 »

RamRodification wrote: post #123
djoletina wrote: post #122

Earlier quoted context omitted.

If I understand correctly your beef is with the fact that they don’t have an “Apply filters” button and not lazy loading? Also they’re probably not trying to save bandwidth but database servers.

Not OP, but I think the beef is that the act of applying a filter requires a reload of anything at all ("hey, server, please send me the list of only 16GB pairs this time"), when it's perfectly possible to just send the full list of items to the client initially and then have filtering apply instantly, client-side, on that already loaded list. At least that's the beef I have, and was reminded of when reading the pare…

Rather than sending the full dataset (which could be fine if it's small), just do serverside filtering. And rendering for the most part.

It drives me nuts how much completely useless JS is written. 90% or more of web apps could easily be serverside rendered with maybe a few small scripts added.

Instead we have this shit, people writing hundreds or even thousands of lines of JS to make this dumb ass auto-refreshing search/filter page whose only purpose is to make a bunch of pointless requests and computation while I'm in the process of building my query.

Just have the filters be a form and the search button submits it. The backend executes the query, builds the page and returns it. Easy peasy, no pointless requests, no sending megabytes of pointless data in response to every request. No complex JS(which by the way is an absolute shit-tier language for anything beyond 100 LOC) logic.

I may be biased due to my personal experience, personally I find that the vast majority of JS I'm forced to deal with shouldn't exist. It's either a result of bad application design, bad API design, JS that just does things html and CSS do better, or dumb ass requirements like "we need this filter page to update the results every time the user does anything". No you don't, you just need a way to build a query and a way to submit it. And paginate it.

"But page loads take too long that's why we use SPAs" they take too long because you're sending megabytes of pointless JS that shouldn't exist. Remove the JS and they're fast. Plus SPAs are frequently slow as shit anyway, because most web developers just kind of suck and write shitty code. Like sending a huge Json document with every request rather than handling it in the backend.

Re: I think I kind of hate lazy loading

#176

Post by viraptor »

kwhitefoot wrote: post #174
viraptor wrote: post #83

Earlier quoted context omitted.

Or a more mundane reason: You need to add the dimensions to the image to reserve the page side and prevent skipping. That takes extra effort and is not something people think about. If there are any places that a/b tested changing layouts specifically, I expect it's extremely few. It's much easier to make the background a clickable ad area and some pages do that explicitly.

Why does anyone need to add the dimensions? Surely the build process can do this ahead of time or the server can do it on the fly. It only needs to be thought of once.

You still need to either use a fully integrated dev/build system which allows it, or explicitly add the placeholders. The build process of course could add the actual numbers, but I don't think I've ever seen that happen outside of CMS content. (Specifically content, not even the theme / static stuff)

Re: I think I kind of hate lazy loading

#177

Post by wruza »

sfn42 wrote: post #175
RamRodification wrote: post #123

Earlier quoted context omitted.

Not OP, but I think the beef is that the act of applying a filter requires a reload of anything at all ("hey, server, please send me the list of only 16GB pairs this time"), when it's perfectly possible to just send the full list of items to the client initially and then have filtering apply instantly, client-side, on that already loaded list. At least that's the beef I have, and was reminded of when reading the pare…

Rather than sending the full dataset (which could be fine if it's small), just do serverside filtering. And rendering for the most part. It drives me nuts how much completely useless JS is written. 90% or more of web apps could easily be serverside rendered with maybe a few small scripts added. Instead we have this shit, people writing hundreds or even thousands of lines of JS to make this dumb ass auto-refreshing se…

But it isn’t huge. I just checked how much data my local pc store fetches for the first page of RAM, 18 items total. It does too much ajax-in-json bs to estimate, but let’s assume each product uses 500 bytes, which is more than reasonable. It’s roughly 9kb total. The first RAM image on that page is 8kb. So the pictures on that page alone are roughly 18x bigger than that json. That means if there’s 18 pages of RAM, and there was 35 actually, the whole json is as big as one-two pages. Iow, unless a user changes just one filter and then buys immediately, it’s more effective.

As a consumer, this all feels like being between two fires. One side creates the stupidest UX possible, where one change can fix that, while the other side claims it’s all bs anyway and we must go medieval. Can’t we just listen to a user for once?

Re: I think I kind of hate lazy loading

#178

Post by sfn42 »

wruza wrote: post #177
sfn42 wrote: post #175

Earlier quoted context omitted.

Rather than sending the full dataset (which could be fine if it's small), just do serverside filtering. And rendering for the most part. It drives me nuts how much completely useless JS is written. 90% or more of web apps could easily be serverside rendered with maybe a few small scripts added. Instead we have this shit, people writing hundreds or even thousands of lines of JS to make this dumb ass auto-refreshing se…

But it isn’t huge. I just checked how much data my local pc store fetches for the first page of RAM, 18 items total. It does too much ajax-in-json bs to estimate, but let’s assume each product uses 500 bytes, which is more than reasonable. It’s roughly 9kb total. The first RAM image on that page is 8kb. So the pictures on that page alone are roughly 18x bigger than that json. That means if there’s 18 pages of RAM, an…

I said:

> sending the full dataset (*which could be fine if it's small*)

In the specific case of search/filter pages, I prefer the server-side rendered experience as a user. If I want to just check the box for RAM and search instantly, I can do that. But if I want to build a more complex query I don't need it to keep updating over and over.

I don't necessarily hate the auto-updating pages if they are implemented well. I just don't think they're any better, so why waste dev hours on it? It costs money to maintain that code, and the more of these pointless little JS applications you bake into your website the more expensive it is to build and maintain.

Re: I think I kind of hate lazy loading

#179

Post by sharlos201068 »

JohnFen wrote: post #159
zanellato19 wrote: post #156

Earlier quoted context omitted.

Then the server send you 2k products every time because you might want one? This is insanity.

Why is it insanity? Web sites have no problem sending megabytes of largely worthless data and code as a matter of course anyway. Why can't some of it be useful?

Because the application files are cached and aren't sent on every request.

Re: I think I kind of hate lazy loading

#180

Post by sharlos201068 »

pradn wrote: post #163
unsupp0rted wrote: post #90

Earlier quoted context omitted.

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).

That comes at the cost of increased unnecessary bandwidth and battery usage though.

As a developer I'm much more interested in optimising for that than accommodating a minor improvement to the experience when experiencing connectivity issues.

Post reply on HN