3 ms·
Honestly, imho there is no reason to do this, the cost-benefit analysis is all downsides and zero upsides. Removing this will absolutely break websites, and you
by anaisbetts 5y ago
Honestly, imho there is no reason to do this, the cost-benefit analysis is all downsides and zero upsides. Removing this will absolutely break websites, and you gain nothing as a result, except "technical correctness". Not a single user will benefit from that change.
- rightbyte 5y agoI feel some devs want low effort easy tasks to do, to give the impression of getting things done for KPI hunting. Otherwise why put in more work into removing something than its presense will ever generate. Like when Python removed support for Windows 7 for no good reason at all but it being past LTS. But there was a submit ...
- DannyBee 5y agoI don't think it's that simple. There is always a fine line between complexity and compatibility. The things that are barely used/almost unused are the things that often end up the least tested or looked at. Depending on how complex they are, and what they do, this is a recipe for bugs/security issues. When you have thousands of these things, not removing them over time is a great way to end up with a huge mess. On the other side, as you say, removing any of them rarely benefits users directly (except in some individually minuscule way like binary size). What seems to happen here strikes me as a reasonable balance - people try to trade off the complexity of the feature vs its use, and wait for it to become unused enough that it might be worth removing. As you can see, here they decided it wasn't worth it, and it's still there today.
- bastawhiz 5y agoExactly. How many bytes in the much-discussed electron bundle size is the result of lots of little things to support one-offs going back decades? How do you document and maintain all of these things, which were pulled from WebKit, which were pulled from KHTML, which have no real documentation or obvious purpose?