[lukifer]

I agree that the NoScript folks can be ignored for apps. However, for web sites which consist primarily of rich documents, it's polite to at least try to convey the same information.

> Specifically building your app to attempt to handle the "bad data connection" use case that users already are familiar with in the context of the internet seems like bad programming.

Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Also, not all users will understand that components didn't load (many users still don't even know what a browser is!). And if the failed load is due to a proxy/firewall/DNS problem, or just a straight-up bug, a reload may not solve it anyway.

In any case, you're spot on about prioritizing development to the audience. Guidelines can be a good start, but there's no "one size fits all" for the web.

[criley]

>Au contraire: It's the height of good programming to attempt to predict and handle as many real-world errors as humanly possible. If I'm writing a USB device driver, you'd best believe I should try to do something sane if the cable comes unplugged, rather than just saying "don't do that".

Should you devote a lot of your limited programming time to catching an exception that users naturally experience during USB operation and can be corrected by a simple "unplug and replug?"

I argue that you shouldn't devote undue attention to something that users naturally already handle.

But if your project is healthy and features are rolling out and you have the time and talent to waste on edge cases like this, then why not!