4 ms·

1) Write it from the beginning in such a way that it can be removed easily. Ideally a single chunk of code, an entire file, etc. 2) Put a big comment on it tha

1) Write it from the beginning in such a way that it can be removed easily. Ideally a single chunk of code, an entire file, etc. 2) Put a big comment on it that says "HACK: Remove when X is no longer the case" 3) Periodically check X when you think about it or come across that code If X is "users' browsers have collectively reached a certain milestone", that should be easy to measure for via logs

brabel 5y ago
> Put a big comment on it that says "HACK: Remove when X is no longer the case" You know, every now and then I come across some comment like that from 6 years ago that is clearly no longer applicable and I go and remove the hack... feels really good, but I don't think anyone will just go around looking for these trying to get rid of hacks as there's ALWAYS more important things to do... the hack will probably remain mostly harmless there for decades to come :D so why would we spend time on that other than by happenstance, like I've just mentioned?!
- brundolf 5y ago
  I mean it's really satisfying to do, and if the originator did make the thing easy to remove, then it doesn't take away much time from other priorities
chrismorgan 5y ago
The trouble with a lot of this stuff is that it happened in the distant past when the end state wasn’t clear; hindsight says you should have labelled the hack with the conditions that required it, but that wasn’t at all obvious then: you often didn’t know what might change to make your hack unnecessary or counterproductive. Nowadays, browser development is fairly principled so that you can express things like that—or better still, polyfill—but in the days of long ago you didn’t know who or what was going to win, and where browsers deviated it wasn’t a matter of comparing behaviour to spec and saying “this one is wrong” (which is normally how things will go these days), but rather… well, they’d probably keep on being different for a while, but maybe at some point one would cave and change to be more like the other, or maybe they’d change to something else altogether. And because many or most situations were like this, people never got into the habit of annotating such things even in cases where it was possible (e.g. once addEventListener had won, any attachEvent usage because you supported old IE should have been marked accordingly as unnecessary once IE9 was the baseline). They were the days of the wild west when frontend web development was far more ad hoc than principled.

brabel 5y ago

> Put a big comment on it that says "HACK: Remove when X is no longer the case" You know, every now and then I come across some comment like that from 6 years ago that is clearly no longer applicable and I go and remove the hack... feels really good, but I don't think anyone will just go around looking for these trying to get rid of hacks as there's ALWAYS more important things to do... the hack will probably remain mostly harmless there for decades to come :D so why would we spend time on that other than by happenstance, like I've just mentioned?!

brundolf 5y ago
I mean it's really satisfying to do, and if the originator did make the thing easy to remove, then it doesn't take away much time from other priorities

chrismorgan 5y ago

The trouble with a lot of this stuff is that it happened in the distant past when the end state wasn’t clear; hindsight says you should have labelled the hack with the conditions that required it, but that wasn’t at all obvious then: you often didn’t know what might change to make your hack unnecessary or counterproductive. Nowadays, browser development is fairly principled so that you can express things like that—or better still, polyfill—but in the days of long ago you didn’t know who or what was going to win, and where browsers deviated it wasn’t a matter of comparing behaviour to spec and saying “this one is wrong” (which is normally how things will go these days), but rather… well, they’d probably keep on being different for a while, but maybe at some point one would cave and change to be more like the other, or maybe they’d change to something else altogether. And because many or most situations were like this, people never got into the habit of annotating such things even in cases where it was possible (e.g. once addEventListener had won, any attachEvent usage because you supported old IE should have been marked accordingly as unnecessary once IE9 was the baseline). They were the days of the wild west when frontend web development was far more ad hoc than principled.