<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-size:12.8000001907349px">It's not that it's imperfect. It's that it's useless in the real world.</span></blockquote><div>... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">What's the alternative? To send down a file that tests for support and then sends it back to the server and then build the appropriate assets for that browser?</span></blockquote><div> </div><div>Its possible in the AMD approach. Idk though if its useful.</div><div><br></div><div>The need in TCO detection is really debatable, but one might be using it, say, in two years from now to throw a _proper_ exception while running some crazy recursive code in an old browser.</div><div><br></div><div>NB: it would be practical only if feature detection possibility lands to a browser with (or even before) corresponding feature. And, imho, that's what Kyle Simpson meant, starting the thread: handy feature detection available _prior_ to feature implementation.</div><div><br></div><div>Two more off-topic cents:</div><div>If at any point we will </div><div><ul><li>have adjustable features, like disabling at some scope `eval`, `with`, `Function()` or using `global object`<br></li><li>or a new `stricter mode`<br></li><li>or choosing new Number representation</li><li>... or whatever</li></ul></div><div>it would be nice to be able to detect such state, without `try..catch` in a fast & semantic way.</div><div class="gmail_extra"><br></div></div>