4 ms·

"Performance" matters a lot less than many other things like collaborating with other people, or getting the DOM manipulation right.

simmerup 4y ago
I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.
- pas 4y ago
  My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.
  - thegeomaster 4y ago
    Structuring the UX in a user friendly way matters more, that doesn't mean random 200ms lags are OK. As you said, performance is UX too. I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why. You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies. Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.
    - pas 4y ago
      Random 200ms lag is different than showing a new panel full of elements. I'm aware of those complaints. 95% is when people are using a thermal throttled old device, while the app in question is trying to smoothly animate a complete clusterfuck of a webpage (for bonus points it's usually in some god-awful WebView in an app). It's not simply displaying new checkboxes, inputs, labels, buttons, it's multi-megabyte images with fancy CSS effects and so on. > They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. Of course, no questions there! But it's not because the "framework is not performant enough", it would be slow even in vanilla JS in 95+ % of situations. > And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Yes. And it's because you say to the client/designer/productperson that hey, if you want snappiness even for the 99th percentile of your users (ranked by hardware), then let's test on that device, and let's forego that nice animation that you saw in that native app on your friend's iPhone 15 ÜberMaxPro. And, not surprisingly, many of the aforementioned culprits will say "I want that shiny thing" > but our industry behaves like a bunch of babies. I don't think you're harsh at all! And I agree. Many IT workplaces went all-in with the infantilism. (Daycare for autist-savants! Colorful open-office with a playroom, maybe even a ball pit! You can't concentrate today? Don't worry, just play some table tennis, and try it again tomorrow! -- Contrast this with the endless office gray cubicle farms of the engineering departments ~50 years ago. Which is probably the other extreme of the spectrum. And I believe there's a healthy middle ground. Well maybe slacking off on HN is not exactly part of it.) > Yet the teams there collaborate just fine. The games industry is famously not in a "fine" place, I'd say :) But yes, of course, they have a clear target, and even if the process requires some blood sacrifice for the crunch times, it works, sometimes. Sometimes we get buggy things like Cyberpunk 2077, which was less-than-optimized for some target platforms.
  - bayesian_horse 4y ago
    React isn't defenseless in the performance department. If a naive implementation takes 200ms to update many elements, there's usually an approachable way to speed it up!
- actualwitch 4y ago
  I will take an app that's a bit slow but renders consistently over an app that works faster but sometimes forgets to update parts of UI, every time.
  - josephg 4y ago
    Why would performance and correctness be in opposition to each other? Is chrome more buggy because its fast?
- bayesian_horse 4y ago
  The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it in most apps in most places even if you don't actually optimize things. Then indeed, abstractions a team can agree on matter more. Getting state management right matters. Hiring people and getting them productive quickly matters. Those are strong points in favor of React and even Angular, to an increasing degree for Vue, Svelte and others.
  - azangru 4y ago
    > The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it How can you know this? The only scientific way to approach this question is with real-user metrics and analytics.
    - bayesian_horse 4y ago
      Experience from using React for many years tells me. Rarely have I needed to optimize anything related to react to make something visibly snappier, and most of the time it's not really React's fault. And there are some benchmarks that show SolidJS and some other things are faster than React at specifically what React is doing (like dom manipulation/reconciliation etc). And yes, I'm talking broad strokes!
- grumple 4y ago
  If a page is taking too long to render or interact for regular web usage, it's almost certainly not because of React. Clearly there are extremely performant applications using it at the highest levels of scale and complexity (Facebook, Twitter, many others).
- 0xblinq 4y ago
  Well, for the dev (for many of them) that’s how it is. As long as my tools are shiny, f*k the users.

simmerup 4y ago

I read this sentiment as basically saying the users experience of the app matters less than the experience of the dev who works on it.

pas 4y ago
My reading is the opposite. Basically all real end-to-end UX (actual performance included) depends on a collaborative effort. Someone mentioned that React is slow, it might take 200ms to update many elements.... and? Unless someone is making a fast-paced interactive game of DOM elements, it doesn't matter. Structuring the UX in a user friendly way matters infinitely more.
- thegeomaster 4y ago
  Structuring the UX in a user friendly way matters more, that doesn't mean random 200ms lags are OK. As you said, performance is UX too. I hear normal, non-tech people with average hardware complain about "lagginess" of their machines all the time. And usually the only application they use is Chrome. They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Not particularly because of performance, but they will enjoy using it more, and they won't be able to explain exactly why. You'd think that with the ridiculous amounts of money software engineers are paid to do what they do, they'd be able to swallow slightly more difficult collaboration and developer experience in order to deliver a more quality product. Forgive me for being harsh, and I don't mean this as directed to you (I don't know you), but our industry behaves like a bunch of babies. Aside: if you're making an interactive game, you have 16ms to respond and render, not hundreds. In 16ms, modern games dispatch draw calls for millions of triangles, do AI, physics, netcode, level streaming and other bookeeping. Yet the teams there collaborate just fine.
  - pas 4y ago
    Random 200ms lag is different than showing a new panel full of elements. I'm aware of those complaints. 95% is when people are using a thermal throttled old device, while the app in question is trying to smoothly animate a complete clusterfuck of a webpage (for bonus points it's usually in some god-awful WebView in an app). It's not simply displaying new checkboxes, inputs, labels, buttons, it's multi-megabyte images with fancy CSS effects and so on. > They won't say that they had a 200ms lag when they clicked on a button, but the overall experience degrades when things are slow to respond. Of course, no questions there! But it's not because the "framework is not performant enough", it would be slow even in vanilla JS in 95+ % of situations. > And when you sit that person in front of a good, optimized, snappy application, they will sing praise. Yes. And it's because you say to the client/designer/productperson that hey, if you want snappiness even for the 99th percentile of your users (ranked by hardware), then let's test on that device, and let's forego that nice animation that you saw in that native app on your friend's iPhone 15 ÜberMaxPro. And, not surprisingly, many of the aforementioned culprits will say "I want that shiny thing" > but our industry behaves like a bunch of babies. I don't think you're harsh at all! And I agree. Many IT workplaces went all-in with the infantilism. (Daycare for autist-savants! Colorful open-office with a playroom, maybe even a ball pit! You can't concentrate today? Don't worry, just play some table tennis, and try it again tomorrow! -- Contrast this with the endless office gray cubicle farms of the engineering departments ~50 years ago. Which is probably the other extreme of the spectrum. And I believe there's a healthy middle ground. Well maybe slacking off on HN is not exactly part of it.) > Yet the teams there collaborate just fine. The games industry is famously not in a "fine" place, I'd say :) But yes, of course, they have a clear target, and even if the process requires some blood sacrifice for the crunch times, it works, sometimes. Sometimes we get buggy things like Cyberpunk 2077, which was less-than-optimized for some target platforms.
- bayesian_horse 4y ago
  React isn't defenseless in the performance department. If a naive implementation takes 200ms to update many elements, there's usually an approachable way to speed it up!
actualwitch 4y ago
I will take an app that's a bit slow but renders consistently over an app that works faster but sometimes forgets to update parts of UI, every time.
- josephg 4y ago
  Why would performance and correctness be in opposition to each other? Is chrome more buggy because its fast?
bayesian_horse 4y ago
The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it in most apps in most places even if you don't actually optimize things. Then indeed, abstractions a team can agree on matter more. Getting state management right matters. Hiring people and getting them productive quickly matters. Those are strong points in favor of React and even Angular, to an increasing degree for Vue, Svelte and others.
- azangru 4y ago
  > The performance "disadvantage" of react (compared to what? SolidJS? handcrafted JS? some WASM thing?) is so small a user won't notice it How can you know this? The only scientific way to approach this question is with real-user metrics and analytics.
  - bayesian_horse 4y ago
    Experience from using React for many years tells me. Rarely have I needed to optimize anything related to react to make something visibly snappier, and most of the time it's not really React's fault. And there are some benchmarks that show SolidJS and some other things are faster than React at specifically what React is doing (like dom manipulation/reconciliation etc). And yes, I'm talking broad strokes!
grumple 4y ago
If a page is taking too long to render or interact for regular web usage, it's almost certainly not because of React. Clearly there are extremely performant applications using it at the highest levels of scale and complexity (Facebook, Twitter, many others).
0xblinq 4y ago
Well, for the dev (for many of them) that’s how it is. As long as my tools are shiny, f*k the users.