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

React is holding me hostage

emnudge.dev

Post reply on HN
Print view View original

191–200 of 553 posts

Re: React is holding me hostage

#191

Post by azangru »

bayesian_horse wrote: post #180
simmerup wrote: post #151

Earlier quoted context omitted.

I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.

The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it in most apps in most places even if you don't actually optimize things. Then indeed, abstractions a team can agree on matter more. Getting state management right matters. Hiring people and getting them productive quickly matters. Those are strong points in favor of React and even An…

> The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it

How can you know this? The only scientific way to approach this question is with real-user metrics and analytics.

Re: React is holding me hostage

#192

Post by tomgp »

onion2k wrote: post #103

Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a few seconds. I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed…

> I'm not sure I'd ever expect a framework, React or anything else, to stop that behavior. If a child component signals to a parent that the state has changed then I would always expect that to cascade down the node tree. That could cause further updates. And more renders. That behavior is on me. If the framework decided not to cascade some updates that would be weird.

It's not that the properties shouldn't be updated it's that in React the whole subtree gets completely re-rendered, with a potentially big performance cost. Svelte just changes the relevant bit of the DOM, like a single class attribute or whatever, and leaves everything else be, this feature alone is what made me switch. In addition to baseline performance benefits certain things which are really awkward in React (e.g. animated transitions) become non-issues.

>Feeling like you have to stick with React is a state of mind - you can change that with enough effort.

I really appreciate your optimism about switching to a different framework/ etc. and I would have felt the same earlier in my career where I didn't have so many non work commitments, financial and otherwise. But to me now this reads as wishful thinking; switching track is difficult, especially when your existing skill set represents a large chunk of the demand in the marketplace. (And I say this having recently sucessfully made the switch from React to Svelte)

Re: React is holding me hostage

#193

Post by MrPatan »

jameshart wrote: post #48
treis wrote: post #27

I've been working on a React side project for a few months now and looking at my company's apps plus posts like this I think people just miss the point. Stuff like this: >Things get more complicated when you start using React Context and start signalling updates in a parent component. The render cascades. Maybe one component fetches some data, some component remounts, and you run your state update again, delayed by a…

The bit of react that is f ( newState ) => UI is the easy part. The bit that is g ( state , userInput ) => newState is the hard part. In particular managing the scope of that newState . Oh, and sometimes you need to handle h ( state , asynchronousData ) => newState too. And then comes the fact that even though your f is _pure_, it also has to be _fast_, because it's going to run every time you get a newState .

This is why people use redux, keep state in a store and just do v=f(state).

Your app is the store, not the DOM.

It really makes things much simpler. The trick is to keep all the state in the store, including when things are loading, when some user interaction is happening but not yet complete, etc.

From your comment, it seems like there may be some problem if the user is interacting somehow, let's say in the middle of doing a drag and drop, and some data update comes in from a websocket, right? Well, if that's going to cause a problem for your render it's because apparently your data-updated function h needs to know if the user is doing a drag and drop. That should get put in the state when the user starts the interaction, and now h can know about it and react correctly.

Yes, it's more complicated than just have some component render based on the data you receive, but that's because it turned out that your app was more complex than you thought, it has more states you need to care about.

There's no magic wand, but this stuff works, just adds some boilerplate code but I don't mind.

Re: React is holding me hostage

#194

Post by brnewd »

Illniyar wrote: post #132

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

TSX + MobX are the reason I'm happy to stay on the React train after a transition from AngularJs (1) to Vue 2 to React.

Re: React is holding me hostage

#195

Post by sakex »

Illniyar wrote: post #189
thegeomaster wrote: post #141

Earlier quoted context omitted.

How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard i…

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose). 2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how m…

You'll need some data to make those claims.

Re: React is holding me hostage

#196

Post by tomgp »

Accacin wrote: post #186

The whole thing around React is odd to me. People laugh at web development, especially the frontend, for changing libraries every week but you read a thread like this and everyone is so sure that React is a bad library and we should be using some newer library instead. I work with React daily and it has issues, but I find most issues can be worked around without much trouble. It's easy to hire people, onboard people,…

My position isn't that we should be using a new library per se. It's that we should be more selective about what 3rd party code we use and espescially what we ship to end users. React has tended towards a kitchen sink approach and this is exacerbated by initial design shortcomings/decisions i.e. no built in state management or method for encapsulating styles has lead to a deluge of libraries that promise to fill the gaps, none of which quite work with one another. This I guess is why we've seen the rise of meta-frameworks like Next which fill this gaps in a predictable way. But these just meta frameworks just shift developers another step further from the underlying HTML/CSS/JS making it harder to debug things and harder to fix issues when you stray from the framework's happy path.

(All that said, I don't blame people for choosing React for certain classes of projects, the economics of hiring new devs, the relative maturity and stability , the large community etc all make for powerful incentives to choose React)

Re: React is holding me hostage

#197

Post by iakov »

codeptualize wrote: post #183
thegeomaster wrote: post #141

Earlier quoted context omitted.

How is performance not important in this context? React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine. None of this is perceptible on our beefy dev boxes, which is why I think people disregard i…

> the modern webapp experience is so miserable for the average person. I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?

It feels like a myth to me as well. We, tech nerds, value "optimized" solutions, "beautiful" code. We buy top-notch hardware, remove bloatware, because we really care about our tools and craft.

90% of the users use shitty hardware. Everything is sorta sluggish on their computers - they boot up slowly, the bunch of crapware in autorun take their sweet time to load & phone home, their wifi us overburdened with devices. Most of the software experience is sluggish for them. They don't care if their web app is sluggish too.

Re: React is holding me hostage

#199

Post by activitypea »

pas wrote: post #174
activitypea wrote: post #148

``` The quickest obstacle you’ll run into as someone new to React will be something like this function MyComponent() { const [num, setNumber] = useState(42); // infinite loop setNumber(n => n + 1); return {num} } Trying to make state updates at the top level of a component will result in an infinite loop. ``` I've taught React to dozens of people without ever seeing someone try this. A render function is an idempoten…

This is because people forget that React is still a only "view" library with the M and C sprinkled all over with meathooks. ¯\_(ツ)_/¯

React doesn't map to the MVC paradigm at all, though.

Re: React is holding me hostage

#200

Post by red_admiral »

Illniyar wrote: post #132

I'm still a React guy. I've also worked with Angular and Vue and toyed with Svelte. People tend to compare these frameworks on things that don't matter - often it's performance. We used to compare React performance to AngularJs performance too, which was meaningless. VDom is nice. Reactivity in signals is nice. Limiting rerenders is nice. But I choose frameworks because of developer ergonomics. The killer feature for…

> People tend to compare these frameworks on things that don't matter - often it's performance.

Performance on the end-user device, especially if you're just under/over certain thresholds like 1sec to switch "tabs" or whatever you're using, does matter. Especially if you're trying to get people to buy stuff.

I wish all developers had to routinely try their products on a low-end 2-year-old smartphone. That would take the discussion of whether performance matters to a more informed level.

Post reply on HN