Live data from Hacker News

React is holding me hostage

emnudge.dev

221–230 of 553 posts

Re: React is holding me hostage

#221
post #192

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

> switching track is difficult [...] (And I say this having recently sucessfully made the switch from React to Svelte)

Having developed with Angular and React, and dabbling with Vue, I have to say that Svelte has the best ergonomics of the lot, and the language tutorial is so approachable. I haven't had to think about performance or state to the degree that I have in other frameworks. Any workplace could easily skill up a Svelte dev from a React dev.

Re: React is holding me hostage

#222

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…

Although I agree with the sentiment of your post, #1 is blatantly wrong.

Most of my successful work has been specifically outperforming the competition in a way that makes users choose our product. Performance is an orthogonal feature that improves all other features, and even changes what your clients can do with your system, as in making new workflows viable.

Re: React is holding me hostage

#223

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…

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

This statement reminds me of those Gordon Ramsay shows where a restaurant owner says "the customers like my food!" when it's obviously subpar. The fact is that the customers that didn't like the food politely go away and don't come back.

Your other points get more directly at framework performance versus other performance concerns. I have fewer opinions about those.

Re: React is holding me hostage

#224

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?

In my case it's extensive anecdotal experience. First when I was a budget constrained student with bad hardware. Of course now I use a really good midrange phone, good laptop and pc.

Then i noticed a stark differences in attitude in the 2 studies I did at uni. One was more plain compsci. The other more web/mobile design and development. The later paid absolutely 0 attention to optimisation. Whether it was speed, download size or anything of the sort. The former treated an inneficient slution as invalid or at least graded lower. (Note this was in Beligum)

First time I started paying more attention to this where it wasn't when it wasn't in the context of being a budget constraint student was when I did a temporary IT support stint at a gigantic international pharma company and the software was so sluggish it was....insane. Dozens of people at our facility staring at a slugish webinterface waiting at every action and doing loads of those for every ticket. It was so infuriating I tried to make a browser plugin to prefill stuff with comon defaults the moment they were available knowing I'd never use it beyond those 3 months. Years of time must've been wasted staring at little loading circles because management did not use the software.

Then when I made native software for a manufacturing industry niche where i was told some suggested db retrieval and prerendering optimisations and such weren't worth the time....And sure. These were lowwage foreign workers using it, it didn't hamper much at all and our time was expensive. Maybe the business wouldn't get the money out of it....but then i ventured to production and notice more than a hundred people pulling the same actions many times a day thousands of times a year ....and see them waiting split seconds or multiple seconds depending on the actions that counted up to combined wasted minutes, hours, days, weeks and I realised what a load of bollocks it was.

Additionally when I helped extend various ERP's I realised the old ones were faaar from great but the move to web based interfaces really didn't do us much favours.

Then I come home and try to help my various layman family members on their comparatively slower windows and android devices and it becomes veeery apparent that this is not just a professional software issue. Slugish UI libraries on slugish frameworks on a slugish OS with various other slugish apps.

Coming home to a fast pc running Linux and using stuff i write in my free time using C++ or rust or even just various native apps on windows feels like such a extremely stark contrast.

My conclusion is that users won't care enough up to a certain point as studies show However I do believe that what those studies don't show is that for a good part this is because it's the default for many of them. They think this is just what tech is and all those countless small waittimes behind actions is normal.

Re: React is holding me hostage

#225

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…

> Most frameworks outside react still use templates. Even when they support JSX like syntax (aka vue 2.0) the default are templates. Templates are a no go for me. I use them for blogs or static websites, but applications are easier to make and maintain with actual javascript. I've gravitated away from React towards Vue v3. Templates are working fine, well even. You still use similar amount of Javascript (probably les…

>Weird. useEffect is like the archetypal hook. The problem it purportedly solves was one of the main arguments they made for hooks existing in the first place -- https://reactjs.org/docs/hooks-intro.html#motivation. They just implemented it in a clunky way, and actually the problem could have been solved in an OO fashion without going to hooks at all, but now everything is a fucking hook.

There was (and still is) a real problem in react with composability. Which they tried to solve with mixins, then HOC and then hooks.

The three main hooks are useState, useContext and useEffect . useState and useContext are very straightforward and an overall improvement on their previous counterparts. useEffect was an improvement over mixins, but it was a worse solution for class component lifecycle methods.

It was fairly obvious that useEffect had a lot of problems from the get go, but it was deemed worthwhile to add so that functional programming proponents could have state without classes and to finally have a way to use composability without the horribleness of mixins and hocs (which were worse then useEffect).

The real problem is that useEffect has it's own problems, and while we no longer have the old problems, the new problems might be worse.

Re: React is holding me hostage

#226

Earlier quoted context omitted.

Your dislike for ‘templates’ is much more a matter of personal preference than you’re letting on. Using language like “still using templates” makes me think that you don’t see any valid opposing view. I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. But framing non-JSX approaches as objectively inferior is not in tune with the reality, being that this is something sensible peo…

> Templates are a no go for me It’s pretty hard to get more “this is my opinion rather than a statement of objective fact” than this. > I do not like JSX. It’s not worth talking about why. It’s not an argument I want to have. Ok. Um… well, it’s hard to have a discussion if you won’t talk about it… …but, “code” templates allow autocomplete and type checking in a way that is an objectively distinctive superset of text…

JavaScript is a better, but JSX is not JavaScript. It reuses many features from JavaScript, but you still need some sort of translation (compilation) step to make it useful. In this sense it is not really fundamentally different from any of those what you call template languages.

You can argue the fact JSX better integrates syntaxes from a proper programming language makes it better than other templating languages (and I’m not going to try persuading you otherwise), but the “JSX is better than template language because it is not one” stance you’re implying won’t help you win any arguments.

Re: React is holding me hostage

#227

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…

> issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine.

We have a React+Redux search page where clicking checkboxes takes about that long to update the checkbox, on our good developer machines.

I won't rule out we did something wrong (this page was pretty early in our React understanding), but we've also not managed to fix it due to how much is on that page.

Re: React is holding me hostage

#228

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…

Its is actually sad just looking from a hardware endpoint. A 2016 iPhone 7 has an advanced 5 nanometer CPU. That is really powerful when looking at the grand scheme of things. Yet most react "websites" will completely obliterate it and make the phone get blazingly hot. I do this for fun a lot when browsing the web: when a website makes my phone literally melt, I check its stack on my PC and sure enough it is almost always React paired up with Redux. These performance apologetics are sad.

Re: React is holding me hostage

#229

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…

I would say that useEffect is my favorite hook. It's neat. My least favorite hook would be useReducer. I've never used that one.

Re: React is holding me hostage

#230
post #67
post #40

Earlier quoted context omitted.

> useEffect is a side effect and if you use it you're gonna have a bad time. Right.. but then you can't really use React for building serious UI.

You can build serious UI’s without useEffect. But it’s a powerful escape hatch like rust’s `unsafe` block. Rust can do amazing things to ensure safety of your program, but there’s still times where a human can do it better. By signposting that, keeping it to limited blocks, and wrapping it up in a safe function you get the capability to do hard things, while exposing a safer API. useEffect is similar, it lets you wri…

It's still using the useEffect hook, but just wrapped in a useFetch or something. So technically you're not building a UI without useEffect, just hiding it, no?
Post reply on HN