Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

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.
share|improve this question
It would be great if SO had wiki-like templates for things like this, so you could just do {{ES5}} and be done with it. – The Community Jan 5 '12 at 18:39
What will our content look like in 2 years? I don't wan to see this site be a black hole of old garbage and warnings that aren't applicable any more. Answers that indicate using $().attr in jQuery from 2009 make people searching in 2012 still think they're doing it the right way. We shouldn't be generating bad-knowledge. The question -- if it requires LEGACY support-- should get a LEGACY tag. – Incognito Jan 5 '12 at 18:49
@Incognito: To my mind, this isn't legacy support. Opera's ES5 support is brand new, IE's is brand-new, and a huge number of users aren't yet upgraded. This isn't legacy, it's the current reality. Hopefully it'll be legacy more quickly than the IE6 thing. :-) – T.J. Crowder Jan 5 '12 at 18:54
@T.J.Crowder Depends on your definition of legacy. "Denoting software or hardware that has been superseded". I would say browser versions less then the latest version is legacy. I do however agree that it's valid to add warnings for "strict mode" because the implementation isn't proper in Safari and IE9 – Raynos Jan 5 '12 at 18:58
I think it's more important not to mislead people now than it is to have stuff not done in an "old" (but not necessarily deprecated) style in 2 years. The question should have a legacy tag but you can't expect the OP to do anything, and you can't read their mind. If I gave a php answer that only worked in 3.x, I'd say that, even though 3 has been out for a while, because not everyone's using it. Why not have version tags (or templates) for answers, just like any good reference does? – The Community Jan 5 '12 at 19:00
@T.J.Crowder I understand your point, but you're only thinking of today. What do we do with the knowledge generated today when we have a much wider adoption of es5 in two years? We've warned people not to use stuff that's fully supported. – Incognito Jan 5 '12 at 19:07
@Incognito: I quite like GGG's idea of a tag or something we could use, and then we as a community could deprecate that tag (make it stop rendering) when no longer needed. Perhaps over-complex, but it addresses the "what about two years from now" issue. But although we want SO to be a reference, there's more harm done by tripping people up now than by having an extra paragraph they mostly don't need two years from now. – T.J. Crowder Jan 5 '12 at 19:48
up vote 17 down vote accepted

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.

share|improve this answer
"less experienced people may fail to test in an adequate sample of browsers." And that's where they learn the value of understanding the code they copy and paste and testing all browsers. – Raynos Jan 5 '12 at 18:20
@Raynos: They'll learn that lesson without our laying traps for them. – T.J. Crowder Jan 5 '12 at 18:24
@T.J.Crowder - great answer, but do you know why is China stuck on IE6? Is it because of bootlegged versions of windows that won't let them upgrade? – Adam Rackis Jan 5 '12 at 18:37
@AdamRackis: I don't, no, and I'd like to know. If it were bootlegged software, frankly I'd expect more up-to-date stuff. Probably it's people with old hardware who can't afford to upgrade. – T.J. Crowder Jan 5 '12 at 18:46
BTW, off-topic, but thank you for this - I've cited it more than a few times :) – Adam Rackis Jan 5 '12 at 18:51
@AdamRackis: *blush* Thanks! – T.J. Crowder Jan 5 '12 at 18:55
@AdamRackis There are a lot of chinese browsers that are just embed IE6. Last time I went to hong kong the PCs at the airport were running this chinese browser thats secretly IE6. – Raynos Jan 5 '12 at 19:10
@Raynos: "There are a lot of chinese browsers that are just embed IE6." Thanks, that makes sense. I think I've heard that before, too. Thanks for the info. – T.J. Crowder Jan 5 '12 at 19:52
@Raynos - thanks also. I didn't know that. – Adam Rackis Jan 5 '12 at 20:06
+1 - I agree that the answer should require a short note that the solution requires ES5 support. As long as we still feel like we have to support IE8, a shim is going to be required and it's way, way too easy for a relatively new coder to not realize that when getting solutions from here that don't mention it. Why lay the trap for them when the answer could educate them? P.S. I've been chastised myself for suggesting that an answer should mention that it requires ES5. There are many, many JS newbies here who would simply not know that until they are educated so it is useful to mention. – jfriend00 Jan 7 '12 at 2:33

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!

share|improve this answer
Very good points about not basing the decision on one's impression of the questioner, because of course the point of SO et. al. is to be reference material for others to follow (and one's impression of the questioner can be completely wrong). – T.J. Crowder Jan 5 '12 at 17:12

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.
share|improve this answer

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.

share|improve this answer
ES5 was just implemented by Opera and still lacks full support in Internet Explorer (waiting for 10) and Safari (5.1 almost made it). It's sensible to warn users that these magical new additions don't quite have stable support. – null Jan 5 '12 at 18:31
If I'm writing intranet software for the company I work at, I can certainly use ES5 features with abandon. If I'm writing a public-facing website, I have to add a shim to support (more or less) any browser, because otherwise I'm breaking the site for some of our customers. Warning inexperienced users about this is a good thing. That's just the world we live in. – Adam Rackis Jan 5 '12 at 18:41
If you give answers that you know will only work on about 50% of browsers, your answers are not helpful. IMO. – Andrew Barber Jan 5 '12 at 18:51
I think it is an act of great hubris to call something like 40% of the browsing public legacy. If you have the luxury of not needing to worry about those browsers, then bully for you. However, that doesn't represent most of us. I know of someone who made a baseball stats app who was shocked to find out how many of his customers were IE6 users — because baseball is so popular, and most people wanted to check at work. – JockM Jan 5 '12 at 18:51
With compiled and server-side languages, it's fine to give answers that only work in a relatively recent version of the language. With javascript, it's another story. 90% of these questions give no hint as to where this code is being deployed, so you have to assume it's probably going to be running in people's web browsers, not node.js or some intranet application (the OP probably would have mentioned that). Giving them code that's going to fail in a large percentage of the environments that the OP is probably assuming it will run in is kind of silly. Not telling them that is just mean. – The Community Jan 5 '12 at 18:52
A few years ago I had to support WebTV for a site I created, not because there were many users of it, but because The Most Important users were WebTV users. So it is a much more complicated situation than simply dismissing the legacy – JockM Jan 5 '12 at 18:53
@AdamRackis If your writing a public-facing website it will work without javascript so it's irrelevant. if it doesn't work without javascript you have bigger problems – Raynos Jan 5 '12 at 18:56
@Raynos - let's say I use unobtrusive JS to intercept a form submission. The JS works in IE8. I cancel the default form post, am putting together my ajax request, and all of a sudden use array.filter. Bam. Broken. I'm (barely) smart enough to know this, but newbie users may not be. Warning them is a must. – Adam Rackis Jan 5 '12 at 18:59
@AndrewBarber define: legacy "Denoting software or hardware that has been superseded but is difficult to replace because of its wide use.". It is perfectly valid to say browser that are not the latest version are legacy. – Raynos Jan 5 '12 at 18:59
@AdamRackis meh as mentioned elsewhere, if your going to use Array#filter you should a) know what it does and b) know what the browser support is like. I don't write answers to be copy and pasted by mediocre programmers. – Raynos Jan 5 '12 at 19:01
"if your going to use Array#filter you should a) know what it does and b) know what the browser support is like." So it should follow that if you're going to tell someone to use Array#filter you should probably tell them that they need to know all that stuff, unless you're just being a dick. – The Community Jan 5 '12 at 19:07
@Raynos I wasn't involved in any discussion of the term "legacy". My only concern: someone giving answers that they know will fail in about 50% of the browsers in current use. – Andrew Barber Jan 5 '12 at 19:11
@Raynos Again: if a solution to a question about a public website fails in about 50% of the browsers that will be viewing that website, I consider the answer not to be helpful. I don't care what names you put to the 50%. – Andrew Barber Jan 5 '12 at 19:27
@Raynos On the other hand, if your solution works on 99.5% of the users of the site, I again don't care what you call the 0.5%. (roughly comparable to the real proportion of IE6 users on sites I might often work on, as an example) – Andrew Barber Jan 5 '12 at 19:30
@Raynos - sadly, having code work in a majority of browsers is a requirement most of us have. Telling users it's their fault for using IE8 is simply not an option. Pointing an OP toward an MDN shim and telling them to drop it in their code to support older browsers is a good idea. – Adam Rackis Jan 5 '12 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .