11 ms·

Performance of frameworks is often irrelevant for products/applications. 1. Performance is very very rarely a contributor to a product success. Users prefer mo

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 many you have, and how long they take. It's almost always a waste of effort to try and make your framework render at half the time when 99% of your lag is a database call. 3. 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. (I would hazard a guess that in your panel switch example a differently structured React+MobX solution would not have the problem you described) 4. There are only very few scenarios where the rendering speed between frameworks makes a perceptible difference (usually when talking about large tables or similar scenarios), in all other cases it's a difference of a few milliseconds.

sakex 4y ago
You'll need some data to make those claims.
- deleted 4y ago
  [deleted]
thegeomaster 4y ago
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.
vouwfietsman 4y ago
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.
- dagorenouf 4y ago
  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.
  - vinay427 4y ago
    The data seems to indicate otherwise: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales 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
    - undefinedzero 4y ago
      With SSG and to a lesser extend SSR, React has close to zero impact on the initial page load. It’s all just HTML.
    - taeric 4y ago
      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.
    - jokethrowaway 4y ago
      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)
humanrebar 4y ago
> 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.
chiefalchemist 4y ago
> 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?
- SgtBastard 4y ago
  > 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.
  - _heimdall 4y ago
    > 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.
    - SgtBastard 4y ago
      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.
- Illniyar 4y ago
  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.
dham 4y ago
> 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.
- kunley 4y ago
  Absolutely agree. Thank you btw for bringing up some of the recent history. People forget so easily
- DoesntMatter22 4y ago
  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
  - pcthrowaway 4y ago
    How is "server rendered" different form "rerendering on the backend"?
    - DoesntMatter22 4y ago
      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.
agloe_dreams 4y ago
> 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.
colin_jack 4y ago
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/#shrinkage https://infrequently.org/2023/02/the-market-for-lemons/#shri...

sakex 4y ago

You'll need some data to make those claims.

deleted 4y ago
[deleted]

thegeomaster 4y ago

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.

vouwfietsman 4y ago

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.

dagorenouf 4y ago
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.
- vinay427 4y ago
  The data seems to indicate otherwise: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales 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
  - undefinedzero 4y ago
    With SSG and to a lesser extend SSR, React has close to zero impact on the initial page load. It’s all just HTML.
  - taeric 4y ago
    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.
  - jokethrowaway 4y ago
    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)

humanrebar 4y ago

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

chiefalchemist 4y ago

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

SgtBastard 4y ago
> 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.
- _heimdall 4y ago
  > 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.
  - SgtBastard 4y ago
    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.
Illniyar 4y ago
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.

dham 4y ago

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

kunley 4y ago
Absolutely agree. Thank you btw for bringing up some of the recent history. People forget so easily
DoesntMatter22 4y ago
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
- pcthrowaway 4y ago
  How is "server rendered" different form "rerendering on the backend"?
  - DoesntMatter22 4y ago
    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.

agloe_dreams 4y ago

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

colin_jack 4y ago

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/#shrinkage https://infrequently.org/2023/02/the-market-for-lemons/#shri...