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

21–30 of 319 posts

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

#21

Post by Etheryte »

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…

Talking of bundle sizes, this isn't inherent to the React point being made here but it's arguably too easy to blow up what you're serving. A common example I like to reference is Moment[1] — unpacked size is 4MB, most of which is different locales. If you _don't_ want to bundle all of those with your project, you have to do extra work, instead of making locales opt-in. Perhaps slightly less used, but a more prominent example, a widely-used table component Ag-grid[2] is 25MB before being packed down. Instead of being served as a modular set of components, it's mostly a big blob with minimal separation of concerns.

The takeaway here is twofold: we need better tooling as well as better practices for how to use those tools. It's both an educational problem as well as a toolset issue. It is possible to build lean and fast pages, but it's currently considerably harder than building gargantuan monsters. I don't see the web bloat problem going away until the dynamic here is flipped — it should be easy to ship small bundles even with minimal experience.

[1] https://www.npmjs.com/package/moment

[2] https://www.npmjs.com/package/ag-grid-community

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

#22

Post by ojosilva »

In short, the OP changed the architecture from a client-side rendered app (in React) to a server-side rendered one (built on a custom-made framework cloned from Intercooler.js) and that resulted in a significant performance improvement for their app.

Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from the read. Maybe just "if YOU build/find YOUR own framework for YOUR problem space excitement will follow."

On the other hand, I doubt the complexity issues, also mentioned by the OP throughout the article, was solved by using the new framework. In fact:

> On the developer side, I think React is better still

So tit-for-tat.

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

#23

Post by brainless »

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…

I have been with React for 4 years now. Link state can be driven through React if you are testing some state or URL (active URL). But hover should never be React driven. I can not fathom why anyone would do that.

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

#25

Post by piranha »

ojosilva wrote: post #22

In short, the OP changed the architecture from a client-side rendered app (in React) to a server-side rendered one (built on a custom-made framework cloned from Intercooler.js) and that resulted in a significant performance improvement for their app. Overall not a good critique of React as such to justify the "throwing away React" title in the front page of HN. In fact, not a lot of good conclusions can be drawn from…

Okay, maybe I should elaborate a bit on that. But React is better for developer experience like it is. But when you're talking about code splitting and service workers and other crap it's just a deepest rabbit hole out there. It's unmanageable.

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

#26

Post by andybak »

> So I made a proof-of-concept implementation of our catalogue page in Intercooler and it worked! Except there was a dependency on jQuery and some other irritating stuff…

Actually the original author of Intercooler has a renamed 2.0 version that removes some warts - including the jQuery dependency: https://htmx.org/

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

#27

Post by piranha »

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.

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

#28

Post by hliyan »

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 will find that semantically structured HTML is almost as economical as JSON.

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

#29

Post by piranha »

capableweb wrote: post #16
swyx wrote: post #13

Earlier quoted context omitted.

they were using handrolled SSR in clojurescript, I'm not sure they set up code splitting.

> I'm not sure they set up code splitting Don't think that matters. I've written (from scratch and inherited) and deployed many ClojureScript frontends, from one page ones with lots of interactivity to 30+ pages/sections, none of them reaching the size of 2.5MB minified (when using the production settings for Closure Compiler). Add in SSR and/or code splitting and the weight should be nowhere near there, leading to t…

Oh yeah, binary assets. Yeah, it is certainly binary assets. We just embed node.js in there. /s

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

#30

Post by voldacar »

onion2k wrote: post #19

We need to look at it from two sides: if it’s good for developers and if it’s good for users. React was great at former and terrible at later. React is not "bad for users". Developers build complex, fast apps with React all the time. It can be fast, but if you make mistakes with it then it's easy to make something very, very slow. The app I work on is huge. It's ~8MB of uncompressed React + Redux in development (much…

How performant! How performant!
Post reply on HN