Vanilla-lazyload: Local install of latest version with IntersectionObserver?

[axlright]

Thank you for this amazing tool / repo.

Question - Is it possible to locally run both v8 without IntersectionObserver and v10 with IntersectionObserver using the conditional mentioned here:

(function(w, d){
    var b = d.getElementsByTagName('body')[0];
    var s = d.createElement("script"); s.async = true;
    var v = !("IntersectionObserver" in w) ? "8.7.1" : "10.5.2";
    s.src = "https://cdnjs.cloudflare.com/ajax/libs/vanilla-lazyload/" + v + "/lazyload.min.js";
    w.lazyLoadOptions = {}; // Your options here. See "recipes" for more information about async.
    b.appendChild(s);
}(window, document));

npm install looks to be v8.7.1 and it seems the only access to the v10 is through the Cloudflare CDN.

There's no particular reason I'm looking to host it all locally other than I just generally try to host and run scripts locally and manage updates through npm.

I guess this would also bring up the issue of trying to use npm to load two versions of one application, which may not be possible.

Thanks for any guidance.

[verlok]

Hi @axlright,
thank you for your question.

We’ve been there before and we found that’s not possible to install 2 different versions of any npm package.

That’s why I’m providing the script to conditionally load the 2 versions from cdnjs. It can be any other CDN if you prefer to use your own.

You can download any other version of LazyLoad from both cdnjs, npm and GitHub itself (see Releases).

Let me know if I can be of any other help.

[axlright]

@verlok Thanks - totally understood. Your suggested / included script for conditionally loading works perfectly.

My next step is to figure out a way to include both in the website's single app.js and load the correct parts based on whether IntersectionObserver exists.

I'll close this issue - thanks!

[verlok]

Hi @axlright,
I fail to understand why would you want to do such thing.
Put all the code in the app.js file would mean to always have some code that is downloaded, but never executed.
If I’m allowed to give you an advice, I think you should think about “conditional load”, not “conditional execute” of the code.
Let me know if that makes sense to you.

[MEmanuelsson]

Just thought I'd add a question somewhat related to this issue. We've decided to go for version 10.5.2 in combination with the polyfill available for IntersectionObserver (in our case loaded from https://cdn.polyfill.io/v2/polyfill.min.js?features=IntersectionObserver) instead of the conditional load of 8.7.1, is this maybe a bad idea for some reason? Works fine as far as we've seen (except for the additional polyfill load for browsers that don't know of IntersectionObserver). Any input would be helpful.

[axlright]

@verlok You're right and I appreciate the advice. Conditional load is way smarter than conditional execute. Sometimes I think of things then catch myself halfway through doing them and realize - "this is not the right approach"

For some reason, I have a tendency to favor locally hosted scripts as opposed to external ones loaded via CDN. I can still easily load them locally using the conditional load script you have adapted just to locally hosting the two scripts in two directories named after the version numbers as you have set up through Cloudflare. Thanks again for your input.

@MEmanuelsson - that sounds pretty interesting. Am interested in hearing more about how it work out.

[MEmanuelsson]

@axlright For us this has worked out just fine, as far as we know at least :-) We still have about 10-12% customers (and employees) using IE11 and lazyloading works just as good there as in Chrome and Firefox for instance.

[MEmanuelsson]

@axlright Just found this issue (https://github.com/verlok/lazyload/issues/185) where @verlok mentions this as a potential solution for browsers not supporting IntersectionObserver with the comment "not sure if this works". As far as I know this works just fine but please give it a try you to and let us know how it works out.

[verlok]

To the off-topic sub-thread opened by @MEmanuelsson, I opened #202 and replied there. To @axlright I'm replying to you now. Hold on.

[verlok]

@axlright wrote:

For some reason, I have a tendency to favor locally hosted scripts as opposed to external ones loaded via CDN.

You say "locally hosted scripts" as if you were embedding your script inside the HTML of your application. If you don't do that, you're still hosting your script remotely. And remotely means that the network can fail, and it WILL fail. Using a CDN to host your scripts is much safer, since there are multiple copies of the script and if the best host fails for some reason, the network request is served by another.

This was just about to make you think about what's the meaning of "locally hosted" to you, but I got the sense of your sentence. You want all the scripts to be served by the same source, so if it fails, it fails all along the way. It's an interesting idea, but still I hope you're using a CDN to do that otherwise... you have a SPOF (single point of failure)!

A really good thing you could do is to have all your code in one place, use conditional loading to load LazyLoad from CDNJS, and detect the script load failure with a try-catch block. In the catch, query all the lazy images in the application copy the data-srcset and data-src attibutes to the respective srcset and src.

[axlright]

@verlok Sure thing but if my server fails, then the website has failed and no one is seeing anything anyways 👎

It's a point of personal preference. If we place the scripts on our host along with our css, js, fonts, images, video files and the like, then I know where they are and it's not up to someone else's service.

But I hear your point.

Thanks for such a great project. Initial page load went from 47 resources and 1.1MB (already pretty low) to 16 resources and 0.3MB - pretty awesome! Using this in conjunction with Critical CSS and finely tuned responsive images to get page load way down.

[verlok]

Ok sorry, I was taking for granted that you were not serving your static files (css, js and images) from the same place from where you serve your application, and that you used a CDN for that. My fault. When you scale up to thousands hundreds of users per day, maybe consider using a CDN 😄

[axlright]

Thanks! We have a CDN. It's just ours. Using someone else's CDN address for files means that we're reliant on them keeping the code there and not changing anything including version numbers or url structure. If we keep it all in house, we can rely on our CDN and know where the files are. Same thing for fonts, etc.