JavaScript answers using ES5 features: Warn or not?

Question

I recently saw an answer to a JavaScript question where the answer used Array#filter without mentioning that it's a new feature of JavaScript as of ECMAScript 5th edition (aka ES5), so I commented that it would be worth mentioning that.

I got a reply from the person posting the answer that they thought not saying anything about it is "not an issue at all." I got a stronger reply from a second commenter saying "When can we stop putting a disclaimer...on every single answer that uses ES5?" The second commenter later called it "noise" and "messy," whereas to me it's a disservice to the questioner to leave this trap for them to fall into.

What's your take?

There are probably at least four answers to this question:

1. Always warn them when you use ES5 features.
2. Warn them when you use ES5 features if they seem somewhat like newbies.
3. Warn them when you use ES5 features that cannot be emulated by es5-shim.js and similar.
4. Never warn them.

Answer 1

My take is that it's virtually no effort, and certainly not noise, to just throw this at the end of any answer that uses ES5 features:

Note that the above uses ____ from ES5. Not all browsers have it yet, if you need to support them you'll need to supply it (perhaps via es5-shim.js or similar).

Three reasons:

1. People asking JavaScript questions are a self-selected group: People who don't already know JavaScript and its uses in various environments inside and out.

2. At the moment (January 2012), approximately half the users of the web, worldwide, are using browsers that don't have ES5 support yet (link).* Web developers tend to use modern browsers, and so the person innocently using the suggested code would happily use Array#filter and then later trip over the fact that it was missing from, say, IE8 (to pick an example with 28% of the global user share at present).

3. It's a brief note at the end of an answer, not getting in the way of the main answer's text.

Now granted, developers should always test their code on all their target browsers, so hopefully they'd see the "Object does not support this property or method" and eventually find out about ES5 and such, although less experienced people may fail to test in an adequate sample of browsers.

Surely it's neither hard nor inappropriate to throw them a bone a'la the above.

---

* IE8 (28%) + IE7 (4.8%) + IE6 (7%, mostly China) + Firefox 3.6, 3.5, 3.0 (5.3%) = ~45% for sure, and we can expect others from the "other" category also lack support.

Answer 2

As you've proven in your stats in your answer, browsers which don't support ES5 at all or partially are very much common place.

When we get into a situation like we are now with IE6 I'll happily do away with the warning, but until then (and let's be honest, it's a long way away) I'm all for it.

---

1. Always warn them when you use ES5 features.

   Yes, this is what I do; for the reasons below. As you mentioned, it's very little effort.

2. Warn them when you use ES5 features if they seem somewhat like newbies.

   Beneficial to the OP, but newbies coming across the question will be unaware of this.

3. Warn them when you use ES5 features that cannot be emulated by es5-shim.js and similar.

   Again, you can't guarantee that either they, or other people coming across the question know about such things.

4. Never warn them.

   ... and in the meantime prepare an answer to their imminent question of "Why doesn't this code work?"... I like your thinking!

Answer 3

Propose answers which are generally working well, and not specific for a small group of users, unless explicitly requested.

Mention the usage of modern / not-well-supported technologies, and propose reasonable solutions for backward-compability.

You don't have to show the whole code, or support IE6, unless explicitly mentioned. At least include a link to documentation and/or other answers/blog posts which describe how to implement the feature.

---

For example, in this answer, I show three methods of achieving the same effect.

1. The first method is a one-liner, which only works for most recent versions of Firefox.
2. The second answer is using an ES% feature.
3. The final part of my answer generally works across all browsers.

Answer 4

There is no problem with adding this disclaimer if you want to, it just shouldn't be needed.

Adding a disclaimer to all my answers that use ES5 along the lines of "Feature X won't work in ES3, go use the ES5 shim or port it to ES3" code is messy. That's the exact same as adding a signature to all my answers. It's bloated boilerplate and just becomes noise.

Do we need to back and add warnings to every reference of JSON.parse because it's not implemented in IE7 ?

I see exactly what your saying with warning users about legacy browsers not implementing some features, it's just a matter of drawing the line somewhere. Your not going to leave a disclaimer about some feature not working in IE5 or NN8.

I draw the line at only making disclaimers about features that don't work in major browsers.

Since ES5 currently works in all major modern browsers and is only a problem for legacy browsers (even if they have a non-trivial market share).

I don't add disclaimers for ES5 features. If a user asks a question about javascript without mentioning it has to run in legacy browser X then it's that users problem to get his code running in legacy browsers, not mine.