3 ms·

But very little code has to be fast, right? Best to prioritize making code "easier to think about" and thus more likely correct, then to profile and optimize t

But very little code has to be fast, right? Best to prioritize making code "easier to think about" and thus more likely correct, then to profile and optimize the bottlenecks.

nine_k 6y ago
All the code in the UI should better be fast, else the UI drowns in annoying molasses real quick. So no, performance does matter a lot here.
- rectang 6y ago
  I don't dispute that UI code needs to be fast overall, but it's still the case that only a small proportion of the code needs to be fast in order for the whole thing to be fast. FWIW I worked in the search/database space for a decade and it's the same thing there. There was one time I wrote a lock-free hash table implementation for a registry that needed to be optimized for concurrent access; that code was much harder to write and to understand than the rest of the codebase, but it was justified. Most of the codebase, though, was not performance-critical. EDIT: I will grant that you still need to think about how to architect the project so that it is optimizable later, which can mean thinking about what needs to be async early on.
onion2k 6y ago
Not really. Front end devs should be aiming for a solid 60fps, so you only have about 16ms to do everything you need to do in a frame (less actually because the browser itself needs time as well). If you have interactions, network requests, animation, and calculations all blocking the main thread it'll be a horrible experience for the user. Giving up async and not letting the browser do what it can as soon as possible is just silly.
- rectang 6y ago
  I feel like there's a disconnect here. I did not suggest "giving up async"; I expect that async will be used when justified — as I described having done myself in a nearby comment. I'm just making a bog-standard argument against premature optimization, and I'm shocked that we can't find common ground.

But very little code has to be fast, right? Best to prioritize making code "easier to think about" and thus more likely correct, then to profile and optimize the bottlenecks.

nine_k 6y ago

All the code in the UI should better be fast, else the UI drowns in annoying molasses real quick. So no, performance does matter a lot here.

rectang 6y ago
I don't dispute that UI code needs to be fast overall, but it's still the case that only a small proportion of the code needs to be fast in order for the whole thing to be fast. FWIW I worked in the search/database space for a decade and it's the same thing there. There was one time I wrote a lock-free hash table implementation for a registry that needed to be optimized for concurrent access; that code was much harder to write and to understand than the rest of the codebase, but it was justified. Most of the codebase, though, was not performance-critical. EDIT: I will grant that you still need to think about how to architect the project so that it is optimizable later, which can mean thinking about what needs to be async early on.

onion2k 6y ago

Not really. Front end devs should be aiming for a solid 60fps, so you only have about 16ms to do everything you need to do in a frame (less actually because the browser itself needs time as well). If you have interactions, network requests, animation, and calculations all blocking the main thread it'll be a horrible experience for the user. Giving up async and not letting the browser do what it can as soon as possible is just silly.

rectang 6y ago
I feel like there's a disconnect here. I did not suggest "giving up async"; I expect that async will be used when justified — as I described having done myself in a nearby comment. I'm just making a bog-standard argument against premature optimization, and I'm shocked that we can't find common ground.