Show HN: An Almost Ideal React Image Component

> Not sure what you mean, but as soon as image loaded it turns into good old image, so you can do right click

I believe he wants the opposite of that, putting a div over the image so it cannot be right clicked and saved.

These fancy image placeholders seem more designed to save on CDN costs than to provide a good UX.

I am inspired by your grumbling to write a blog post entitled “Scroll-based lazy loading of images is always bad”. I won’t publish it for a while so I can treat the subject methodically (and I’m busy for the rest of today), but it will come.

Thanks for the imgur comparison; the wording I’ve used does fall down there; in my mind I had distinguished scroll-based lazy loading and scroll-based lazy loading of images. When talking about scroll-based lazy loading of images, I meant where you have content that contains images, rather than situations where the images are the content. (That is, I’m talking about lazy loading just the <img>, not lazy loading content in general.) There are definitely applications for which loading everything up-front is impossible (e.g. imgur infinite scrolling on mobile) or impractical (e.g. showing all the 10,000 messages in a mailbox in an email client that deliberately eschews pagination, like FastMail); in such situations, lazy loading is necessary and while it will often be annoying and imperfect there is and can be no better solution.

Where images are embedded in the content, however, I think that my position is still reasonable; there is an alternative: just load eagerly rather than lazily. Now articles and blog posts are the primary application I have in mind, and I can’t think of any other applications where my position would not hold—given the caveats of interpretation specified in the previous paragraph—but I’m willing to hear other suggestions.

As a rule, I’d much rather see nothing or a solid colour than a pixelated or blurred preview of the image; I find it and the transition surprisingly disconcerting. I mentioned this at https://news.ycombinator.com/item?id=16516126#16558042 and have heard others agree with me.

Even if I do have a connection and it all succeeds, if the image is not there when I scroll to it, the lazy loader has failed in its job. And that’s pretty much unavoidable in general content—people don’t always scroll smoothly through a page; I may jump down a page at a time, or skim through some headings looking at illustrations that haven’t loaded yet because they only figured I might be interested in them a bit under half a second ago, and latency is half a second plus probably another couple of tenths of a second of annoying fade-in transition. The possibilities are endless.

Come live in Australia for a bit and deliberately use sites from the US with scroll-based lazy-loading: I predict you will rapidly acquire a healthy dislike for the technique! :-)

The typical experience reading a medium blog is that I can spend a minute, or a full 15 minutes, digesting the opening paragraphs. With the page idle that whole time. Then I can scroll down to a big brown smear, and read the whole caption before the associated image finishes loading.

I totally understand these images don't need to load with the first round of content. But you know I'm going to scroll down. Just use a timer or something.

> I need React component to asynchronously load images, which will adapt based on network, which will allow a user to control, which image to load.

> The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS.

Of course these problems (multiple!) can be fixed with vanilla js. They all have been, separately, each in their own libraries and stackoverflow posts and custom vanilla code on every project in the past couple decades. The linked page does an excellent job of pointing out the libraries and SO posts it's utilizing to resolve these issues.

The purpose of the linked component is to pull in all these vanilla js fixes and tweaks at once, in a way they'll all work together. A drop-in component to utilize years worth of tweaks and fixes, so you don't have to worry about this crap anymore. Doesn't that kind of cover your complaint? We shouldn't have to deal with it anymore. Drop this in, and worry about something more interesting.

> I think it's time we all took a step back and ask, "what are we doing? Is this the right model? Is there a better way?"

I picked React long before most of my colleagues did, and I continue to feel it's one of the most useful libraries in quite some time for browser-based javascript development. Mostly because it allows for something like this very library - drop-in and move on to something better.

I was also a huge fan of jquery - not because I couldn't do what jquery was doing for me, but because I was tired of doing it repeatedly for different browsers and for each and every project. Same goes with prototype.js when it first came out, though I hated how it modified the underlying objects.

If I'm understanding your post correctly, I feel like these are all attempts to resolve the issues you're speaking toward. To allow us to stop dealing with cross-browser, cross-device, 2-cans and a string connection issues that, ideally, our browsers should be handling for us.

At least we don't have to rely on flash to replace missing browser functionality anymore (I say that as someone who absolutely loved ActionScript3).

It's not a big deal. Just correct the downvotes and ignore the vocal comments.

I identify with your point of view on this topic. But the way to correct the situation isn't to write a rebuttal here. The world only notices better solutions when they exist, so creating them is step one.