Supporting feature tests directly

James Kyle me at thejameskyle.com
Wed Mar 25 21:55:56 UTC 2015


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 <getify at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150325/ee99d327/attachment.html>


More information about the es-discuss mailing list