Ad blockers truly are the new virus scanners. They monitor everything that goes into and out of your computer and randomly break stuff just for kicks. And if that happens, it's somehow the fault of the software provider and not the ad blocker vendor.
You can't test against ad blockers (or virus scanners) because the lists keep changing, so you end up applying ridiculous alchemy like not calling your API endpoints "/analysis" but "/computation" and then you just hope for the best.
In the grand scheme of things, I agree that the people behind ad blockers are fighting the good fight, but in practice it's become a cat-and-mouse game of "who can break the internet the most". I don't know a solution.
This is a good reason to never prefix generated Javascript with hex hashes, at least without swapping out vowels. We rolled the dice one and had this happen on Wikispaces once; it was utterly infuriating to debug.
Nice catch, never thought about it. Is it more problematic with preffixes (vs. suffixes etc.) or should we generally avoid any random string? Appending a hash to the script is very convenient to force the download of the new version of an asset (but maybe we have better solutions now, haven't considered this issue in a while).
You can also do /js/myscript.js?v=1476929634 -- this generally works without any server-side changes. A CRC32 might work better, since controlling mtimes can be annoying.
Why is there a problem exactly? It seems even if hash contains "ad", uBlock origin is not blocking it. Does this problem exist for some specific ad blocking software?
We never understood why certain pull requests wouldn't load in Atlassian Stash/BitBucket Server - turns out our adblocker was blocking the page from loading due to having "ad" in the title.
I've run into that as well. I'm amazed that popular ad blockers still do that, since it's obviously trivial to work around for actual ads, and will result in so many false positives.
That's a hilarious comment, and a good point. But you can tell when your ad blocker is messing with site functionality beyond just blocking ads (i.e., the false positives your parent comment mentions). And at a certain point, this is a differentiator among the ad blockers.
+1 for the minimizing into one bundle thing. Sets of assets are loading sequentially which is slowing page load down.
Your code in each js file seems self-contained, so a simple in-order file concatenation into one .js file as a build step would help. gulp and gulp-concat would do it in a few lines of node, and you'd push the built output to your site.
If you end up wrting so much script that a concatenation approach stops scaling, look into webpack and web modules.
And that's one of the reasons I don't use an ad blocker. Not even uBlock Origin, which receives all the praise, is reliable in that sense.
I don't understand the crusade against people not using ad blockers by the way. I believe I have good reasons not to. Why do people seem to have a problem with that?
It seems related to your /js/ads-controller.js file (it gets blocked because of the "/js/ads-" portion in the path).
I would suggest fixing that (and preferably minimizing your JS into one bundle).