Supporting feature tests directly

James Kyle me at
Wed Mar 25 00:48:21 UTC 2015

I think you missed my point.

Just as people make mistakes, sometimes JavaScript engines make mistakes in their implementations (see: "the engine might be lying to you"), and there's plenty of places where we need to catch these mistakes (see my jQuery example from before). This is why something like `Reflect.supports('TCO')` is just as shallow as testing for existence.

Re: Getting stuck always transpiling syntax.

This does not lock us into transpiling syntax features forever, it just means you need to have the knowledge of your targeted platform at build time rather than run time.

For example:

- If I need to target a browser that does not support TCO, I'm going to transpile it for every browser I support.

- If I don't need to target a browser that does not support TCO, I'm not going to transpile it at all.

- James Kyle

On Tue, Mar 24, 2015 at 5:12 PM, Kyle Simpson <getify at> wrote:

>> A lot of feature detection relies on shallow tests:
>> However, others need to test that features are properly supported by the engine. This is because shallow testing does not cover engine quirks. 
> Of course, shallow tests are often totally sufficient, and I'm trying to have the most efficient method for doing that for places where there is no API identifier to check for.
> That doesn't mean that you wouldn't also conduct some targeted deeper semantics conformance tests in places you needed to. It just means that as a first pass, a lot of FT's that otherwise require `Function(..)` or `eval(..)` can have a shorter more optimal path supported by the engine.
> It's not intended to be an exclusive replacement for any test you could ever conceive.
>> relying on something like `Reflect.supports(...)` isn't any more useful than shallow feature detection
> Of course not. Nothing in my proposal is supposed to indicate as such.
>> (the engine might be lying to you).
> Good grief, why would we add a feature to ES2016+ that is intended to lie to developers or mislead them? :)
> But in all seriousness, why would an engine do something like that? The bad cases in the past where this kind of thing happened are all hold-over vestiges of a bad web (a locked-in IE ecosystem, a still-too-painfully-slow-to-update-and-siloed-mobile ecosystem, etc).
> Just because browsers have committed those sins in the past doesn't mean we have to assume they'll keep doing them.
>> TCO is one of the places where it is difficult to test for. However, it's a pretty rare that you would want to.
> Totally disagree here. Anyone that's following the (Crockford) advice of not using loops anymore and writing all recursion absolutely cares if such code can be directly loaded into a browser or not.
>> 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, totally disagree. At least, that's not even remotely my intention. That's locking us in to always running transpiled code forever, which basically makes the engines implementations of features completely pointless. That sounds like a horrible future to me.
> My intention is to feature test for the features/syntax that I need in my natively written code, and if tests pass, load my native code so it uses the native features. If any tests fail, I fall back to loading the transpiled code. IMO, this is the only remotely sensible go-forward plan to deal with the new transpiler-reality we're in.
> I'm even building a whole feature-detects-as-a-service thing to support exactly that kind of pattern. Will anyone else follow? I have no idea. But I sure hope so. I for one hope that we're using the actual ES6+ code browser makers are implementing rather than transpiling around it forever.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list