I think bloat could be prevented if it was noticed the moment it is introduced.
After application evolves bloated, it's difficult to go back and un-bloat it.
Bloat is often introduced accidential/y, without need, and unnoticed just because developers test on modern and powerful devices.
If developer's regular test matrix included a device with minimal hardware pewer that was known to run the product smoothly in the past, the dev could immediately notice the newly introduced bloat and remove it.
A bloat regression testing.
I call this "ecological development".
We should all do this. No need to aim for devices that already have trouble running your app / website. But take a device that works today and test that you do not degrade with respect to this device.
> After application evolves bloated, it's difficult to go back and un-bloat it.
It will be hard to get to pristine quality, but there ought to be some amount of low hanging fruit, where minimal changes bring noticeable improvement.
Maybe, but determining it will take some investigation. If the regular testing is done on a low profile device, developer knows as soon as possible that his recent changes introduced a bloat regression.
After application evolves bloated, it's difficult to go back and un-bloat it.
Bloat is often introduced accidential/y, without need, and unnoticed just because developers test on modern and powerful devices.
If developer's regular test matrix included a device with minimal hardware pewer that was known to run the product smoothly in the past, the dev could immediately notice the newly introduced bloat and remove it.
A bloat regression testing.
I call this "ecological development".
We should all do this. No need to aim for devices that already have trouble running your app / website. But take a device that works today and test that you do not degrade with respect to this device.