> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
