Supporting feature tests directly

James Kyle me at thejameskyle.com
Wed Mar 25 23:06:39 UTC 2015


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 <getify at gmail.com> 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
> 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/be2a8bb3/attachment.html>


More information about the es-discuss mailing list