Supporting feature tests directly

James Kyle me at thejameskyle.com
Tue Mar 24 23:22:53 UTC 2015


Taking steps to make sure new features can be feature tested is A Good Thing® but relying on something being set that says "I support X" probably isn't the best path to take.




A lot of feature detection relies on shallow tests:




i.e. `if (!Array.prototype.includes) { ...` 




However, others need to test that features are properly supported by the engine. This is because shallow testing does not cover engine quirks. 




i.e. https://github.com/jquery/jquery/blob/7602dc708dc6d9d0ae9982aadb9fa4615a9c49fa/external/sizzle/dist/sizzle.js#L165-L191





So while I agree that feature support should be detectable as much as possible, relying on something like `Reflect.supports(...)` isn't any more useful than shallow feature detection (the engine might be lying to you).




TCO is one of the places where it is difficult to test for. However, it's a pretty rare that you would want to.




i.e.




```


var maybeRecursive;




if (Reflect.support('TCO')) {

  maybeRecursive = function(n) {


    n < 1000000 ? maybeRecursive(n++) : n;


  };

} else {

  maybeRecursive = function(n) {


    while (n < 1000000) {

      n++;

    }

    return n;

  }

}




recursive(0);

```




In this case you would just write the second. This is also true for most syntax features: you wouldn't use feature detection, you would simply transpile your code down to the lowest level of support you need it to have.




Again, definitely a good idea to ensure feature support is detectable. Luckily this is fairly well covered by the tc39 process since a polyfill is required as early as stage 1.




- James Kyle










On Tuesday, Mar 24, 2015 at 3:44 PM, Kyle Simpson <getify at gmail.com>, wrote:
I should stress that while my original proposal (linked earlier in thread) mentions some of the "hard" ES6 cases (like TCO), my focus is not on creating feature tests for ES6. ES6 has sailed. Any feature we could possibly conceive here is quite unlikely to land in a browser before that browser gets all (or at least most) of the ES6 stuff that one might be wanting to test for.


My goal is for us to stop adding features to JS that aren't practically feature testable. I would strenuously desire to have something like `Reflect.supports(..)` (of whatever bikeshedded form) in ES2016 along with any new conceived features. That goes a thousand times more if we invent new syntax (we likely are) or new untestable semantics (like TCO).


Of course, if we had `Reflect.supports(..)` now, it'd be amazingly helpful in detecting TCO, which I would dearly love. But that's not the goal. I don't think we need to muddy the waters about what the ES6 feature tests would be. At least not for now.

_______________________________________________

es-discuss mailing list

es-discuss at mozilla.org

https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150324/d1594249/attachment.html>


More information about the es-discuss mailing list