Hacker News Reader

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

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.

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

Absolutely agree. Thank you btw for bringing up some of the recent history. People forget so easily

Rerendering on the backend can actually be faster than doing AJAX calls because the BE has to send a lot more data than if it's server rendered.

I

How is "server rendered" different form "rerendering on the backend"?

Rerendering should be Rendering, however they aren't different. They are the same.

Server rendering can carry less of a payload to the FE but you aren't sending unnecessary data.

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.

That’s highly dependent on the type of product / customers you have. If you’re running an online shop selling ice cream, going from 100ms to 2ms list sorting speed isn’t gonna get you more sales. I’d argue most online products are ice cream shops to some degree.

The data seems to indicate otherwise: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-...

> A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7%

> 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales

With SSG and to a lesser extend SSR, React has close to zero impact on the initial page load. It’s all just HTML.

Would be fun to see that revisited.

Also misleading to imply a linear relationship. There will be a marginal cost, but no reason to assume constant.

That study doesn't prove anything.

You're not amazon

That said, having a performant website is nice, both for developer experience and for users.

I have to say I pick solid because it's so damn fast (okok, and because it has an API which is React-like but without the crap doesn't make sense or an extra custom runtime just because)

Try to do an a/b test and see the results for yourself. Also remember that those 100ms can in some scenarios turn into 300ms if you are not running on state of the art hardware, like most developers does.

That’s just your gut feeling, not what actual data shows.

1. The obsession with measurable "product success" is part of the problem. Nobody will tell you they prefer your app because of performance, because it's not a perceptible thing your average user will notice. Features are much more important, true. You shouldn't care about performance at all for a prototype, true. But when you have an established product, not caring about the speed at all is a mistake IMO. This also has second-order effects for battery life, for example.

2. True, it depends on the type of app. For anything that is a type of "editor" - website builder, word processor-like thing, kanban board - you operate on a data model that you save in the background. Async calls are fairly unimportant for the overall feel there.

3. To me it's hard to untangle. The reigning paradigm is declarative UI, for great reason. It's so much saner than any manual updates. But this encourages a design where you don't think about what DOM updates will really happen after an action, and this is where the problem lies. A big part of it is also the DOM model and layout. In the extreme, you have a declarative UI library like ImGui which doesn't have any VDOM, it just rerenders every frame, and it's insane how quick it does it. I haven't been able to bring it to its knees, it just maintains 60FPS constantly, with a lot of frame time to spare.

4. It's not hard for me to believe this. I didn't say other frameworks are better. Could be that the whole DOM diff approach is the culprit, or the slowness of DOM updates and relayouts.

You'll need some data to make those claims.

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

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

Friend, your nitpicks here are of something I didn’t say.

I said explicitly “path to monetisation” not “assume they’ll pay and stick around”.

I hope you’ll agree that it’s easier to find a subset of users that will pay when your superset of all users is large vs a super(?)set of zero.

I might not as well say that. I in fact said something completely opposite - that users don't care about performance. Hence more features->more users.

That's just simply not true though...

Do users explicitly care about how many milliseconds somethings takes? No definitely not

Do they care if the application feels slow ? Yes absolutely

Do faster experiences subconsciously feel better ? Yes

Does that subconscious feeling, impact metrics like sales or conversion ? Yes it does

All the (dozens and hundreds) milliseconds add up and the sum of it is perceived easily

People pretty regularly say they buy iPhones because of the very smooth UI (performance), that they buy an ARM Mac because it's so much faster, etc. Google won partly because it was so fast.

So people do explicitly justify usage decisions with performance, all the time. Agreed that overall features win out but it's often the case that multiple products end up with broadly comparable sets of features and struggle to gain a persistent advantage there. Once you reach that point, perf can be a competitive advantage.

Not sure this is true. The following post has issues but I do find sense its argument that the result of what you are saying has been accelerated shrinkage of the mobile web as businesses increasingly use apps instead.

https://infrequently.org/2023/02/the-market-for-lemons/#shri...