5 ms·

I 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 browse

I 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 ago
I'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 ago
This 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.
unclebucknasty 8y ago
I don't get why a comment like this is downvoted. The commenter is simply saying that he doesn't understand the hype. This site is getting nearly unbearable with the groupthink, particularly around specific tech or frameworks. /meta On this particular issue, I will go further than my parent and say this does not represent a significant step forward in the scheme of things. The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS. It is positively nuts that we are celebrating a "fix" for it all of these years later, and that we are investing so much time on what should be routine by now. Anyone who is genuinely excited about this should sincerely be asking themselves if it's a good thing that a lengthy post/fairly involved component for sanely displaying images in a browser is the state-of-the-art for Webdev in 2018. Yes, I get it: browsers don't do x or y. So, yeah, let's add more libs, more frameworks, more shims, more specs...more, more, more. It's almost self-parody by now. Look at the average Webapp of any semi-significant complexity. It is such a hodge-podge of code, languages, technologies, build steps, etc. that it's a wonder any of it works. 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?"
- shawn 8y ago
  As someone who's been here from nearly day one, there has been groupthink around specific tech and frameworks from nearly day one. :) 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.
  - unclebucknasty 8y ago
    >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. Thanks, but I've clearly not made my point! I am saying that we don't need to each run off and create more solutions as that's how we got here in the first place. That is, we can't solve the problem of too many "solutions" by creating more solutions. So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top.

alex504 8y ago

I'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 ago

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

unclebucknasty 8y ago

I don't get why a comment like this is downvoted. The commenter is simply saying that he doesn't understand the hype. This site is getting nearly unbearable with the groupthink, particularly around specific tech or frameworks. /meta On this particular issue, I will go further than my parent and say this does not represent a significant step forward in the scheme of things. The problem being solved here is largely akin to a problem I had to solve 15+ years ago with Vanilla JS. It is positively nuts that we are celebrating a "fix" for it all of these years later, and that we are investing so much time on what should be routine by now. Anyone who is genuinely excited about this should sincerely be asking themselves if it's a good thing that a lengthy post/fairly involved component for sanely displaying images in a browser is the state-of-the-art for Webdev in 2018. Yes, I get it: browsers don't do x or y. So, yeah, let's add more libs, more frameworks, more shims, more specs...more, more, more. It's almost self-parody by now. Look at the average Webapp of any semi-significant complexity. It is such a hodge-podge of code, languages, technologies, build steps, etc. that it's a wonder any of it works. 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?"

shawn 8y ago
As someone who's been here from nearly day one, there has been groupthink around specific tech and frameworks from nearly day one. :) 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.
- unclebucknasty 8y ago
  >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. Thanks, but I've clearly not made my point! I am saying that we don't need to each run off and create more solutions as that's how we got here in the first place. That is, we can't solve the problem of too many "solutions" by creating more solutions. So, I think step one is to step back, all take a breath (devs, browser-makers, etc.) and look at creating a reasonable, cohesive platform for proper Web-development, free of the legacy baggage of a static document-based foundation with reams of duct tape on top.