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

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

711–720 of 756 posts

Re: If not React, then what?

#711

Post by BeefWellington »

quantadev wrote: post #198
BeefWellington wrote: post #137

Earlier quoted context omitted.

The overwhelming majority of default HTML actions (no JS) that happen from a mouse click do not trigger a page load. You're trying to make it sound like selecting an item from a dropdown or selecting a textbox to enter text will cause a complete page load every time unless you use an SPA framework and that's just literally completely untrue. By your measure though, it sounds as though you'd be fine if these page load…

Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.

I think you're failing to understand that there are hundreds to thousands of functional applications out there that are not SPAs that are doing all of those things just fine. An SPA is not a requirement to be able to update values in a form, transition between page states, etc. The two options are not only Static Site or SPA -- that is the absurdity.

Making an entire application a single page load and then some API calls sounds attractive when your application is small to medium sized in terms of complexity. It runs into problems when complexity or feature count pass a certain point.

Re: If not React, then what?

#712

Post by cheema33 »

bryzaguy wrote: post #475
johnfn wrote: post #311

Earlier quoted context omitted.

> I disagree. Try loading up a library heavy site (i.e. React plus a half dozen associated helpers for state, UI and whatever, which is pretty common) on an old or cheap Android device. It can take multiple seconds before the page is fully loaded. Even once the libraries are loaded, React sites often involve parsing a giant lump of JSON before you can do anything, that’s particularly CPU intensive and takes time on l…

I worked at New Relic and focused specifically on improving page load performance for one of the products using our RUM data. Even after combining/parallelizing API calls then embedding the data into the page, I found there was still an average 3-6 second average page load cost using React vs an already rendered HTML page which was nearly instant. Not huge but frustrating to discover the constraint when it was my tas…

If your page is taking 3-6 seconds to load, you are either doing something wrong, or not understanding where the problem is and blaming React incorrectly.

My React app is statically exported and cached by the browser. There is only a single graphql call that fetches all necessary data. Backend is my only bottleneck. Everything else happens in less than 10ms.

And yes it is entirely possible to shoot yourself in the foot with any language and any framework. Including React.

Re: If not React, then what?

#713

Post by lmm »

Izkata wrote: post #702
lmm wrote: post #626

Earlier quoted context omitted.

> I'm "calling into" react (3) times here, while react is calling "into me" (1) time. It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point. > Are we saying any external source code that accepts a function as a parameter is considered a framework? Code that accepts a function for narrowly scop…

> It's calling into you three or more times, invisibly, if I remember the details of what useEffect and useState actually do at runtime correctly. Which rather illustrates the point. If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that…

> If they were using useState() correctly and provided a button or link to call the update function, yeah, React would call into their code as many times as the user clicked the button. As it is though, it's just once (useEffect with that second argument is "only run the passed-in function once on mount").

As I understand it both the useState and useEffect create points where their code will be suspended and resumed as a coroutine, even if everything only gets run once? But yeah, the more important point is that in the general case React will run it multiple times in ways that are not really under the user's control (at least not without understanding the internal details of React quite deeply).

Re: If not React, then what?

#714

Post by cheema33 »

kccqzy wrote: post #408
rkagerer wrote: post #406

Earlier quoted context omitted.

I hate what "modern" web development has done to my UI experience. Eg. There's a delay between an Amazon.ca results page loading and it populating the search text box with the phrase you just searched for. As a result when I do two searches in rapid succession, it consistently interrupts my typing at exactly the right time to batter in incomprehensible text. AirCanada and WestJet are two other websites that became aw…

There's no React-ey style UI. Seriously. It's a UI framework not a collection of prebuilt UI components. You cannot tell if a site is using React or not without opening dev tools.

Vast majority of the comments on this story complaining about React are actually complaints about some bad UI library or a poorly designed and architected website that happens to use React.

Re: If not React, then what?

#715

Post by cheema33 »

wordofx wrote: post #454
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

In 2024. React is probably the worst choice you could make when creating a new web application.

For static web page, it would be tough to beat html/css. But if you are building a web application of some complexity, it would be tough to beat React.

You can totally shoot yourself in the foot with any language or framework. And you can most certainly do that with React as well. As we so often see.

Re: If not React, then what?

#716

Post by cheema33 »

simonw wrote: post #37

A fun thing about reading Alex is that you can tell he's had the same arguments over and over again for a decade now and he's frustrated with having to keep on making the same points and getting the exact same responses. Most of the people commenting on this piece won't have read this whole article (it's long, and internet attention spans are short). As a result, you'll find plenty of the comments here were exactly p…

For me, when he said this:

"In short, nobody should start a new project in the 2020s based on React. Full stop."

He lost me. My React web app of medium complexity is statically exported and gets cached by the user's browser. All the data it needs for the main page is fetched by a single graphql call. The UI code renders in less than 10ms even on old machines. Network and the backend are the primary bottlenecks for me.

Could I redesign and rearchitect it such that the frontend is very slow to render even on modern machines? Yes, quite easily. And I suspect, many people complaining about React's performance are doing just that.

Re: If not React, then what?

#717

Post by cheema33 »

ahuth wrote: post #367
firefoxd wrote: post #258

The fundamental problem with React and the like, is that it forced developers to unlearn the anchor tag. If you can change the url via js why use an actual hyperlink tag? Over the years, I'm seeing more and more unlearning of fundamental web from new frontend devs forged in boot camps.

You're right that there's certainly bad HTML produced by React apps out there. But there's good HTML, too! As far as I can tell, React let's you write HTML in both the right and wrong ways, like all frameworks (including plain JS). Maybe it seems like React is worse in terms of HTML because of how popular it is? There are more users of it, so more potential examples of bad HTML?

> There are more users of it, so more potential examples of bad HTML?

I think you have hit the nail on the head.

Re: If not React, then what?

#718

Post by cheema33 »

sabbaticaldev wrote: post #606
jakubmazanec wrote: post #265

Great, another misinformed rant about React; meanwhile React developers get stuff done without inventing yet another template language. Also, website aren't slow because of React, they are slow because of shitty developers or insufficient budgets.

COBOL developers also get stuff done

Yes, but is COBOL increasing in popularity with devs year after year?

Re: If not React, then what?

#719

Post by crvst »

boredtofears wrote: post #623
crvst wrote: post #485

Earlier quoted context omitted.

That’s probably the main real-world use case for useEffect. Dedicated third-party libraries like React Query obviously use useEffect under the hood as well

Yeah that's what I thought -- all the React codebases that I've worked in are riddled with `useEffect` for this reason primarily.

I'm jealous, then. I've seen all kinds of deranged Rube Goldberg machines built using useEffect

Re: If not React, then what?

#720

Post by grey-area »

azangru wrote: post #639
grey-area wrote: post #549

Having seen some large react codebases I’d agree wholeheartedly with this article. React solves problems we don’t have any more (eg IE), badly, at the cost of poor performance, lock-in and a host of other problems that other solutions just don’t have. It means downloading MBs of javascript just to render a simple page. It encourages multiple loads of massive json payloads for bits of the page which are then translate…

> It means downloading MBs of javascript just to render a simple page. React + react-dom minified gzipped is around 60kB. Yes, this is a lot; but no, this is not MBs of javascript. If your (simple) pages download MBs of javascript, that means you have added lots of other stuff on top of react. While I completely agree that react is unnecessary for simple sites, react itself is not guilty of megabyte-size javascript b…

You’re writing your entire website in react then downloading it to the client every time. This means the weight is react plus hundreds or thousands of dependencies (which this is ecosystem seems to actively encourage) plus all your app logic. MBs is not uncommon for larger websites.
Post reply on HN