8 ms·
Show HN: An Almost Ideal React Image Component
- jbob2000 8y agoThis is amazing, but I feel like there is something fundamentally lacking from <img> if you have to do all this bullshit just to get an image to display. Why can’t the image and DOM spec be upgraded to include lazy loading and touch to download? I can’t think of a use case where you wouldn’t want this.
- stereobooster 8y agoRead this https://github.com/whatwg/html/issues/2806 https://github.com/whatwg/html/issues/2806
- jbob2000 8y agoRead the whole thing. As is typical with committees, they harp on about crap that doesn’t matter to 99% of users, and thus any viable solution gets delayed indefinitely. So I guess we get shitty image loading across the whole web, oh well.
- TheRealPomax 8y agoThat's kind of the browser's responsibility, really. The image element already covers what is required to instruct the user agent that there a) is an image resource and b) what its location is. It's then up to the browser to do the right thing with that data. It's nice that people are finding ways to preempt that in case the browser they're in is dumb as dirt, but it's really not the role of the spec to tell user agents how to deal with loads of images. If I'm browsing my gigabit intranet image repositories on any of our workstations, I don't want my user agent to be "intelligent" and just load everything, because it can. If I'm on LTE mobile, I want my browser to be a little smarter about swapping in/out image content. If I'm on 3G, I don't want the browser to load any images at all unless I tell it to. But those are my wants, those are not things the spec should "ordain" user agents must (in the spec definition of must) do. React components like these are nice, but the real question is why doesn't your _browser_ already do this. Not "why doesn't the spec say what needs to happen", but why haven't Microsoft, Google, Mozilla, Opera, etc. implemented network-and-content-traversal-appropriate image handling? (one answer might be "because apparently users don't actually ask for it enough", but I honestly don't know).
- zaroth 8y agoBecause there’s no way to standardize the behavior across user agents to the extent necessary that developers could actually rely on it producing a consistent experience across a large user-base.
- TheRealPomax 8y agoConversely, there is also no way to standardize which solution to use to the extent necessary that developers could actually rely on it producing a consistent experience across a large user-base. You don't need standard behaviour, you just need _good_ behaviour. And if every browser does that differently, but it's appropriate to the network speed and processing capabilities, then as a dev the issue of "making sure images load appropriately" becomes as irrelevant as "making sure your webfont actually loads" has become in the modern browser landscape.
- lozenge 8y agoDownloading all the images provides a good user experience. If your intranet has a GB of images on a single page, that's on you - even if browsers did as you suggest, any older browser would still saturate your network link. These fancy image placeholders seem more designed to save on CDN costs than to provide a good UX.
- TheRealPomax 8y agoI think you misread what I said as "I want the browser to load all the images, all the time" instead of "I want the browser to download and render in ways that are appropriate to the constraints of the network and processing power, not have to rely on a million folks each inventing their own lazy-loader".
- yesimahuman 8y agoPerfect opportunity for a reusable web component that anyone could consume
- tootie 8y agoI think this is a typical lifecycle. The community will be a magnificent shim or two, then the committees will wait and see if it's a winner, then start adopting the key elements. That's why nearly all of jQuery is now supported natively by browsers and why we have <video> tags instead of flash.
- sunsetMurk 8y agoWell this is very cool. On my MVP projects I'm happy to get any of those things to happen. I would LOVE an angular service that did this that I can re-use. If only I had the time to fork this and make it work... May need to explore this over the weekend. Thanks for putting this together!
- faitswulff 8y agoIt would be helpful if the repo stated why this was ideal - and as opposed to what?
- JasonSage 8y agoIf you click through it actually tells you all the things it provides which you wouldn't get with a vanilla img tag.
- faitswulff 8y agoAh, didn't realize it wasn't a top-level readme. For the lazy: > 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.
- matthberg 8y agoIt would be cool to optionally integrate SVG placeholders, a-la: https://medium.com/@jmperezperez/using-svg-as-placeholders-more-image-loading-techniques-bed1b810ab2c https://medium.com/@jmperezperez/using-svg-as-placeholders-m... (previously discussed: https://news.ycombinator.com/item?id=15696596 https://news.ycombinator.com/item?id=15696596)
- crooked-v 8y agoThat seems like it would require a compile step with a file loader, which is generally doable but means you need handling for (for example) Webpack vs. Parcel vs. whatever else.
- stereobooster 8y agoIt supports SVG placeholders. SVGs need to be converted to data URIs, like `data:image/svg+xml,%3csvg xmlns='...`, and it works the same as LQIP. You can use https://github.com/stereobooster/sqip.macro https://github.com/stereobooster/sqip.macro to generate those
- ggregoire 8y agoWow this is great. Right now I'm using a homemade <ImgWithPlaceholder src={src} /> that displays a generic gray PNG on 404 or src null. I'll definitely try your lib as a replacement. I'm excited about the out-of-the-box lazy loading and the LQIP (never heard before.)
- dstroot 8y agoWhy do I love stuff like this sooo much? (I really do) Consider the yak shaved. :)
- stereobooster 8y agoOh yes. More than one
- meesterdude 8y agoI know this'll get downvoted, but this looks like an awful lot of work for... displaying images in a browser. As other HNers have said, it feels like the browser should be doing this work rather than having to create round about, convoluted JS solutions to deliver simple functionality. Plus, I don't get what's exciting about this. But I'm also not a react guy - and this does nothing to make me consider picking it up. Which, is counter to all the cool JS libraries i've pulled into projects over the years, which naturally induced a desire to learn more JS. I guess if you're hyper focused on react or frontend js in general, this sort of stuff might be more appealing and relevant. but dear god I've got way more important/interesting things to do than spend a day getting images to render in the browser. Nor does this do anything to lower the barriers of entry for people with an idea and a desire to build something. Sometimes I wonder if that's a design intent. anyway, sorry for the rant. Great job identifying/solving problems, but i don't get the appeal.
- alex504 8y agoI'll reply because it seems like 25% of every thread I've read on front end development in the past 5 years has a comment like this. This library doesn't really have anything to do with React. Just because it is implemented in React doesn't mean that React needs this, over say Vue or Angular or VanillaJS or w/e "cool" library you like. In fact I would say the existence of libraries like this should make you want to adopt React over a library with less adoption. I would also suggest you be more open to the idea that these kinds of things matter quite a bit when you are operating at scale. This type of library isn't really intended for the use case where spending time making optimizations isn't important or interesting.
- crooked-v 8y ago> Plus, I don't get what's exciting about this. Substantially cutting down loading time for a page with 800 high-quality images while still being able to write components in a completely declarative manner.
- stevenhuang 8y agoThis is about performance and UX. Respect for the user. Yes, browsers should be doing this. But they don't. So other than the obvious, what do you propose? > this does nothing to make me consider picking it up. Which, is counter to all the cool JS libraries i've pulled into projects over the years, which naturally induced a desire to learn more JS. For shame. What this tells me is that you essentially don't care about your users. The notion of this being something only react/frontend developers care about is also quite off-base. Lets include all the "cool" JS libraries under the sun until the page is bloated, but definitely not the ones that try to make the site perform better... ? Yeah not a good attitude. Perhaps if you imagine yourself on a metered connection, navigating to a page with a bunch of hires images, wouldn't you appreciate the work the developers put into making the site a better experience for you? That respect for the user is the appeal.
- samhunta 8y agoThis is a great start. Some lightweight features that would make this even more ideal (for me) would be: - retina/3x support - support for styled components extend feature (if can be made a lightweight implementation) - maybe default max width of 100% on mobile? - optional ability to overlay an empty full size block so the image cant easily be right clicked and saved
- stereobooster 8y agoIt supports retina/3x. Provide big enough image and it will use it. It takes into account `devicePixelRatio` > maybe default max width of 100% on mobile? It is. > optional ability to overlay an empty full size block so the image cant easily be right clicked and saved Not sure what you mean, but as soon as image loaded it turns into good old image, so you can do right click
- anonfunction 8y ago>> optional ability to overlay an empty full size block so the image cant easily be right clicked and saved > 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.
- jabn76 8y agoI hate lazy loading. - bit offtopic: Are there any good browser extensions that stop this behaviour?
- stereobooster 8y agoCan you explain why?
- ec109685 8y agoYou have to wait for react to load and initialize on the client before an image can load.
- connorelsea 8y agoimages and everything else bc client-side rendering... not sure how this is an argument for not lazy-loading images though
- anothergoogler 8y agoAs an end user it feels slow. If I hold my space bar on a website created in 1995, I can scan the entire page contents.
- connorelsea 8y agoYou'd still have blank spaces where large images are as they're loading on a slow connection
- anothergoogler 8y agoI'm talking about lazy loading that waits until the image enters the viewport. An HTML page created in 1995 loads the images eagerly.
- stereobooster 8y ago
- deleted 8y ago[deleted]
- stanislavb 8y agoSeems very interesting. I'll give it a shot and try integrating it @ SaaSHub.com. Thanks for sharing and implementing it.
- chrismorgan 8y agoYou know what’s an almost ideal image component? <img>. Sure, browsers could be a little cleverer about prioritising image loading, and I wish everyone would prefer to slim their images down somewhat, but compared with all other attempts I have encountered (with no exceptions), <img> is almost ideal. I unconditionally hate all scroll-based lazy loading of images. Any other forms of lazy loading of images such as you outline in this post I will also hate, p≥0.96. And attempts to be clever like detecting high latency and working otherwise in such situations normally mess up what I want to happen. I’ve written about these things before and I’ll doubtless write about it again; https://news.ycombinator.com/item?id=16518010 https://news.ycombinator.com/item?id=16518010 is the last time I wrote about it on HN and some discussion arose. (The previous time was on the SVG image placeholders article linked elsewhere in these comments.)
- deleted 8y ago[deleted]
- chacham15 8y agoMost of this comment is just you being dismissive about an idea without any real reason presented for being dismissive. The only useful bit here is actually in your linked comment which most people will probably not see and that is that lazy loaded images tend to fail a lot on poor internet connections. I would argue that even in that case, lazy loading images arent necessarily bad depending on the situation: imagine a site like imgur, where you will likely browse to another page without ever loading all of the images. In that case, the browser would still have loaded the image if it were an img tag and this way you get to the next page faster. Sometimes the browser will cancel the img download, but its not reliable. If the js were coded to handle errors on loading the image, that would probably be a better situation overall.
- chrismorgan 8y agoIt’s much worse than just the potential for failure, as I indicate in other places I’ve written about it. If I ever see evidence that scroll-based lazy loading has occurred, it has failed in its mission: it didn’t load the image in time. And in practice, this happens a lot of the time, especially in higher latency situations. You can’t sufficiently-well predict what the user is going to do and so only load it just in time. It doesn’t work. 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.
- TheAceOfHearts 8y agoI've previously experimented with image loading components for fun. Similarly, I implemented the material design image loading spec for the web a few years ago. This may come off a bit negative, but I disagree that it provides a better UX. I don't know if I've grown jaded or cynical, or if we just have drastically different preferences. I think embedding a thumbnail with a link to the full-sized image is better; it's certainly simpler. In general, I don't think the tradeoffs are worthwhile. Some thoughts: * There is no mention of module size. That can have a big effect on your initial pageload. Of course, this depends a lot on the context in which you are using said module. It might still be sensible for certain kinds of galleries, perhaps less so for an application for which images are of secondary concern. * The discussion on performance is too focused on mobile and having very few images on the screen at the same time. What about desktop? What if you plan on having more than two images on-screen at the same time? Doing a comparison with traditional img tags on a grid-view gallery with 100 images would be much more interesting. * I think it would be genuinely interesting to see what the real-world experience would be if you took a popular website and dropped this in. I do not believe that it would often be an improvement. The two sites that come to mind are 4chan and Reddit.
- stereobooster 8y agoModule size is ~7Kb. A detailed comparison is here https://github.com/stereobooster/react-ideal-image/blob/master/other/idealimage-vs-img.md https://github.com/stereobooster/react-ideal-image/blob/mast... > The discussion on performance is too focused on mobile Because mobile users have a slower internet connection and worse CPUs. What kind of performance are you talking about? If load performance, then this component uses well-established techniques (not invented by me), like lazy-loading (known since jQuery times), srcset (web standard), LQIP (used by Facebook, Medium), width, height (required for all blocks in AMP). If you are talking about JS performance like frame rate or paint or "junk" on the scroll - I didn't measure it but didn't say it was the first target either.