Supporting feature tests directly

Kyle Simpson getify at
Thu Mar 26 15:51:05 UTC 2015

> doesn't yet solve my use cases, although I can't speak for Kyle.

It would not support my use-case. At least, in the sense that it's an all-or-nothing which is counter to what I'm looking for. It's also going to be way more processing intensive than just doing an `eval` / `Function` test, which defeats the entire point of the proposal.

> a feature that was specificatlly design to enable non-conforming implementations

That's not at all the intent of this feature. More below.

> This sort of feature testing is inherently a short term need. Within a few years, all implementations will support all major features

Within a few years, all implementations will be ES6 compilant, sure. But they'll never all be entirely up to date on ES2016, ES2017, ES2018, … as they roll out.

This feature testing mechanism is intended to be a rolling window of FT's for the gap between when something is standardized (to the point that developers could rely on polyfills/transpiles for it) and when it's fully implemented in all browsers that your app is running on. This gap could be as short as 6-12 months and (considering mobile) as long as several years.

On an app-by-app, need-by-need basis, there will *always* be such a gap, and FT's let you know what you have available at that moment in that specific browser.

This is directly analogous to all other classes of FT's, such as modernizr (focused more on HTML/CSS, with JS only as it related to one of those).

> For example, I’m sure nobody today has a need to test Reflect.supports(Symbol.functionExpression) or Reflect.supports(Symbol.tryCatch).

No, they don't. Exactly my point with the rolling window. And exactly why I stated that the intent of this feature is *not* about ES6 (or ES5) features, but rather about new stuff in ES2016+. It would be my hope that the feature testing API proposed could be one of the first things browsers could land post-ES6, which would mean devs could soon'ish start using those tests to track/cope with the gap between the ES2016 stamp of approval and when all those ES2016 features land. And of course the same for ES2017 and beyond.

And since what I'm asking for is stuff that, largely, can already be tested, just less efficiently, we could very quickly polyfill `Reflect.supports` to let devs use it even earlier.

> would be throw-away work that within in few years would just be legacy baggage

My design intent with my proposal, supporting the string syntax form, is to not have a huge table of lookup values that are legacy baggage and thrown away, but a general feature that is flexible and continues to be useful going forward.

The few exception cases, if any, like for example a `Symbol.TCO` test or whatever, would be very small, and their "burden" of legacy would be quite low once we're past the window of them being useful.

> a feature such as Reflect.parse which has other uses 

As I mentioned near the beginning of this thread, `Reflect.parse(..)` would generally suit the proposed use-case, except it does a lot of extra work (creating and returning a tree -- a value that then I'd be throwing away creating unnecessary GC) that feature testing itself doesn't need. It's unclear that `Reflect.parse(..)` would provide any additional performance gains over the current `eval` / `Function` approach, and could even be potentially worse.

It's also unclear that `Reflect.parse(..)` would ever have any reasonable answer for the "hard" tests we've briefly touched on, such as exposing semantics like TCO or any other sorts of things we invent which can't reasonably be tested by syntax checks or pragmatically tested via runtime code. At least `Reflect.supports(..)` *could* have an answer for that.

More information about the es-discuss mailing list