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
