The overall performance of a web-based software is arguably pretty far from something to write home about (especially given the exceptional engineering[1] underpinning systems running JavaScript itself), and kind of leaves most of the technically inclined people wondering how the so-called modern frameworks managed to end up being a reference architecture. It almost feels like we've finally got ourselves a kind of software that's getting larger faster than it's getting... faster.
Computer systems have gotten literally orders of magnitude quicker since the inception of what would later came to be a web platform, and that's definetely brought an enormous value for so many users (most of the mundane tasks get easily solved by just opening the browser), and it wouldn't be so if every single developer have still had to look at the cache lines and memory pages.
It's hard to argue that the progress in hardware has basically got rid of any incentives for optimizing on the level of cycle-aware assembly language routines for the majority of the real-word tasks, but you still don't necessarily have the right to architecture your software with a dozen levels of abstractions, most of which you don't even understand completely, so that you can make your life easier by being sure that you'll just go and get any number of developers straight out of a bootcamp and they will be able to pull it off just because there's not so much hard work to do.
Most of the technical leaders basically deceives, intentionally or not, their employers into thinking that it just can't be done better "because JS is slow" so the employers can happily find comfort in that they don't have to even try it out and in the fact that their contenders won't bother either.
Usually they will tell you about some business-orientation or even that they actually make concious tradeoffs: like, our business-goal demands us to deliver our software faster and not so much to get our software to run faster, but it sort of rises a question whether you are capable of formulating your goals correctly if you're not aware of the actual technical limitations, because it's far from obvious how could you evaluate your need to get something run faster if you're already sure that you just can't.
The very set of goals is in fact very dependent on what you think is possible on a given distribution platform. Imagine having a glimpse of a potentially really good idea of how you could improve your product by doing this and that, but you don't even consider it because you're already rather falsely convinced that it just can't be done fast enough to be viable. And what if you're wrong?
[1] Lars Bak is probably literally the best man for the job.