>
when you limit (not even block
) JavaScriptSpeaking as a web developer, blocker of JavaScript by default, uMatrix user, and extensive user script writer: limiting is vastly harder to deal with than blocking; your “even” is unjust. “No JavaScript” is easy to detect and cope with (even if it’s just to respond “nah, dude; JavaScript me, bro”), but coping with blocking some JavaScript requires you to consider what could be blocked and what to do about it in each case.
If you’re talking third-party scripts, then sure, developers should handle failure to load scripts/XHR/fetch, simply for normal people’s sake; for analytics especially there are well-trodden paths, though certainly occasionally you encounter sites that don’t tread them. (Note that when I say “third party” I mean the social concept of third party, not “different origin”, because it’s common to load first-party scripts from different origins—CDNs, &c.)
If you’re blocking things at a finer grain than first-party/third-party divide, then you should expect things will often blow up. It’s not particularly reasonable for them to detect and work with your meddling.
A few years ago I had to use Dropbox from time to time. It was always fun whenever it dropped my session (never for any obvious reason) and forced me to log in again, as I had to tweak my whitelists almost every time as they’d have shifted their CAPTCHA thing around or added a new CAPTCHA service (they had three or four going at once!) or something. It would take literally twenty seconds after pressing the submit button before it would decide to actually let me in, even with no intercepted requests. Not sure what was going on with that. And if anything was blocked, then it’d probably just hang indefinitely, often even without any exception ever being thrown in the console! Definitely not a good experience, and they should detect that a necessary script failed to load and notify you, but eh, I reckon I brought it on myself by using fine-grained blocking.