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

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.