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

61–70 of 319 posts

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

#61

Post by ricardobeat »

kungato wrote: post #46
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…

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

> return the full html every time

The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting.

Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content: HTML is nothing more than the template and content already baked in. In practice the JS templates are much larger due to containing the entire application logic + compiler overhead.

Finally, the benefit of having the templates already loaded is only realized over longer timespans, when probably half of your users are coming in with an empty cache anyway.

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

#62

Post by vezycash »

piranha wrote: post #36
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?

It's hard but take a few minutes off before responding to snarky comments.

Please answer their indirect question: "Did you replicate every of the react app's functionality in the app?"

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

#63

Post by avasthe »

Etheryte wrote: post #21
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…

Tangentially related; is there no lint option (similar to use strict) in JS yet to ensure no methods / functions are dynamically called and thus allow effective dead code elimination?

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

#64

Post by lr4444lr »

kungato wrote: post #46
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…

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

Because the user can't be trusted - on several levels.

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

#65

Post by piranha »

ricardobeat wrote: post #61
kungato wrote: post #46

Earlier quoted context omitted.

Why does is handling state on the backend better than handling it on the frontend? You will always have the cost of waiting for the server to return the full html every time you want something to happend and still you will have cases where you are handling state on the frontend

> return the full html every time The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting. Note that with an SPA you need to send templates (in the js bundle) + data (json api) to the client, which by definition will be at least as large as static HTML for the same content : HTML is nothing more than the template and content already baked in. In practice the J…

> The post mentions their HTML size decreased - most likely due to reduction in intermediate components and nesting.

Mostly because of initial data. Index page is still on react, so you can go on https://kasta.ua/ and look for element `#initial`.

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

#66

Post by rawoke083600 »

Just use Svelte. It's a super simple API, the "trickiest" part is the "reactive sections" but the whole API and reactivity part you can grok in an afternoon.

In the past I have used Angular and React - these days I just always reach for Svelte (speed and simplicity).

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

#67

Post by renke1 »

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…

React Portals could also help here, allowing you to still use context and the like.

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

#68

Post by richthegeek »

brainless wrote: post #23
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.

The first legit reason I can think of is if you have a particularly complex UI with fixed/absolute/sticky positioning and you need tooltips. In this case, CSS gets in the way and you need to render the tooltip through a tooltip and so need to set the position using JS on hover.

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

#69

Post by [deleted] »

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…

[deleted]

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

#70

Post by murkt »

adventured wrote: post #41
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…

6-12 months from now another article will be warranted, the author will have changed their mind again. That's the pattern you see throughout the entire thing, non-stop jumping. It's a solid bet as an indicator of the lack of maturity as a developer, incessant tech hopping.

You mean in nine years its Backbone, then React, then server-side rendering? Yeah, that’s tech hopping every 6 months in its finest.
Post reply on HN