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

Native lazy loading has landed in Chrome

dev.to

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Native lazy loading has landed in Chrome

#31

Post by reaperducer »

tobr wrote: post #29
wereHamster wrote: post #24

Earlier quoted context omitted.

I wouldn't say it's common. Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===) wouldn't even be able to tell you for certain what the code does, exactly. Using === to compare against "true" makes only sense if the variable can be something other than boolean (undefined, null, string etc). Or if you are programming defensively – by choice or because the codebas…

The `in` operator always returns a boolean, though.

Maybe it was just done out of habit.

A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.

Re: Native lazy loading has landed in Chrome

#32

Post by rasz »

davidweatherall wrote: post #11
cameronbrown wrote: post #8

Earlier quoted context omitted.

Hmm, maybe if websites don't use lazy loading JavaScript anymore (guilty as charged btw) then you'll be able to configure it however you want in browser settings?

I imagine anti-lazyloading extensions will start appearing soon.

whole extension:

    document.querySelectorAll("img[loading]").forEach(function(e){e.loading="";})

Re: Native lazy loading has landed in Chrome

#33

Post by bgdnyxbjx »

sharpercoder wrote: post #5

As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).

Lazy loading doesn’t have to mean waiting for user input to load a resource, or waiting for the viewport. It just gives the developer a way to break up their bundles and control over when they get loaded a fetched.

A well designed web app would have a small start up bundle so the user can get something useful quickly, and then it would start prefetching and loading the rest of the bundles.

Re: Native lazy loading has landed in Chrome

#34

Post by rubbingalcohol »

holtalanm wrote: post #20
toastal wrote: post #7

I'm happy to see this. So many websites with lazy loading never implemented a fallback for noscript. And most of the popular libraries didn't account for this accessibility.

just curious -- in what situation would your average user not have javascript turned on?

It's hostile to the user to require javascript for non-app pages that don't need it.

Re: Native lazy loading has landed in Chrome

#35

Post by rasz »

zsrxx wrote: post #27
josteink wrote: post #26

Earlier quoted context omitted.

Chrome? Google Chrome and options? Hah! Good one!

about:flags

Show me on the doll where Chrome has an option to disable Ping attribute (dont bother looking for chrome://flags#disable-hyperlink-auditing, its gone), or set custom localstorage quotas?

Re: Native lazy loading has landed in Chrome

#36

Post by icebraining »

city41 wrote: post #30
sharpercoder wrote: post #5

As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).

The article contradicts itself a little bit. It says "Currently the images are fetched with different priority in Chrome, the ones which are not in the viewport have less priority. But they're fetched as soon as possible regardless." But it also says: "lazy: Defer loading of resources until it reaches a calculated distance from viewport." If a lazy image is only loaded when within a distance of the viewport, then you…

I think the first is what happened before this new feature (lazy loading) was implemented.

Re: Native lazy loading has landed in Chrome

#37

Post by tgv »

sharpercoder wrote: post #5

As a developer and systems architect, I really like this. As uset, I hate this so much. On slower connections, I like to load a page, swap tabs, come back later and expect the page to be loaded. This mechanism will now break (and is already brokrn by the usr of these lazy loading libs).

> As a user, ... I like to ... and expect ...

Sorry, but the format made me laugh.

Re: Native lazy loading has landed in Chrome

#38

Post by mark_and_sweep »

reaperducer wrote: post #31
tobr wrote: post #29

Earlier quoted context omitted.

The `in` operator always returns a boolean, though.

Maybe it was just done out of habit. A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.

That's an unreasonable, excessive use of defensive programming.

We're not talking about an unstable API here, we're talking about an operator.

It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.

Re: Native lazy loading has landed in Chrome

#39

Post by city41 »

icebraining wrote: post #36
city41 wrote: post #30

Earlier quoted context omitted.

The article contradicts itself a little bit. It says "Currently the images are fetched with different priority in Chrome, the ones which are not in the viewport have less priority. But they're fetched as soon as possible regardless." But it also says: "lazy: Defer loading of resources until it reaches a calculated distance from viewport." If a lazy image is only loaded when within a distance of the viewport, then you…

I think the first is what happened before this new feature (lazy loading) was implemented.

Ah yes, of course. Thanks.

Re: Native lazy loading has landed in Chrome

#40

Post by kaycebasques »

For anyone hearing about loading=“lazy” for the first time from this article , I’ll reiterate the main idea because the article doesn’t go into much depth about the motivation.

The main idea is that some pages use a lot of cellular data to load images that are further down the page, out of the viewport. If the user glances at the page and decides it’s not relevant and exits, then those offscreen images were just a waste of cellular data. loading=“lazy” addresses this problem by deferring the image loads until the user has scrolled the page and the image is soon to be in the viewport.

Disclosure: I write the Chrome DevTools docs

Post reply on HN