Supporting feature tests directly

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

Re: Supporting feature tests directly

Tab Atkins Jr.
On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
<[hidden email]> wrote:

> +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.

CSS has an exactly analogous feature already, and calls it
CSS.supports().  That's a decent reason to stick with supports() as
the name.

~TJ
_______________________________________________
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
For consistency sake I agree, but I come from a world where browsers also exposed unofficially APIs so that, as James mentioned already, `Array.prototype.includes` would have returned true and never worked.

I wonder how reliable is `CSS.supports` not just in term of syntax, but actual usability.

Best Regards

On Wed, Mar 25, 2015 at 7:44 PM, Tab Atkins Jr. <[hidden email]> wrote:
On Sun, Mar 22, 2015 at 3:59 AM, Andrea Giammarchi
<[hidden email]> wrote:
> +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.

CSS has an exactly analogous feature already, and calls it
CSS.supports().  That's a decent reason to stick with supports() as
the name.

~TJ


_______________________________________________
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

Tab Atkins Jr.
On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
<[hidden email]> wrote:
> For consistency sake I agree, but I come from a world where browsers also
> exposed unofficially APIs so that, as James mentioned already,
> `Array.prototype.includes` would have returned true and never worked.
>
> I wonder how reliable is `CSS.supports` not just in term of syntax, but
> actual usability.

You give it a full property declaration, and if the browser can parse
it successfully, it returns true/false.  This allows for false
positives (a browser parsing a property but not actually supporting it
yet), but devs (rightfully) yell and scream at browsers whenever that
case (parse but no support) happens, so we do it very rarely, and only
ever by accident.

It's just a standardized version of the de facto standard CSS feature
test of "set the property on an element, and try to read it back; if
you get something, it's supported".

Because it's based on an objective and reliable criteria tied to
directly to actual support (successful parsing), it's reliable in
practice as a feature test.  This differentiates it from the old
hasFeature() function, which was based on a map of feature strings to
bools stored in the browser, with no connection to the actual features
in question, and so was inevitably filled with lies and bitrot.

~TJ
_______________________________________________
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
The reason `@supports` works in CSS is because of the limited language feature-set CSS has, but this wouldn't work in JavaScript.

To reuse the TCO example:

```
var supportsTCO = Reflect.supports('function recursive() { recursive() }');
```

Of course that will parse, and executing it wouldn't be a good idea.

Transpilers can solve this problem. I've been working on Babel to get caniuse-like browser support data to be smarter about handling what to transpile.

- "I want to support the last two versions of every browser, transpile/polyfill that for me."
- "I want to support these features, what browser support will I have?"



On Wed, Mar 25, 2015 at 12:32 PM, Tab Atkins Jr. <[hidden email]> wrote:

On Wed, Mar 25, 2015 at 12:06 PM, Andrea Giammarchi
<[hidden email]> wrote:
> For consistency sake I agree, but I come from a world where browsers also
> exposed unofficially APIs so that, as James mentioned already,
> `Array.prototype.includes` would have returned true and never worked.
>
> I wonder how reliable is `CSS.supports` not just in term of syntax, but
> actual usability.

You give it a full property declaration, and if the browser can parse
it successfully, it returns true/false. This allows for false
positives (a browser parsing a property but not actually supporting it
yet), but devs (rightfully) yell and scream at browsers whenever that
case (parse but no support) happens, so we do it very rarely, and only
ever by accident.

It's just a standardized version of the de facto standard CSS feature
test of "set the property on an element, and try to read it back; if
you get something, it's supported".

Because it's based on an objective and reliable criteria tied to
directly to actual support (successful parsing), it's reliable in
practice as a feature test. This differentiates it from the old
hasFeature() function, which was based on a map of feature strings to
bools stored in the browser, with no connection to the actual features
in question, and so was inevitably filled with lies and bitrot.

~TJ
_______________________________________________
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

Tab Atkins Jr.
On Wed, Mar 25, 2015 at 1:17 PM, James Kyle <[hidden email]> wrote:
> The reason `@supports` works in CSS is because of the limited language
> feature-set CSS has, but this wouldn't work in JavaScript.

No, it works because most of the time, whether or not something parses
is a sufficient proxy for "this is supported".  This isn't always
adequate - for example, you can't test whether a browser supports APNG
in CSS properties with this - but that's okay.

Similarly, a JS version would let you test for anything where parsing
is a proxy for support, like "function*(){...}" or "()=>{}".  It
wouldn't help you with things where parsing is successful whether the
feature is supported or not.

There's no good way to support those cases that parsing doesn't
address besides direct feature tests, or support tables.  Luckily,
both of these already exist in the ecosystem, so it's okay that we're
not solving them.

~TJ
_______________________________________________
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
What this sub-discussion of CSS `supports(..)` is reinforcing is what I said earlier: a capability to do feature tests in a direct, efficient, and non-hacky manner is valuable to some/many uses and use-cases, even with the recognition that it doesn't have to *perfectly* support all conceivable uses/use-cases/tests.

We should avoid a mindset that anything short of perfect isn't worth doing at all. Thankfully JS doesn't have such a design principle.

A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally or intentionally lie. But it *could* be better to some audiences than having no information. I personally would prefer to use it, even with its "risks", than trying a long recursive loop in a `try..catch` to imply if TCO was in effect.

Nevertheless, it's the least important kind of test being advocated for here, even though it seems to be getting all the attention. If that kind of test is a bone of contention, it should be the easiest to drop/ignore.

Moreover, to reduce the risk of bitrot on feature lookup tables (that `Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )` type of test.
_______________________________________________
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
It's not that it's imperfect. It's that it's useless in the real world.

We can already do shallow testing of APIs. Reflect.support doesn't help there, and in some ways (that I've outlined before) it is a regression.

```
if (!Array.prototype.includes) { ... }
if (!Reflect.supports("Array.prototype.includes")) { ... }
```

You also wouldn't do testing of syntax support at runtime, as you would effectively be duplicating the code.

```
var myFunc;
if (Reflect.supports("TCO")) {
  myFunc = recursiveImplementation;
} else {
  myFunc = nonRecursiveImplementation;
  // Why duplicate? You'd be saving yourself a lot of hassle by just transpiling to this
}
```

What's the alternative? To send down a file that tests for support and then sends it back to the server and then build the appropriate assets for that browser?

No, that'd be absurdly slow, and now you've already delegated to using a build tool.

- James Kyle



On Wed, Mar 25, 2015 at 1:44 PM, Kyle Simpson <[hidden email]> wrote:

What this sub-discussion of CSS `supports(..)` is reinforcing is what I said earlier: a capability to do feature tests in a direct, efficient, and non-hacky manner is valuable to some/many uses and use-cases, even with the recognition that it doesn't have to *perfectly* support all conceivable uses/use-cases/tests.

We should avoid a mindset that anything short of perfect isn't worth doing at all. Thankfully JS doesn't have such a design principle.

A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally or intentionally lie. But it *could* be better to some audiences than having no information. I personally would prefer to use it, even with its "risks", than trying a long recursive loop in a `try..catch` to imply if TCO was in effect.

Nevertheless, it's the least important kind of test being advocated for here, even though it seems to be getting all the attention. If that kind of test is a bone of contention, it should be the easiest to drop/ignore.

Moreover, to reduce the risk of bitrot on feature lookup tables (that `Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )` type of test.
_______________________________________________
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
> It's not that it's imperfect. It's that it's useless in the real world.

It's clear it's useless to you. It's not clear that it's useless to everyone. In fact, I for one definitely find it useful. No sense in continuing to argue over subjective opinion.


> We can already do shallow testing of APIs. Reflect.support doesn't help there, and in some ways (that I've outlined before) it is a regression.
>
> ```
> if (!Array.prototype.includes) { ... }
> if (!Reflect.supports("Array.prototype.includes")) { ... }
> ```

As I've repeatedly said, this proposed feature is not for those sorts of tests. It's for all the syntax tests that require `try..catch` + `Function` / `eval`. Please (re)read the rest of the thread.


> You also wouldn't do testing of syntax support at runtime

I already do. I fully intend to keep doing so.


> as you would effectively be duplicating the code.

Nope, not duplicating code. Maintaining code in original ES6+ authored form as well as transpiled form. They're both files that can be loaded by a browser. So my intent is to decide at runtime which one is appropriate, and only load one or the other.


> ...send down a file that tests for support and then sends it back to the server

Yep, absolutely. Bootstrapping.


> and then build the appropriate assets for that browser?

Of course not. It picks one of two already existing files.

_______________________________________________
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

Косыч Дед
 It's not that it's imperfect. It's that it's useless in the real world.
... 
What's the alternative? To send down a file that tests for support and then sends it back to the server and then build the appropriate assets for that browser?
 
Its possible in the AMD approach. Idk though if its useful.

The need in TCO detection is really debatable, but one might be using it, say, in two years from now to throw a _proper_ exception while running some crazy recursive code in an old browser.

NB: it would be practical only if feature detection possibility lands to a browser with (or even before) corresponding feature. And, imho, that's what Kyle Simpson meant, starting the thread: handy feature detection available _prior_ to feature implementation.

Two more off-topic cents:
If at any point we will 
  • have adjustable features, like disabling at some scope `eval`, `with`, `Function()` or using `global object`
  • or a new `stricter mode`
  • or choosing new Number representation
  • ... or whatever
it would be nice to be able to detect such state, without `try..catch` in a fast & semantic way.


_______________________________________________
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
Re: shallow testing

Yes you've said that, but this is exactly what `@supports` is in CSS. There was no way to do shallow testing so they added a way to do it.

Re: Bootstrapping

This is exactly my point, you're already using multiple builds and letting a transpiler handle it for you. Why would you opt for a worse solution than letting transpilers handle even more than you?

Here's my ideal situation:

For users who want targeted builds:
1. The transpiler handles building multiple files for various targeted environments.
  - Using a known set of feature support (similar to caniuse).
2. Server uses header information to send down the appropriate built file
  - Using the same known set of feature support.

For users who want a single build:
1. The transpiler builds a single file which supports every targeted environment
2. Server sends the same file for everyone.

Neither of these are perfect solutions, but they are a lot better than needing to make multiple requests just to determine what version of the site to serve.



On Wed, Mar 25, 2015 at 2:17 PM, Kyle Simpson <[hidden email]> wrote:

> It's not that it's imperfect. It's that it's useless in the real world.

It's clear it's useless to you. It's not clear that it's useless to everyone. In fact, I for one definitely find it useful. No sense in continuing to argue over subjective opinion.


> We can already do shallow testing of APIs. Reflect.support doesn't help there, and in some ways (that I've outlined before) it is a regression.
>
> ```
> if (!Array.prototype.includes) { ... }
> if (!Reflect.supports("Array.prototype.includes")) { ... }
> ```

As I've repeatedly said, this proposed feature is not for those sorts of tests. It's for all the syntax tests that require `try..catch` + `Function` / `eval`. Please (re)read the rest of the thread.


> You also wouldn't do testing of syntax support at runtime

I already do. I fully intend to keep doing so.


> as you would effectively be duplicating the code.

Nope, not duplicating code. Maintaining code in original ES6+ authored form as well as transpiled form. They're both files that can be loaded by a browser. So my intent is to decide at runtime which one is appropriate, and only load one or the other.


> ...send down a file that tests for support and then sends it back to the server

Yep, absolutely. Bootstrapping.


> and then build the appropriate assets for that browser?

Of course not. It picks one of two already existing files.

_______________________________________________
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
We're getting way afield with this whole transpilers thing. I'll indulge it for just this response, then I'll return my focus on this thread to the issue at hand: feature tests IN javascript.


> ...CSS. There was no way to do shallow testing so they added a way to do it.

As I have repeatedly said, the intent is not to be able to do new sorts of tests that are not currently possible.

I know perfectly well that I can do `if (Array.prototype.includes) ..` tests and I can also do `try { eval("(()=>{})") } catch..` tests. That's not new news to anyone here.

The intent is to take *only* the latter of those two and do it in a more efficient and less hacky way.


> Here's my ideal situation:

Your "ideal situation" means that if I want split builds (I do!), I have to maintain my transpiler's definitions and keep up to date on usage stats for me site to decide when I care about a certain browser or when I stop caring about it, and change my configurations accordingly. I know a lot of people think that way. I most definitely do not. Pretty "not ideal" to me.

I prefer an option where I can write and deploy code, and never touch it, or even the server/tools, again (if I don't need to), and it will just continue to work "forever". For awhile, tests will end up serving both files, but eventually, as browsers evolve, the tests will all result in only the *.es6.js files being served. To me, that's "ideal".

In short, I don't actually want to think *at all* about what browsers do what things. To whatever extent possible, I want feature tests to handle that entirely. I think browser versions are meaningless arbitrary marketing labels. caniuse data is, at best, amusement to me. I never make real decisions based on 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
The problem with that is you're still delegating to build tools and servers to solve the entire problem. As you said previously you would not opt for the pure-javascript solution:

```
if (Reflect.supports('TCO')) { /* recursive */ } else { /* not recursive */ }
```

So while I get the sentiment of "feature tests IN javascript", the problem (as you've said) is that your solution would not exist solely in your javascript.

In order for Reflect.supports to be practical it needs a build tool/server, but as soon as you introduce those better options are available.

I'm sorry that you'll have to think about it.



On Wed, Mar 25, 2015 at 3:14 PM, Kyle Simpson <[hidden email]> wrote:

We're getting way afield with this whole transpilers thing. I'll indulge it for just this response, then I'll return my focus on this thread to the issue at hand: feature tests IN javascript.


> ...CSS. There was no way to do shallow testing so they added a way to do it.

As I have repeatedly said, the intent is not to be able to do new sorts of tests that are not currently possible.

I know perfectly well that I can do `if (Array.prototype.includes) ..` tests and I can also do `try { eval("(()=>{})") } catch..` tests. That's not new news to anyone here.

The intent is to take *only* the latter of those two and do it in a more efficient and less hacky way.


> Here's my ideal situation:

Your "ideal situation" means that if I want split builds (I do!), I have to maintain my transpiler's definitions and keep up to date on usage stats for me site to decide when I care about a certain browser or when I stop caring about it, and change my configurations accordingly. I know a lot of people think that way. I most definitely do not. Pretty "not ideal" to me.

I prefer an option where I can write and deploy code, and never touch it, or even the server/tools, again (if I don't need to), and it will just continue to work "forever". For awhile, tests will end up serving both files, but eventually, as browsers evolve, the tests will all result in only the *.es6.js files being served. To me, that's "ideal".

In short, I don't actually want to think *at all* about what browsers do what things. To whatever extent possible, I want feature tests to handle that entirely. I think browser versions are meaningless arbitrary marketing labels. caniuse data is, at best, amusement to me. I never make real decisions based on it.
_______________________________________________
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

liorean

As I see it, what might be more desireable than a straight shallow feature test or feature support reporting feature would be an official versioned test library, possibly including tests of pure internals, and a new standard api for asking the engine for the results it gets for running a certain test or set of tests. The engine could then either have its results collected at build time and cashed results for that particular build built into the api, or allow the user to require the result of getting the test and executing it live, with the issues that comes with that. One possible result, except the obvious success and fail, is of course that a certain test didn't exist at the time of the build and thus not tested.

Of course, the earliest something like that could be in the language would be ECMAScript 7...


_______________________________________________
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
This exists: http://test262.ecmascript.org



On Wed, Mar 25, 2015 at 8:12 PM, liorean <[hidden email]> wrote:

As I see it, what might be more desireable than a straight shallow feature test or feature support reporting feature would be an official versioned test library, possibly including tests of pure internals, and a new standard api for asking the engine for the results it gets for running a certain test or set of tests. The engine could then either have its results collected at build time and cashed results for that particular build built into the api, or allow the user to require the result of getting the test and executing it live, with the issues that comes with that. One possible result, except the obvious success and fail, is of course that a certain test didn't exist at the time of the build and thus not tested.

Of course, the earliest something like that could be in the language would be ECMAScript 7...



_______________________________________________
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
I don't believe test262 can yet be run in a browser (only directly against a browser engine), nor run in ES3 browsers (so that shimmed engines can be tested) so that doesn't yet solve my use cases, although I can't speak for Kyle.

On Wed, Mar 25, 2015 at 9:32 PM, James Kyle <[hidden email]> wrote:
This exists: http://test262.ecmascript.org



On Wed, Mar 25, 2015 at 8:12 PM, liorean <[hidden email]> wrote:

As I see it, what might be more desireable than a straight shallow feature test or feature support reporting feature would be an official versioned test library, possibly including tests of pure internals, and a new standard api for asking the engine for the results it gets for running a certain test or set of tests. The engine could then either have its results collected at build time and cashed results for that particular build built into the api, or allow the user to require the result of getting the test and executing it live, with the issues that comes with that. One possible result, except the obvious success and fail, is of course that a certain test didn't exist at the time of the build and thus not tested.

Of course, the earliest something like that could be in the language would be ECMAScript 7...



_______________________________________________
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

Allen Wirfs-Brock
In reply to this post by Kyle Simpson

> On Mar 22, 2015, at 2: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.

I’m pretty skeptical about including this sort of feature testing feature as part of standard ECMAScript.  Here are some of the reasons:

ECMAScript doesn’t include the concept of language subsets/supersets (other than the Annex B features).  An conforming implementation of a Ecma TC39 standard is  expected to implement all of the features of current standard. Given that perspective, it isn’t clear why we would want to  provide a feature that was specificatlly design to enable non-conforming implementations.   test262 is TC39’s support for testing the standards conformance of an implementation.

This sort  of feature testing is inherently a short term need. Within a few years, all implementations will support all major features, so work that does into incorporating specific feature detection into the ES standard (for example defining something like Symbol.arrowFunction) would be throw-away work that within in few years would just be legacy baggage that could never be removed from the language.  For example, I’m sure nobody today has a need to test Reflect.supports(Symbol.functionExpression) or Reflect.supports(Symbol.tryCatch).

On the other hand, a feature such as Reflect.parse which has other uses but which also has a potential applicability for feature detection seems reasonable.

Allen

_______________________________________________
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
> 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.



_______________________________________________
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

Bill Frantz
On 3/26/15 at 8:51 AM, [hidden email] (Kyle Simpson) wrote:

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

I don't see a real need for high performance in these tests.
AFAICS, they occur once, probably at load time. A smart JS
implementation might even parse the Reflect.parse() string at
the same time it is parsing the main set of JS code. As such,
the extra overhead for CPU and GC will probably be swamped by
the communication CPU and transmission times.

Not using eval makes it more likely that you will be able to
perform the tests in "safe" subsets of JS.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos,
CA 95032

_______________________________________________
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
Without the direct feature test API I'm suggesting (or something like it), how will someone feature test the two new (proposed for ES7) `export` forms, for example?

https://github.com/leebyron/ecmascript-more-export-from

I'm not strongly opposed to going the `Reflect.parse(..)` route for feature-testing (certainly more preferable than `eval` / `Function`), except I'm concerned that:

1. it will offer no reasonable path in the future for answering the "hard" tests, like TCO would have been. Would `Reflect.parse( Symbol.TCO )` be too janky of a hack for such things?
2. engines won't be able to tell (static analysis?) that the parse tree isn't needed and not wasting that memory for GC to clean up.

The advantage of an API that doesn't return anything but `true` / `false` means the engine knows it doesn't need to keep the tree around and send it into JS-land. I don't know if there's any internal processing benefits, but it certainly seems there's memory benefits.


> I don't see a real need for high performance in these tests

High performance? No.

But, if these feature tests slow down an app in the most critical of its critical paths (the initial load) to the point where people can't use the feature tests in the way I've proposed, then the "solution" is moot.

I *could* load up an entire parser written in JS and use it to parse syntax strings. That's *a* solution. But it's not a *viable* solution because it's way too slow for the purpose of feature tests during a split load.

So it should be noted that the proposal does imply that whatever solution we come up with, it has to be reasonable in performance (certainly much better than `eval` / `Function` or a full JS parser loaded separately).
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
12