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

81–90 of 319 posts

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

#81

Post by smichel17 »

ricardobeat wrote: post #58
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…

> Seems to be blaming something on a library that the library has no care about in the first place Libraries and frameworks establish idioms, which encourage or discourage certain patterns. In my experience React / JSX definitely encourage complexity and abstraction by making display and logic so intertwined, especially with hooks. > And holy guacamoly, how do you end up with this? Libraries upon libraries, one tiny…

I can second this. I'm working on two projects, one paid and one volunteer. One is using vanilla css/html (requirement to work without js) and the other is using react. Doesn't matter which is which.

To set the context for the following statement, I've discovered that I prefer developing the nojs site. This mainly comes down to all the things that the browser does for me, but I have to handle manually in React, but it also includes something fun about figuring out the right css selectors to accomplish pseudo-interactivity without js. The point here is that I'm not personally inclined to avoid css.

And yet, when I work in react, I find myself writing less css, and the css I do write is closer to utility classes, something I never used in the nojs project.

I'm writing this on mobile but it's getting too long, posting and will move to desktop and edit in the reasons why I think React pushes me in the direction.

e: got here just as the edit window is closing, will reply to self instead.

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

#82

Post by tjpnz »

davidtranjs wrote: post #18

All of your issues like dropdown and hover in JS can be solved by CSS, why did you choose to implement them in JS? About complex logic, it is everywhere. I once worked at an big ecommerce company and the server-side catalog page was more then 2000 lines, nobody want to touch that page. But it would be easier with React since we can break it down to smaller components. Your 2.5MB minified bundle is actually too big.

>All of your issues like dropdown and hover in JS can be solved by CSS, why did you choose to implement them in JS?

Because it's modern? In all seriousness I've often asked questions along these lines and haven't always received great answers.

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

#83

Post by 1f60c »

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…

> dead-tree elimination

The practice of removing unneeded code from a bundle using static analysis is commonly known as “tree-shaking”, but I like your version better. :D

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

#84

Post by piranha »

capableweb wrote: post #72
piranha wrote: post #29

Earlier quoted context omitted.

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

You know, executables are not the only type of binaries, embedding a PNG file into the JS asset would also be considered embedding a binary asset. But I'm sure you knew this, you're just trying to be funny.

:-) yeah, in the heat of the moment. There is of course things we could do to improve bundle size, but it's all components and logic. We didn't do any css-in-js or any other fancy stuff.

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

#85

Post by [deleted] »

madeofpalk wrote: post #77
ricardobeat wrote: post #58

Earlier quoted context omitted.

> Seems to be blaming something on a library that the library has no care about in the first place Libraries and frameworks establish idioms, which encourage or discourage certain patterns. In my experience React / JSX definitely encourage complexity and abstraction by making display and logic so intertwined, especially with hooks. > And holy guacamoly, how do you end up with this? Libraries upon libraries, one tiny…

I cannot see how react encourages you to forget :hover in CSS.

[deleted]

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

#86

Post by piranha »

vezycash wrote: post #62
piranha wrote: post #36

Earlier quoted context omitted.

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

This is why it took four months, we had to change all React-isms to something that works in both modes. One particular thing could load less HTML, and it'll require some attention to make it so - but as we're deprecating React version of catalogue, it'll be easier to do.

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

#87

Post by piranha »

mercer wrote: post #59

As others have commented, this doesn't seem like it's React's fault. But it does illustrate how React isn't a magical solution to the front-end woes and how complicated the whole thing still is to do right. I'd still use React for projects, but for now I've been incredibly happy with the LiveView solution that Phoenix/Elixir offers (or the variants for other frameworks. Blazor for C#, LightWire for Laravel/PHP?). It'…

LiveView is also very interesting. The main reason we went other way is that amount of connections and state held on server will be really high, plus we have some clients with bad connections and regular HTTP works much better on those than websockets.

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

#88

Post by wwright »

hliyan wrote: post #48
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

Theoretically, you have a point. Practically, you are reading this comment on a website that not only does exactly this, but refreshes the entire page (rather than a small block of HTML, intercooler-style). The performance benefits are evident.

This site also has almost no state at all per-user.

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

#89

Post by catbuttes »

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…

We do exactly this within SharePoint. We have various react parts that look things up in the database - sometimes quite heavy queries for reporting.

We have put together a small collection of fairly generic react apps that mean we can put one on a page, put in some config and have it displaying a report generated in SQL in about as long as it takes to write the SQL for the report. We have used this approach for generic SQL reports, SharePoint lists, imgage retrival and entry forms. Having the library of options to hand has meant we can confidently assemble a new (fairly complex) page much quicker than previously - and be confident that it will work as it is reusing known good components.

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

#90

Post by lgl »

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…

> A complex page can have up to 60,000 DOM nodes under React's control with thousands of event listeners. It starts in about 3s and never drops below 60fps

Can one really make such affirmations regarding client rendered web apps? I'm assuming these numbers aren't solely measured on localhost in some state of the art development machine/device so won't it depend on the client's machine specs, browser, usage, bandwidth, etc?

Post reply on HN