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

181–190 of 553 posts

Re: React is holding me hostage

#181

Post by bayesian_horse »

pas wrote: post #163
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.

My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.

React isn't defenseless in the performance department. If a naive implementation takes 200ms to update many elements, there's usually an approachable way to speed it up!

Re: React is holding me hostage

#182

Post by pas »

PaulHoule wrote: post #58
javcasas wrote: post #49

Earlier quoted context omitted.

If you are having trouble testing context, you are _definitely_ doing context wrong. To test the context itself: pass as children of the context components to render the context state. To test the components within the context: create a context with mock functions/values. React has no answer to state going sideways because React manages a tree of components, and you are not supposed to connect random branches of a tr…

For the goals of the application you can push a button in one branch of the tree and it has an impact on many other branches…

That still means you have 3 different types of entities.

One where the event originates (knobs), one where it will gets translated into actual UX effects (DOM updates, API fetches, whatever, lets call these servos and gauges), and one place where the business logic lives that transforms between the low-voltage input signal and the high-voltage output driver power.

Without that transducer you have incompatible things.

Yes, many times this is a trivial thing, and that's usually when it can be done internally to the component.

Re: React is holding me hostage

#183

Post by codeptualize »

thegeomaster wrote: post #141
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…

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?

Re: React is holding me hostage

#184

Post by citeguised »

pupppet wrote: post #50

Not to start an unholy flame war, but if you were to start a new project and didn’t need to worry about the ecosystem or workforce, what framework would you choose? Vue? Svelte? Something else?

WC with LitElement (Shadow DOM disabled) for a SPA (if no SSR is needed).

Re: React is holding me hostage

#185

Post by Sammi »

snowstormsun wrote: post #167

It's a bit frustrating how difficult it is to find out the old value of a dependency of a React useEffect hook: https://stackoverflow.com/questions/73399384/how-to-get-and-... Back with components, it was trivial to compare old and new values and change the state based on that.

I was super interested in hooks when they first came out. But after a short honeymoon period I noticed all the complex rules, exceptions, caveats, and footguns, and I wondered how the React team ever thought this was something you could put into the hands on new developers and expect them to not run into trouble.

It reminds me of teachers who have been teaching so long that they don't understand what it's like to be new to the subject any more. It's called The Curse of Knowledge cognitive bias: https://en.wikipedia.org/wiki/Curse_of_knowledge

Re: React is holding me hostage

#186

Post by Accacin »

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, and if there's an issue you can be fairly sure that someone else out there has had an issue too and there's a solution to be found.

I'm not in a hurry to replace React, but I don't need to. React is stable enough to rely on in my honest opinion.

Re: React is holding me hostage

#187

Post by marginalia_nu »

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?

Try getting a slightly shitty phone and visit a place with spotty wifi that drops some packets. It's very enlightening.

I'm averaging a 15-30 second TTI on the most js-heavy sites.

Re: React is holding me hostage

#188

Post by Ciantic »

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…

> When using React I usually just use MobX and everything just works.

MobX is signals library. In other words, you are already using the signals way of doing things if you mostly manage your state with MobX. I still use MobX as well if I think I can't use SolidJS.

SolidJs if you haven't looked has MobX-like tools built in, computed, autoruns and all the same tools, it triggers "renders" when one of the signals changes. In reality it doesn't have renders, because it's not based on VDOM, but it makes it look like it does.

However I like to keep my signal library separate, I would wish SolidJS had separate signals library I could use elsewhere as well.

Also SolidJS is big library and framework by now, it comes with risks if Ryan Carniato were ever to loose interest.

Edit, I also found that Ryan has created an example of MobX and JSX without React, it's a good way to demonstrate that React is not as important with signals libraries: https://github.com/ryansolid/mobx-jsx since you know MobX that example probably makes sense.

Re: React is holding me hostage

#189

Post by Illniyar »

thegeomaster wrote: post #141
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…

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 many you have, and how long they take. It's almost always a waste of effort to try and make your framework render at half the time when 99% of your lag is a database call.

3. Framework performance is rarely a contributor to the speed of your rendering. It's most often a problem with how you structured your app. You can structure your app poorly in any framework. (I would hazard a guess that in your panel switch example a differently structured React+MobX solution would not have the problem you described)

4. There are only very few scenarios where the rendering speed between frameworks makes a perceptible difference (usually when talking about large tables or similar scenarios), in all other cases it's a difference of a few milliseconds.

Re: React is holding me hostage

#190

Post by gurraman »

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?

Same. We've been working on a huge React project for several years. Lots of graphs, 3d models etc ... and it is super-snappy. Only slow part is a WebGL-based chart component that visualizes 2-3 M rows of signal data. We can probably decimate the signal data to improve performance, but that has got nothing to do with us using React.

N.B. No one is using the app from their mobiles. iPad and computers only.

Our reasons for choosing React when there are so many alternatives: prior knowledge, ergonomics, easy onboarding, ecosystem.

Post reply on HN