(if you don't know the author, he's a web evangelist, working previously for Mozilla, now for Microsoft; now you can understand his frustration, in the times of recent Chrome monoculture in the web)<p>I wholeheartedly agree with the author and wanted to post another long rant here, but I resisted the temptation :)<p>In this particular example of a WebGL demo, I think it was not exactly malicious, the issue was IMO most probably due to writing non-future-proof code, and then abandoning it (there was a related post last week about writing non-future-proof Python code that will break in python4, same applies here). Lots of early "HTML5" demos do not work anymore because they used some not-yet-standardized and/or prefixed syntaxes that have changed since etc.<p>Anyway, the link to [1] is very interesting. Many people underestimate the risk of third-party JS server going down (or being slow), adblockers preventing some JS from executing etc.<p>Edit: to clarify, I don't mean you should not use JS (heck I'm a JS developer, and IMHO the times of "progressive enhancement" are long gone, unless you serve almost only text content). I don't mean you should have 3 redundant servers to serve your JS from; just detecting that the thing didn't load, and not making assumption that it will be reliably delivered to the user in 0.1 s, would be good enough. There are pages out there that will totally break or fail to load if some non-important JS file is not loaded due to a network issue or whatever else.<p>It doesn't require infinite amount of work to handle some cases like that (though, sadly getting management buy-in for even small things like this is not easy, and we might sometimes have to go against the flow for the good of our users).<p>[1] <a href="http://kryogenix.org/code/browser/everyonehasjs.html" rel="nofollow">http://kryogenix.org/code/browser/everyonehasjs.html</a>
Whether or not you like the delivery, it is a reasonably good point. Personally, I'd have loved to read a little more how to do it right and a little less why.<p>The how to do it right is important because WebGL adoption is growing, and plenty of sites actually require it, as opposed to only having a tangential demo or fancy logo on it that isn't strictly necessary. If your site absolutely requires WebGL, and you block browsers incorrectly, you're hurting your site drastically.<p>I don't know what the best way to do it is, and I'd love to hear what other people do. My current thinking is: don't screw around with user agents, of course. This might be where the OP's complaint came from, because if you try to whitelist compatible browsers, new ones will always break immediately.<p>A better approach is put a canvas on your page, try to grab the webgl context, and check whether it failed. That way, if webgl can work, it will, and you only block people who have it turned off or actually have on old browser.<p>The message that announces the reason for failure is important, IMO. You can put up some explanation for how to fix the problem, because sometimes its fixable, or you can do something off-putting that only says 'fail' and chase people away.
For some reason this article received a fair amount of negative feedback here. I quite enjoyed it.<p>It's good to remind developers that they should ensure that their products degrade gracefully, and to give a few examples of what could go wrong. Mentioning the (somewhat basic, but still generally effective) fault-tolerance of HTML/CSS vs JS along with the user's basic viewpoint also helps to get his point across further.<p>Maybe I'm just used to reading longer form content, but I didn't feel that this brief blog post was a waste of time.
I use Linux+Firefox+Pipelight. Amazon Video used to work well with this, until some bright mind decided to force Silverlight and to check browser agent strings beforehand to make sure you are using a "supported browser version".<p>Of course, this bright mind never thought of people using pipelight. Well, now I have to set my browser agent to pretend I'm on Windows or Mac to get things working. Thanks Amazon for sucking so much.
Protip for Web programmers: "No, you can't count on Javascript."<p>Yes, I block your shitty Javascript. If I enable Javascript, I enable for your domain only. The 18 other domains are not going to load.<p>Get over it.
The problem is that it takes effort to support both with and without JS, and effort costs money. Just like many developers I like to do things properly and support both, however in a business context it doesn't always make sense to do so. 80/20 rule.
how do you write like 1500 words saying the same thing over and over and over? Read this article for 1500 simple little examples!<p>In before "say something positive": If whoever wrote this gets to write a long rambling complaint about some random website nobody has ever heard of having a bad error message, I can equally complain about my pet peeve: "people writing long blog posts whining about things that set them off but aren't the real reason they are so angry to begin with".
Seems a lot of people are doing the shit "we" (as in the older, sometimes even somewhat grumpier developers) have seen in the 90s, as in the "best viewed with Internet Explorer" shit -- making websites completely inacccesible to Netscape, all over again.<p>But this time with Chrome versus every other capable browser on the market.<p>Sigh.
OK, so the author purports to be on the side of "end users". And he purports to share empathy with users who get annoying messages that their browser is lacking, outdated, etc.<p>As an "end user" who has gotten hundreds of such messages over the years, I ask: How about Silverlight? Have you ever gotten an annoying message along the lines of "Sorry, you need Silverlight"?<p>I have. And I assure you I do not need Silverlight to watch video.<p>Speaking of empathy, just this week I believe someone posted to HN about a still undisclosed 0-day for Silverlight that someone wrote years ago, that still works flawlessly and recently sold for tens of thousands of US dollars on the black market.
I think he's really made because when developers write error messages the company doesn't like to suck it up and take the blame i.e. " we don't support your current browser" vs "YOU don't have webgl"
I'm sorry that you wasted your time going to a web toy you were not able to see! :'(<p>The developer made a mistake in his error handling routing so that it is triggered by a false positive.
This is likely because he made the demo on a time budget, because being a demo, it is not important to be perfect.
Okay, I won't tell you that your browser can't calculate, for every possible Javascript function, and every possible input to that function, the Boolean value indicating whether or not that function will halt. Don't mind me at all!<p>> <i>HTML and CSS both are fault tolerant. If something goes wrong in HTML, browsers either display the content of the element or try to fix minor issues like unclosed elements for you. CSS skips lines of code it can’t understand and merrily goes on its way to show the rest of it. JavaScript breaks on errors and tells you that something went wrong. It will not execute the rest of the script, but throws in the towel and tells you to get your house in order first.</i><p>HTML (or rather, processing thereof) being fault tolerant is a complete misfeature. It's the result of browser in the 1990's trying to out-do each other in handling broken web pages in order to look more functional. Broken HTML should be loudly rejected (at least in pages which declare strict conformance to a modern dialect).<p>CSS skipping stuff it doesn't understand is harmless because a declarative language for assigning style properties. It doesn't have permanent effects, like making a call to a server to update a database record.<p>A program in a general purpose language cannot reliably continue after an error (without logic to handle that situation). Later steps depend on the earlier ones having executed correctly in every detail.