Supporting feature tests directly

Kyle Simpson getify at gmail.com
Wed Mar 25 20:44:07 UTC 2015


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.


More information about the es-discuss mailing list