[DRAFT] Bump minimum browser versions

[sbc100]

This change bumps out minimum supported browser versions just enough so we can drop support for output transpilation via babel.

chrome: 74 -> 85
firefox: 68 -> 79
safari: 12.2 -> 14.0

This also means we always support the MUTABLE_GLOBALS and PROMISE_ANY features, since its no longer possible to target engines without them.

[sbc100]

@dschuff @kripken @brendandahl @juj WDYT?

We could completely remove out babel dependency here..

[kripken]

If feedback from users is positive, sgtm. This still gives us over 5 years of backwards compatibility iiuc.

[juj]

I am all for bumping up the minimum browser versions, I think it is a due time.

However, whenever I read PRs like this, it does make me feel like we are erasing a lot of valuable information that we worked really hard to embed to the repository.

Like, presumably, here we have encoded the minimum browser versions that are required for ES6 support. Removing Chrome from the list could make a reader go "why is this check arbitrarily missing Chrome?"

And the feature matrix erases the version info from the many features, that are now given.

It seems like it would be valuable to keep carrying the information, e.g. in comments, so that when cross-referencing between features and versions, one can still positively confirm "ok, the authors have checked sign-ext/threads/etc. here and it can be assumed", rather than the reader possibly needing to go "this feature x/browser version y is not listed here at all, so by omission we should assume that they thought through it."

But we do have places in code where we haven't thought about minimum Node.js version for example, and we could not assume by omission that it must work since it is omitted.

Finally, I wonder if it is a good idea to drop Babel support? I mean, right now we would indeed evolve to a situation where Babel would not be needed.. but is that the case still in the future? E.g. two years from now, we might find some nice new syntax that we think we want to take advantage of, and Babel could have gained transpilation support to it - but we dropped the whole Babel thing, and would need to rebuild it from scratch again in order to enable transpilation?

I.e. do we think that we will never be using Babel again? Or even if after bumping versions now, we won't, but maybe we might be using it again in the future? LGTM either way, just wanted to think whether we are creating friction to reinstating Babel if necessary again in the future.

[sbc100]

Like, presumably, here we have encoded the minimum browser versions that are required for ES6 support. Removing Chrome from the list could make a reader go "why is this check arbitrarily missing Chrome?"

Yes, that does looks odd. I think we should remove that duplication now: #26745

[sbc100]

It seems like it would be valuable to keep carrying the information, e.g. in comments, so that when cross-referencing between features and versions, one can still positively confirm "ok, the authors have checked sign-ext/threads/etc. here and it can be assumed", rather than the reader possibly needing to go "this feature x/browser version y is not listed here at all, so by omission we should assume that they thought through it."

But we do have places in code where we haven't thought about minimum Node.js version for example, and we could not assume by omission that it must work since it is omitted.

Yes, I agree, keeping this information around, if only in comments would be usefull. I will look into that before landing this.

[sbc100]

I.e. do we think that we will never be using Babel again? Or even if after bumping versions now, we won't, but maybe we might be using it again in the future?

Yes, I also considered this. Its highly likely the we could need a transpiler again once day (although I don't any any immediate plans to use new JS features).

However, I think when that time comes we would probably want to reconsider using closure-compiler (or some other tool) transplantation (I think they have addressed the core issue from before) and avoid the babel dependencies (which is pretty huge IIRC). So I decided I'd rather not keep babel dependency around in a dormant state.. since that can also lead to confusion if folks see it in the code but is never ever used. We also have git history of course.

[juj]

Yeah, that makes sense. LGTM