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