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

291–300 of 553 posts

Re: React is holding me hostage

#291

Post by jameshart »

holbrad wrote: post #255
Illniyar wrote: post #243

Earlier quoted context omitted.

And I never click on Ads. Yet they work and drive a lot of traffic and money to sites. (Even after all the fraud) Products almost never compete on performance, and the biggest, most popular ones are almost always the slower ones. Regardless of your anecdotal evidence, there is a reason why this sentiment is prevalent in the industry - because PMs and devs who thought otherwise were quickly outcompeted by those that m…

Performance is obviously important, to suggest otherwise is just silly. Both Google and Amazon have researched this topic and the results are readily available. First link I found: https://www.thinkwithgoogle.com/marketing-strategies/app-and... Why do you think there some much time and effort going into improving performance of computing in general. Facebook Lite, android go, GPU's, cpu improvements, 5g, etc. The imp…

Performance is obviously relevant in the margin. A performance improvement in your site might decrease dropoff or churn by something like 1-5%, which is a good number, and it will compound.

But if you are still at the stage in product development where adding features will increase your addressable market by tens or hundreds of percents (which doing things like ‘supporting multiple European languages’ or ‘adding google login’ can do) then those performance gains are not where engineering investment needs to go.

Re: React is holding me hostage

#292

Post by dham »

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…

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

Yet this is what all the JS people were saying in 2014 - 2015 when everything started to become SPA. They argued this is what the users want. That's been used to justify all this stuff for a very long time if you're on Twitter. When it gets traction within Twitter it leaks into orgs. It's the same argument that's used now for all the SSG,SSR,hydration,edge and whatever other buzzword.

The internet is miserable because of all these React sites. I know first hand because my wife has a Chromebook. Yet developers won't listen because they think 6x cpu slow down is good enough to test with on their $4000 Mac book pro.

If users really don't care that much about performance then why aren't we just rendering html and sending new html on every interaction. That's much easier to do, performs pretty well from a CPU/Memory standpoint.

We've taken on a lot of complexity over the years in defense of the users. The argument I go back to is what is "good enough" and the developers/product/design I've worked with don't know what this word means.

Re: React is holding me hostage

#293

Post by jameshart »

undefinedzero wrote: post #264
humanrebar wrote: post #223

Earlier quoted context omitted.

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

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible. Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the…

People are tempted to use react in the animation frame render loop, and these comparisons often seem to assume that that is the level of performance we need to be targeting - enough to hold 60 fps. But react’s not a good fit there. Other animation techniques are better for a vast number of reasons.

Re: React is holding me hostage

#295

Post by snarfy »

holbrad wrote: post #255
Illniyar wrote: post #243

Earlier quoted context omitted.

And I never click on Ads. Yet they work and drive a lot of traffic and money to sites. (Even after all the fraud) Products almost never compete on performance, and the biggest, most popular ones are almost always the slower ones. Regardless of your anecdotal evidence, there is a reason why this sentiment is prevalent in the industry - because PMs and devs who thought otherwise were quickly outcompeted by those that m…

Performance is obviously important, to suggest otherwise is just silly. Both Google and Amazon have researched this topic and the results are readily available. First link I found: https://www.thinkwithgoogle.com/marketing-strategies/app-and... Why do you think there some much time and effort going into improving performance of computing in general. Facebook Lite, android go, GPU's, cpu improvements, 5g, etc. The imp…

Arguing features vs performance is really about which features are more important. Performance is just another feature.

I use Vim and I use VSCode. There is little debate about which has better performance and which has more features. It's also easy to see which has more users.

Re: React is holding me hostage

#296

Post by jmull »

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…

JSX is yet another template language, is it not?

Re: React is holding me hostage

#297

Post by dham »

gurraman wrote: post #190
codeptualize wrote: post #183

Earlier quoted context omitted.

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

Super-snappy for who? You? with a $4000 Mac Book Pro? Even with 6x CPU slowdown in Chrome, that's not enough throttling for these modern computers to test with.

Re: React is holding me hostage

#298

Post by krautsourced »

akudha wrote: post #216
codeptualize wrote: post #183

Earlier quoted context omitted.

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

I have a beefy machine and fast internet. Yet, JIRA is annoyingly slow. Half the time, pages on my bank’s website take forever to load, or don’t load at all. I don’t have any numbers, just some anecdotal experience like the above. It is not just speed. The UI of many sites suck too. Amazon, GoDaddy, for example. Then there are ads. We don’t see ads in between content anymore. It is content within ads these days. I am…

In the case of Jira, how much of that is related to frontend code, compared to backend code / inefficient queries?

I find performance suffers mostly when media assets, advertisments, marketing and tracking scripts etc. come into play. The frontend rendering rarely makes a dent at that point.

Re: React is holding me hostage

#299

Post by _heimdall »

SgtBastard wrote: post #248
chiefalchemist wrote: post #242

Earlier quoted context omitted.

> Performance is very very rarely a contributor to a product success You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset? Why Lord? Why?

> You might as well say, having users is very very rarely a contributor to success. These two things are not even remotely the same thing. Having users is a path to monetisation but having a high performant app no one uses is not. In fact, if you have users despite performance, it suggests you have a home run product that can be optimised for performance. Again, you can’t optimise your way to user growth.

> Having users is a path to monetisation but having a high performant app no one uses is not.

These two things are also not the same. You start with "having users" and assume they're willing to pay and will stick around. You compare that to "having a high performance app no one uses" - explicitly limiting the scenario with an unrelated caveat that no one uses it.

A better comparison would look only at having users vs. a high performance app, which has too little information, or having users that aren't willing to pay vs. a high performance app that no one uses, which leave you in the same boat.

Re: React is holding me hostage

#300

Post by PaulHoule »

pas wrote: post #182
PaulHoule wrote: post #58

Earlier quoted context omitted.

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

That is one of the many partial answers that works some of the time but not all of the time.

For relatively simple applications you can push all the state high up to the root of the tree or near the root of the tree and have it flow down with props.

There is a complexity hierarchy and around the time people woke up to AJAX (there were a few years when it was just a ‘evil Microsoft thing’) I was writing apps that were highly dynamic, the extreme example is an IDE with property sheets or something like Adobe Photoshop where an arbitrary number of components need to ‘react’ when a piece of data changes. It is bad enough when there is a status bar and four other parts of the UI determined by management that need to be updated when a piece of data changes (could become five or six tomorrow). it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes.

Prior to 2010 I was building apps like that and developing special purpose frameworks to do exactly as you say in GWT, Silverlight and such. There was no support for such things at the time, no async/await, management and other devs had no idea of the ‘race conditions’ that could happen when data could either come out of a cached copy or get fetched.

In those cases I spent a while struggling to understand the problem and developed systems for handling state in complex applications so when I look at React, Vue and most of those (with the possible exception of MobX) I want to ask “where’s the beef?” because these frameworks are not adequate to the problem and people don’t seem to understand they are no adequate to the problem (it comes from Facebook, how bad can it be?)

Most of the reason why people think "React is OK" is that they are writing apps (99% of them) that are so simple they don't need React. If you're writing apps that really need React, than React doesn't seem OK.

Post reply on HN