5 ms·

> 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

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

Illniyar 4y ago
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.
- holbrad 4y ago
  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-mobile/page-load-time-statistics/ 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.
  - jameshart 4y ago
    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.
  - snarfy 4y ago
    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.
    - larksimian 4y ago
      Is it vim in all 3 categories?
      - tarboreus 4y ago
        Just two of them.
        satvikpendem 4y ago
        Or just one.
    - 0xblinq 4y ago
      If you think Vim has less features than VSCode you haven’t used vim enough.
  - InsomniacL 4y ago
    > 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.
    - ansgri 4y ago
      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.
  - CuriouslyC 4y ago
    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.
undefinedzero 4y ago
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.
- jameshart 4y ago
  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.
- kunley 4y ago
  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.
  - undefinedzero 4y ago
    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.
- taylodl 4y ago
  > 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!
nine_k 4y ago
The continued popularity of Slack and GitLab is an illustration that frontend performance alone is not the defining factor of success.
- philwelch 4y ago
  Not to mention Jira.
  - deleted 4y ago
    [deleted]
amluto 4y ago
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!
taco_emoji 4y ago
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.

Illniyar 4y ago

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.

holbrad 4y ago
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-mobile/page-load-time-statistics/ 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.
- jameshart 4y ago
  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.
- snarfy 4y ago
  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.
  - larksimian 4y ago
    Is it vim in all 3 categories?
    - tarboreus 4y ago
      Just two of them.
      - satvikpendem 4y ago
        Or just one.
  - 0xblinq 4y ago
    If you think Vim has less features than VSCode you haven’t used vim enough.
- InsomniacL 4y ago
  > 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.
  - ansgri 4y ago
    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.
- CuriouslyC 4y ago
  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.

undefinedzero 4y ago

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.

jameshart 4y ago
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.
kunley 4y ago
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.
- undefinedzero 4y ago
  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.
taylodl 4y ago
> 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!

nine_k 4y ago

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

philwelch 4y ago
Not to mention Jira.
- deleted 4y ago
  [deleted]

amluto 4y ago

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!

taco_emoji 4y ago

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.