Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A tale of webpage speed, or throwing away React

solovyov.net

Post reply on HN
Print view View original

31–40 of 319 posts

Re: A tale of webpage speed, or throwing away React

#31

Post by piranha »

tom_walters wrote: post #11

This is the typical "we didn't spend any time thinking about our architecture therefore we're going to blame our framework" article. React is a great choice for certain use-cases, but when low-quality developers are allowed to pick it up and apply it to everything you end up in a mess. The same thing happens with literally any tool. If you want speedy initial interaction times and manageable codebases, (and requireme…

This is typical "I drink React kool-aid so I'll never give benefit of the doubt to anybody who's not supporting my point of view" comment.

Re: A tale of webpage speed, or throwing away React

#33

Post by ncrmro »

llimos wrote: post #17

For sites that are content-heavy I've started wondering if it makes sense to have the content server-side rendered the old-fashioned way, and use multiple React roots for the parts of the page that need to be interactive. You can still use Redux etc. for managing app state globally (though not React context), and you get most of the gains of load time, and of using React where you need it. It seems everyone uses but…

This map is actually a wordpress plugin that loads locations from google sheets into a JS var that a react bundles loads. Client already had the rest of the site built in Wordpress so easier to just make a plug-in with a shortcode that loads the react bundle into a div.

I and some other built while i was at Poetic in Houston, Tx. https://www.houstonfoodbank.org/find-help/agency-locator/

Re: A tale of webpage speed, or throwing away React

#34

Post by andybak »

blickentwapft wrote: post #20

You can populate an ordinary web page with some react and get the best of both worlds. Plain javascript is painful. It’s nit necessary to throw out react to address the issues identified here. The author comes across as fairly junior.

> Plain javascript is painful.

Which is exactly why he isn't advocating plain javascript. You should take a look at micro-frameworks like Intercooler (and htmx, unpoly alpinejs etc). For devs who don't remember the days before megaframeworks it can be quite illuminating to see a different way of looking at things.

Re: A tale of webpage speed, or throwing away React

#36

Post by piranha »

swyx wrote: post #12

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. You can have a React app without those problems, but apparently, you have to have better self-control than we had (nobody’s perfect!). idk if this is fair. OP was using…

> additionally, I highly doubt that the author has replicated this functionality by using his new turbolinky framework.

Which functionality?

> a bunch of UI requirements

So your point is that you don't really know, but let's blame them for trying, or what?

Re: A tale of webpage speed, or throwing away React

#37

Post by tnova »

piranha wrote: post #27
capableweb wrote: post #10

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using Reac…

The thing is that your tools should be making good this easier than bad things. And React is the opposite of that.

So youb are saying that React makes it easier to do bad things than good things? Would you mind extending on that?

Re: A tale of webpage speed, or throwing away React

#38

Post by kome »

hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

you are SO right... but web developers have decided to go for complexity over simplicity and elegance.

IMHO this happened just because complexity and fads generate so much more money, in the long run.

Re: A tale of webpage speed, or throwing away React

#39

Post by Jestar342 »

hombre_fatal wrote: post #15
capableweb wrote: post #10

> we’ve discovered that React also leads to some questionable practices. Like hovers in JS (rather than in CSS), drop-down menus in JS, not rendering hidden (under a hover) text (Google won’t be happy), weird complex logic (since it’s possible!), etc. This is some strange reasoning that I have yet to seen myself. If you can do the hovers states/drop down menus in CSS, why not do them in CSS, even if you're using Reac…

That first quote (using JS when CSS would be faster and simpler) does remind me of being a beginner and always arriving at jQuery's animate() for all my needs. That said, animation is hard, and React doesn't insulate you from that, so it takes some thought. In fact, being a layer of abstraction, it requires even more understanding of animation. Fading a component in is easy with regular CSS transitions. But fading a…

RE: jQuery.animate() - that was around before CSS animations were. Animations were not in the CSS spec until v3 which only saw widespread support this side of 2010.

Before then you could only do animations with Javascript, and frankly jQuery's `animate()` was a god-send.

Re: A tale of webpage speed, or throwing away React

#40

Post by hestefisk »

hliyan wrote: post #28

When I first read the haiku at the bottom of the HTMX homepage, I had a flash of insight. javascript fatigue: longing for a hypertext already in hand What are we doing? State management libraries? Hypermedia is the engine of application state. Send data to client as HTML and have the client apply styles over it, rather than converting from JSON to local objects and storing in some sort of reactive data store. You wil…

Agree, this is so true. I will give it a few years before we are all back on server rendered web apps.
Post reply on HN