Supporting feature tests directly

Kyle Simpson getify at gmail.com
Wed Mar 25 22:14:18 UTC 2015


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.


More information about the es-discuss mailing list