Supporting feature tests directly

James Kyle me at
Wed Mar 25 21:03:44 UTC 2015

It's not that it's imperfect. It's that it's useless in the real world.

We can already do shallow testing of APIs. doesn't help there, and in some ways (that I've outlined before) it is a regression.


if (!Array.prototype.includes) { ... }

if (!Reflect.supports("Array.prototype.includes")) { ... }


You also wouldn't do testing of syntax support at runtime, as you would effectively be duplicating the code.


var myFunc;

if (Reflect.supports("TCO")) {

  myFunc = recursiveImplementation;

} else {

  myFunc = nonRecursiveImplementation;

  // Why duplicate? You'd be saving yourself a lot of hassle by just transpiling to this



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?

No, that'd be absurdly slow, and now you've already delegated to using a build tool.

- James Kyle

On Wed, Mar 25, 2015 at 1:44 PM, Kyle Simpson <getify at> wrote:

> What this sub-discussion of CSS `supports(..)` is reinforcing is what I said earlier: a capability to do feature tests in a direct, efficient, and non-hacky manner is valuable to some/many uses and use-cases, even with the recognition that it doesn't have to *perfectly* support all conceivable uses/use-cases/tests.
> We should avoid a mindset that anything short of perfect isn't worth doing at all. Thankfully JS doesn't have such a design principle.
> A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally or intentionally lie. But it *could* be better to some audiences than having no information. I personally would prefer to use it, even with its "risks", than trying a long recursive loop in a `try..catch` to imply if TCO was in effect.
> Nevertheless, it's the least important kind of test being advocated for here, even though it seems to be getting all the attention. If that kind of test is a bone of contention, it should be the easiest to drop/ignore.
> Moreover, to reduce the risk of bitrot on feature lookup tables (that `Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )` type of test.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list