Hacker News Reader

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.

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.

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?"

( I didn't downvote the parent )

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

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

Is it acceptable that this is the state of the art? That, 15-20+ years on, we are fixing the same problem and, further, that we are doing so by rolling a bunch of cruft into yet another framework? Is this really what we are shooting for?

>A drop-in component to...

>Drop this in, and worry about something more interesting

Drop it in after learning and adopting a fairly heavyweight framework that forces you to code to a completely different paradigm. Do we really think this is an acceptable solution for simply displaying images on a Web page? I think that's really telling WRT how far off the map we've wandered.

>Doesn't that kind of cover your complaint?

>I feel like these are all attempts to resolve the issues you're speaking toward.

I think React and others are really symptoms of the problem, which is an impedance mismatch between the static document model that underpins the platform on which we are now trying to build fully dynamic applications.

Rather than continuing to paper over browser deficiencies, there needs to be some collaboration between the webdev and browser communities to define more consistent behavior for common scenarios and a standard component/event based model of the type that has proven suitable for GUI-based applications. The Web standards of HTML, DOM, CSS, etc. should not be first-order constructs in this new model. That is, devs should not work in them directly and, to the extent that these standards are useful due to their currently-broad browser support, they should be generated by tooling. We should be laying out our UIs on canvases in our IDEs with flexible grid layouts, and hanging event handlers off of various events a la Swing.

We need to break the current DOM/old Web model that tells us React and others are good simply because they make the impedance mismatch slightly less painful and paper over some browser deficiencies.

(I didn't downvote your posts either)

I went on a weird tangent with my reply to this comment and just I'm just going to replace it with this. I generally agree with what you're saying as a means forward, but I also think React is a fantastic tool in the meantime.

What we have is, in fact, the state of the art for better or worse. We will get beyond this, but it clearly takes time.

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.

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

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

Lol... this is way easier said than done. The ironic thing is, this has been attempted several times. In fact I would argue this thinking led to the React ecosystem.

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