Supporting feature tests directly

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Supporting feature tests directly

Kyle Simpson
Has there been any consideration or discussion for direct support of feature tests for ES7+ features/syntax? I'm thinking specifically of things which are difficult or impossible to just simply test for, like via the existence of some identifier.

I have an idea of what that could look like, and am happy to discuss further here if appropriate. But I was just checking to see if there's any prior art around related specifically to JS to consider before I do?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Supporting feature tests directly

Domenic Denicola
I think you're referring to the `eval` function?

-----Original Message-----
From: es-discuss [mailto:[hidden email]] On Behalf Of Kyle Simpson
Sent: Sunday, March 22, 2015 05:28
To: [hidden email]
Subject: Supporting feature tests directly

Has there been any consideration or discussion for direct support of feature tests for ES7+ features/syntax? I'm thinking specifically of things which are difficult or impossible to just simply test for, like via the existence of some identifier.

I have an idea of what that could look like, and am happy to discuss further here if appropriate. But I was just checking to see if there's any prior art around related specifically to JS to consider before I do?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Axel Rauschmayer
In reply to this post by Kyle Simpson
I don’t think there are even documented best practices for ES6, yet (w.r.t. switching between native ES6 and transpiled ES6). That’d be interesting, too.

On 21 Mar 2015, at 21:28, Kyle Simpson <[hidden email]> wrote:

Has there been any consideration or discussion for direct support of feature tests for ES7+ features/syntax? I'm thinking specifically of things which are difficult or impossible to just simply test for, like via the existence of some identifier.

I have an idea of what that could look like, and am happy to discuss further here if appropriate. But I was just checking to see if there's any prior art around related specifically to JS to consider before I do?

-- 
Dr. Axel Rauschmayer
[hidden email]
rauschma.de




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Jordan Harband
In http://npmjs.com/make-generator-function, https://www.npmjs.com/package/make-arrow-function, and the tests for https://github.com/es-shims/RegExp.prototype.flags/blob/master/test/index.js#L6-L12, I use `Function` eval to test for support of these things - one could do the same with `let`, `const`, etc.

I'd be very interested to hear about any non-eval solution for this.

On Sat, Mar 21, 2015 at 5:10 PM, Axel Rauschmayer <[hidden email]> wrote:
I don’t think there are even documented best practices for ES6, yet (w.r.t. switching between native ES6 and transpiled ES6). That’d be interesting, too.

On 21 Mar 2015, at 21:28, Kyle Simpson <[hidden email]> wrote:

Has there been any consideration or discussion for direct support of feature tests for ES7+ features/syntax? I'm thinking specifically of things which are difficult or impossible to just simply test for, like via the existence of some identifier.

I have an idea of what that could look like, and am happy to discuss further here if appropriate. But I was just checking to see if there's any prior art around related specifically to JS to consider before I do?

-- 
Dr. Axel Rauschmayer
[hidden email]
rauschma.de




_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
In reply to this post by Kyle Simpson
> I think you're referring to the `eval` function?

Actually, I'm referring to proposing something new that would substitute for having to hack feature tests with `eval`.

These are the initial details of my idea, a `Reflect.supports(..)` method: https://gist.github.com/getify/1aac6cacec9cb6861706

Summary: `Reflect.supports( "(()=>{})" )` or `Reflect.supports( "let x" )` could test **just** for the ability to parse, as opposed to the compilation/execution that `eval(..)` does. It'd be much closer to `new Function(..)` except without the overhead of needing to actually produce the function object (and then have it be thrown away for GC).

This is inspired by https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API, where FF has a `Reflect.parse(..)` method that is somewhat like what I'm suggesting, except that for feature tests we don't need the parse tree, just a true/false of if it succeeded.

An alternate form would be `Reflect.supports( Symbol.arrowFunction )`, where the engine is just specifically saying "yes" I support that feature by recognizing it by its unique built-in symbol name.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Andrea Giammarchi-2
+1 to Kyle proposal, using eval or Function is not even an option in CSP constrained environments ( unless the relative code is provided as SHA256, then we need to agree on how such code should look like and share it as polyfill )

I'd also suggest `Reflect.isValidSyntax` as alternative to `Reflect.supports` 'cause it's less misleading when it comes to figure out APIs support and their implementation.

After all, that's exactly what we'd like to know, if a generic syntax will break or not.

Regards

On Sun, Mar 22, 2015 at 1:00 AM, Kyle Simpson <[hidden email]> wrote:
> I think you're referring to the `eval` function?

Actually, I'm referring to proposing something new that would substitute for having to hack feature tests with `eval`.

These are the initial details of my idea, a `Reflect.supports(..)` method: https://gist.github.com/getify/1aac6cacec9cb6861706

Summary: `Reflect.supports( "(()=>{})" )` or `Reflect.supports( "let x" )` could test **just** for the ability to parse, as opposed to the compilation/execution that `eval(..)` does. It'd be much closer to `new Function(..)` except without the overhead of needing to actually produce the function object (and then have it be thrown away for GC).

This is inspired by https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Parser_API, where FF has a `Reflect.parse(..)` method that is somewhat like what I'm suggesting, except that for feature tests we don't need the parse tree, just a true/false of if it succeeded.

An alternate form would be `Reflect.supports( Symbol.arrowFunction )`, where the engine is just specifically saying "yes" I support that feature by recognizing it by its unique built-in symbol name.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
> ...using eval or Function is not even an option in CSP constrained environments

> ...that's exactly what we'd like to know, if a generic syntax will break or not.

Furthermore, there are things which are valid syntax which cannot be directly `eval`'d or `Function`'d, such as `import` and `export`.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Supporting feature tests directly

Gary Guo
So why not just add a sandbox, and let uncertificated codes run in the sandbox, providing the external environment means to catch error (or interact somehow)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Supporting feature tests directly

Mark S. Miller-2

The combination of the loader and realm APIs should give us that and, of course, more.

On Mar 22, 2015 8:52 AM, "Gary Guo" <[hidden email]> wrote:
So why not just add a sandbox, and let uncertificated codes run in the sandbox, providing the external environment means to catch error (or interact somehow)

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
In reply to this post by Kyle Simpson

> So why not just add a sandbox, and ... means to catch error

Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle is, even a little bit, slower than a feature test that requires only the parser to answer the question at hand.

Since these tests are likely to happen in the critical path (page load), their speed is pretty important to be as optimal as possible.

------

I don't want or need a general means to try out a whole program to see if it compiles or not. Don't let the `eval`-looking form of the proposal mislead as to intention. Intention is only to, feature-by-feature, determine feature support where simple tests for identifiers is insufficient.

For example, this is *not* intended to be possible:

```js
let x;
Reflect.supports( "let x;" ); // false -- dupe declaration!
```

That kind of test would require running in the context of the current lexical env, and would imply an entirely different level of integration with the program than intended. I don't need static errors like preventing duplicate declaration or anything of that nature. Even stuff like what `strict mode` would enforce are outside of the "scope" of what's being proposed.

Only want to know if, in general, `let x;` could parse by the current engine. That's why `Reflect.supports( Symbol.letDecl )` would be an entirely sufficient option.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Jordan Harband
The only concern I'd have with a symbol approach is that there are likely to be engine variances in the future - in the case of "let", knowing that the syntax is supported doesn't mean that ES6's semantics apply, it just means it won't throw a SyntaxError.

If that's the sole goal - detecting SyntaxErrors efficiently without using eval - then I think this is great - but what I'd really love to see is a path towards a built-in comprehensive way to determine semantic capabilities at runtime (as opposed to all the feature detection that devs/polyfills/shims/etc have to do now).

On Sun, Mar 22, 2015 at 1:46 PM, Getify Solutions <[hidden email]> wrote:

> So why not just add a sandbox, and ... means to catch error

Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle is, even a little bit, slower than a feature test that requires only the parser to answer the question at hand.

Since these tests are likely to happen in the critical path (page load), their speed is pretty important to be as optimal as possible.

------

I don't want or need a general means to try out a whole program to see if it compiles or not. Don't let the `eval`-looking form of the proposal mislead as to intention. Intention is only to, feature-by-feature, determine feature support where simple tests for identifiers is insufficient.

For example, this is *not* intended to be possible:

```js
let x;
Reflect.supports( "let x;" ); // false -- dupe declaration!
```

That kind of test would require running in the context of the current lexical env, and would imply an entirely different level of integration with the program than intended. I don't need static errors like preventing duplicate declaration or anything of that nature. Even stuff like what `strict mode` would enforce are outside of the "scope" of what's being proposed.

Only want to know if, in general, `let x;` could parse by the current engine. That's why `Reflect.supports( Symbol.letDecl )` would be an entirely sufficient option.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
In reply to this post by Kyle Simpson
> likely to be engine variances in the future

I hope you just mean like changes that ES7 might make to an ES6 feature. And I hope those aren't syntactic as much as semantic. :)

If there was a change on syntax, I would assert that should be considered a "new feature" with its own new test, even if it was just a variation on an existing one. Like `Symbol.arrowLiteral` and `Symbol.conciseArrow`, where the second test might check specifically places where the grammar for arrows was relaxed to allow omission of `( )` or whatever.


> knowing that the syntax is supported doesn't mean that ES6's semantics apply

That's true. But I think semantics are more a run-time concern, and thus should be checked with actually executed code (`Function(..)`, etc).

Off the top of my head, things which are statically verifiable, like duplicate param names, could be checked (if that's the kind of thing a parser even checks), but things like if we relax and allow implicit symbol coercion are much more clearly run-time errors.


> If that's the sole goal - detecting SyntaxErrors efficiently without using eval

Yep, that's it.

Consider it a first-pass quick feature test for syntax… if more extensive deeper run-time semantics checks are necessary, that would more be the realm of `Function(..)` or other similar (future) features. At least in those deeper-check cases, you wouldn't have to worry about catching `SyntaxError`s, since you could know in advance before trying the more performance-expensive tests.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Rick Waldron
In reply to this post by Kyle Simpson


On Sun, Mar 22, 2015 at 4:47 PM Getify Solutions <[hidden email]> wrote:

> So why not just add a sandbox, and ... means to catch error

Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle is, even a little bit, slower than a feature test that requires only the parser to answer the question at hand.

Since these tests are likely to happen in the critical path (page load), their speed is pretty important to be as optimal as possible.

------

I don't want or need a general means to try out a whole program to see if it compiles or not. Don't let the `eval`-looking form of the proposal mislead as to intention. Intention is only to, feature-by-feature, determine feature support where simple tests for identifiers is insufficient.

For example, this is *not* intended to be possible:

```js
let x;
Reflect.supports( "let x;" ); // false -- dupe declaration!
```

That kind of test would require running in the context of the current lexical env, and would imply an entirely different level of integration with the program than intended. I don't need static errors like preventing duplicate declaration or anything of that nature. Even stuff like what `strict mode` would enforce are outside of the "scope" of what's being proposed.

Only want to know if, in general, `let x;` could parse by the current engine. That's why `Reflect.supports( Symbol.letDecl )` would be an entirely sufficient option.



The SpiderMonkey/Firefox Reflect.parse is non-standard, but may be a useful place to start.

First, "import" the "reflect.jsm" component module: 

  Components.utils.import("resource://gre/modules/reflect.jsm");

Then try this: 

  function isSyntaxSupported(syntax) {
    try {
      Reflect.parse(syntax);  
      return true;
    } catch (_) {
      return false;
    }
  }

  [
    "import foo from 'bar';",   // valid
    "export var a = 1;",        // valid
    "export default class {}",  // valid
    "export class List {}",     // valid
    "async function foo() {}",  // invalid
    "let (x = 1) { x; }",       // invalid
    "module Name {}",           // invalid
  ].forEach(function(syntax) {
    console.log("`%s` is %ssupported", syntax, isSyntaxSupported(syntax) ? "" : "un");
  });


Firefox 38.0a2 (2015-03-23): 

"`import foo from 'bar';` is supported"
"`export var a = 1;` is supported"
"`export default class {}` is unsupported"
"`export class List {}` is unsupported"
"`async function foo() {}` is unsupported"
"`let (x = 1) { x; }` is supported"
"`module Name {}` is unsupported"



Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Косыч Дед
What about checking tail call optimization support?
Imho, we need a possibility to verify engine supports it.
`eval`, `Function` and `Reflect.parse` wont work here.
So `Reflect.supports` looks more meaningful in this case.

On Mon, Mar 23, 2015 at 3:31 PM, Rick Waldron <[hidden email]> wrote:


On Sun, Mar 22, 2015 at 4:47 PM Getify Solutions <[hidden email]> wrote:

> So why not just add a sandbox, and ... means to catch error

Other than the `import` / `export` thing I mentioned, for the exact reason why `eval(..)` and `new Function(..)` are not preferred (which roughly do the same thing)… A feature test that requires the entire parse/compile/execute cycle is, even a little bit, slower than a feature test that requires only the parser to answer the question at hand.

Since these tests are likely to happen in the critical path (page load), their speed is pretty important to be as optimal as possible.

------

I don't want or need a general means to try out a whole program to see if it compiles or not. Don't let the `eval`-looking form of the proposal mislead as to intention. Intention is only to, feature-by-feature, determine feature support where simple tests for identifiers is insufficient.

For example, this is *not* intended to be possible:

```js
let x;
Reflect.supports( "let x;" ); // false -- dupe declaration!
```

That kind of test would require running in the context of the current lexical env, and would imply an entirely different level of integration with the program than intended. I don't need static errors like preventing duplicate declaration or anything of that nature. Even stuff like what `strict mode` would enforce are outside of the "scope" of what's being proposed.

Only want to know if, in general, `let x;` could parse by the current engine. That's why `Reflect.supports( Symbol.letDecl )` would be an entirely sufficient option.



The SpiderMonkey/Firefox Reflect.parse is non-standard, but may be a useful place to start.

First, "import" the "reflect.jsm" component module: 

  Components.utils.import("resource://gre/modules/reflect.jsm");

Then try this: 

  function isSyntaxSupported(syntax) {
    try {
      Reflect.parse(syntax);  
      return true;
    } catch (_) {
      return false;
    }
  }

  [
    "import foo from 'bar';",   // valid
    "export var a = 1;",        // valid
    "export default class {}",  // valid
    "export class List {}",     // valid
    "async function foo() {}",  // invalid
    "let (x = 1) { x; }",       // invalid
    "module Name {}",           // invalid
  ].forEach(function(syntax) {
    console.log("`%s` is %ssupported", syntax, isSyntaxSupported(syntax) ? "" : "un");
  });


Firefox 38.0a2 (2015-03-23): 

"`import foo from 'bar';` is supported"
"`export var a = 1;` is supported"
"`export default class {}` is unsupported"
"`export class List {}` is unsupported"
"`async function foo() {}` is unsupported"
"`let (x = 1) { x; }` is supported"
"`module Name {}` is unsupported"



Rick

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
In reply to this post by Kyle Simpson
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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

James Kyle
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. 


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

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Kyle Simpson
> That sounds like a horrible future to me.

> IMO, this is the only remotely sensible go-forward plan to deal with the new transpiler-reality we're in.

> I for one hope that we're using the actual ES6+ code browser makers are implementing rather than transpiling around it forever.

Ugh. Apologies for the hyperbole. Got carried away. But that *is* how strongly I feel about it.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

James Kyle
In reply to this post by Kyle Simpson
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 <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Supporting feature tests directly

Brendan Eich-2
In reply to this post by Kyle Simpson
Kyle Simpson wrote:
> 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.

LOL.

I don't think Crock was totally serious there... Let's get PTC support
in all engines and then find out.

/be
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12