Without wishing to create a paradox, it absolutely does, yes. I've been a web dev since 1997 and I frequently have to remind myself that I don't always need to optimize things, memoize things, or throw features out based on browser performance any more. I constantly underestimate what browsers are capable of. There's a 'pandemic' of over-optimization that heaps complexity (aka bloat) into web apps unnecessarily based on the mostly wrong belief that browsers are slow.
Devs need to be careful, and they need to measure things. They shouldn't start with the assumption that something will be slow.
What's really interesting about this whole question is that HN's least favorite frontend library, React, suffers this problem. The virtual DOM implementation was necessary a decade ago when React started, but DOM manipulation has been optimized in browsers so now the vdom is actually a bit of a hinderance (React has advantages other than speed, so it's still a fine choice.) Libraries that HN likes, such as Svelte and Solid, rely on the browser to be fast, because the browser is fast.
I don't know in which world you live in but most websites are incredibly unoptimised and over-engineered. They use a huge amount of resources on expensive machines and bring consumer machines to a grind.
I wish we lived in a pandemic of over-optimization.
It's entirely possible for both things to be true at the same time. Tons of developers prematurely optimizing things that don't matter because they make assumptions about performance. Those assumptions can also mean an epidemic of not optimizing things that *do matter*.
> Devs need to be careful, and they need to measure things. They shouldn't start with the assumption that something will be slow.
I disagree. The specs of developers' machines typically so far surpass those of users as to make that assumption valid more often than not.
Further, the fail case for incorrectly assuming that a web page will be fast ranges from it being slow to it being unusable, while the fail case for incorrectly assuming that a web page will be slow is that it is slightly more responsive than expected.
> The specs of developers' machines typically so far surpass those of users as to make that assumption valid more often than not.
Billions of people are using computers that are 100 times slower than your machine in different metrics. 100 times less space on hard drive, 100 times slower hard drive, 100 times slower processor, 8-16 times less memory, etc.
But then they probably won't pay you anyway, also if you target them, you have to make compromises that will affect the overall quality.
Without wishing to create a paradox, it absolutely does, yes. I've been a web dev since 1997 and I frequently have to remind myself that I don't always need to optimize things, memoize things, or throw features out based on browser performance any more. I constantly underestimate what browsers are capable of. There's a 'pandemic' of over-optimization that heaps complexity (aka bloat) into web apps unnecessarily based on the mostly wrong belief that browsers are slow.
Devs need to be careful, and they need to measure things. They shouldn't start with the assumption that something will be slow.
What's really interesting about this whole question is that HN's least favorite frontend library, React, suffers this problem. The virtual DOM implementation was necessary a decade ago when React started, but DOM manipulation has been optimized in browsers so now the vdom is actually a bit of a hinderance (React has advantages other than speed, so it's still a fine choice.) Libraries that HN likes, such as Svelte and Solid, rely on the browser to be fast, because the browser is fast.