Live data from Hacker News

React is holding me hostage

emnudge.dev

341–350 of 553 posts

Re: React is holding me hostage

#341

Earlier quoted context omitted.

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…

> 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). I close sites all the time when they fail to work quickly. I have aborted orders on sites midway through when the interaction became sluggish enough that I wasn't confident in the value of the product anymore. Thi…

Indeed, and I regularly watch other people give up on websites when they perform poorly.

And this isn’t just about 100 ms here or there. The frequency with which clicking a button takes seconds to have any observable effect is quite high. Coupled with modern UI trends where interactive elements aren’t clearly distinguished, sometimes users can’t tell a laggy button from a not-a-button.

I suspect a massive UX study bias here. Are people looking at telemetry to try to see whether users who completed some flow are happy? Those users (a) completed the flow, so they didn’t give up and (b) are likely enriched in those users who would use your site no matter what. The marginal users of poorly-functioning websites aren’t in the data set!

Re: React is holding me hostage

#342

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…

why is useEffect hook in particular that bad?

I played with Vue and svelte and now a firm React user, mainly due to its ecosystem, for most products the slowness of React does not play a major role at all for me.

Re: React is holding me hostage

#343

Earlier quoted context omitted.

>> 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. The clue is in if everyone is missing the point but you, may be start with more introspection. :) I will give an example of a side project I am working on. The homepage has two sub components, one when the user is logged in, one when the user is logged out. Now, w…

GP's post reads like a definitive example of Dunning Kruger. These are large-scope issues that the article highlights likely won't be apparent in smaller efforts that could be referred to as a "side project".

That's not what I said my entire exposure to React is.

Re: React is holding me hostage

#344

I've been feeling the same sentiment as the author. Having worked on 3 sizable React projects now (all started before I arrived), I can only conclude that beyond a toy phase -- once you have many hands working on React and *particularly* once you start managing sizable state -- there is only pain. The most recent case resulted in spending quite a bit of time explaining to a peer why we were experiencing an unexpected…

React definitely continues to innovate. Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago. The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities. Frameworks like remix and next will be able to leverage and build on this to create even…

> (Vue, Svelte, Angular, Solid etc)

> it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.

So does Solid No?

Re: React is holding me hostage

#345

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,…

I would like if the industry had less React domination. React is a bit like the IE8 of frameworks. It might not be the best choice for individual cases, but you have to learn its quirks as a developper since all the industry uses it.

But if we don't replace it, I appreciate if React introduced fine-grained updates and changed their attitude towards performance. I think as an industry, we have been pushing the "optimization is the root of all evil" statement beyond it's limits and now all software is super slow (except maybe games and some nice things like Excalidraw).

As I'm writing this, I noticed that Excalidraw uses React, so I wonder what's their secret sauce. Maybe recoil?

Re: React is holding me hostage

#346

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…

My personal bugbear about pretty much all web frameworks discourse is universally stated things like:

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

Performance matters in a lot of contexts. If you’re doing complex stuff performance matters. If you’re a public facing site depending in search traffic performance matters.

I’ve ended up disliking React simply because it’s become this one size fits all solution that 90% of web development goes through without it ever being necessary. There’s nothing wrong with React itself but it’s often applied badly.

Re: React is holding me hostage

#347

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…

There's 2 things that I hate about react. 1) JSX - It's terrible. Svelte, Vue, Riot... they all got it right. JSX, mixing a weird syntax of HTML and JS together is just inferior to HTML with additional markup. 2) I don't know why but every react project has crazy levels of abstraction. Everything is 15 layers deep and making any sort of change requires way too much effort to navigate 15 files and code reading to make…

How is this example from vue docs:

preferable to the jsx version:

or even this loop example from the vue docs:

    
      {{ item.message }}
    
better than its jsx counterpart?

    items.map(item => (
      {item.message}
    ))

Re: React is holding me hostage

#348

Earlier quoted context omitted.

You keep saying useEffect has problems but you never mention what those problems are.

Sorry. The biggest problem is that useEffect's mental model is based on data change and not on events. So instead of "do something when this action/event happens" we get "do something when this data changes". Which ends up being abused a lot, as developers who aren't familiar with this mental model (which is most of them), tend to lump up every action into a data change. So instead of something like (contrived exampl…

I think your example was good, but I disagree with your conclusion. In your example, the hooks version renders the UI based on data/state. In the non-hooks version, the state of the rendered UI depends on ephemeral events and the order they were dispatched. The hooks version is more easily tested and it's easier to reason about as a developer. It conforms to the mental model of a function (props, state) => UI. The non-hooks version would look like (props, state, actionHistory) => UI, where actionHistory is a list of all actions the user has taken since the app was initialized. With that function, we can't reproduce UI, because we don't have actionHistory (since the events triggered by the actions has not been recorded).

And are you sure the data in useEffect is stale? I don't think it is, the documentation[0] seems to suggest that it uses the current closure.

The rest I agree with.

[0] https://reactjs.org/docs/hooks-effect.html#example-using-hoo...

Re: React is holding me hostage

#349

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…

> 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.

This is absolutely true!

I would say that some frameworks make it easier to make mistakes. For example, Angular can be highly performant...but the automatic change detection kills performance. But wait, you can fix that! Just make your components use OnPush Change detection! ...which is not...the default? Why? In any Corporate app that displays complex UIs you absolutely need to be using it everywhere. but yet.

Personally, I think it is to make it easier for beginners who don't understand why their observables are not showing content on the page but it is still annoying to set it in every component or hunt it down. This is a small part of why we turned to using nx and generators with configurations that add it by default.

Re: React is holding me hostage

#350

Earlier quoted context omitted.

I like the mental picture of the comparison. Consider, that you might have taught a boased selection of people, and that others might not be so diligent to have read the docs and actually thought about it in depth to also understand it ; )

The idea of pure functions deriving UI from state is the single central idea of React's worldview. The docs work extra hard to get this model of apps into your brain. This is not the same thing as people being elitist about Git, this is refusing to engage with the design of the framework and blaming the framework. I like how you say "others might not be so diligent to have read the docs"... As opposed to? Picking up…

> As opposed to? Picking up a UI framework and just winging your way through LSP autocompletions until something happens on your screen?

Yes, that, and following bad tutorials by other people who did the same.

Post reply on HN