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 moved faster and released more features.

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 important caveat is that once it's fast enough the gains are marginal.

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.

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.

Is it vim in all 3 categories?

Just two of them.

Or just one.

If you think Vim has less features than VSCode you haven’t used vim enough.

> The important caveat is that once it's fast enough the gains are marginal.

Based off how slow every SaaS service is in the B2B space, performance isn't important in all scenarios.

Marginal performance (i.e. 100 ms to 10 s per action, not multiple minute delays) is somewhat important to end users and matters only if they can switch easily. End users typically have little to no say in choosing the business software, especially after it's already bought.

Performance is usually a lower order concern than an app doing what you want. You can bail on a slow app because you're impatient all day long, but if it's the only way to do the thing you want to do, I 100% guarantee you're going to suck it up and use the app.

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 most mature and popular.

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.

Not exactly true about "performance is more API based". Everything adds up. 400ms here, 700 there. Websites can be slow even before api calls are triggered or on the middle of them, or while the results from api responses are presented.

Rendering performance can definitely add up, but rarely do React websites render so many elements that you get to 700ms. Once you do, you can nearly always fix that with an performance optimizations iteration. I reckon that issue is just as likely in all frameworks, and less likely to be about React using 0.2ms (or something like that) longer per element to render before optimizations.

> Site performance is much more API based

Exactly. And those API calls are going out over the network. The caller has to serialize the request into text, the API implementation has to deserialize the text into values that can be passed to a local implementation function and then the API implementation has to take the result and serialize it into the return. Finally the caller has to process the result.

That's the simple case. Things get even more involved when you start using HTTPS to secure the data in transit on the channel and using OAuth to secure the access to the API. What appears to be a simple API call turns into a lot of back-and-forths with multiple servers - with all the network latency that entails. Then developers complain their website is slow. Gee, I wonder why!

The continued popularity of Slack and GitLab is an illustration that frontend performance alone is not the defining factor of success.

Not to mention Jira.

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!

Performance obviously matters, but only to the extent that everyone has a threshold for how much sluggishness they're willing to tolerate. For the majority of use cases, React is performant enough that devs don't have to go out of their way to optimize anything.