IE11 Support and use of for-of

[dogoku]

I've written and rewritten this issue more times than I'd like to admit, all because I don't want to sound ungrateful for this otherwise amazing project. I'll try to keep this short, as none of us really wants to support IE, but some of us don't have a choice...

This issue is related to #79 but it's more of a "feature" request, rather than a bug report.

IE11 requires a significant amount of polyfills to run even the compatibility bundle, thanks to primarily for...of, which in order to be transpiled safely, depend on the use of Symbol.iterator, which requires a babel-polyfill (50kb+ gzipped).

By not using for...of, you will not only decrease the size of your transpiled bundle, but also significantly reducing the number of polyfills IE11 requires to load. In most cases, for...of only saves 2/3 lines of code compared to other loop constructs, but those 2 lines are dramatically offset by the size of the transpiled code and polyfills.

I know this is a big thing to ask, but is not using for...of something you would consider for this project?

Thanks for reading this far and thank everyone on the team for this amazing project.

[zbraniecki]

Hi @dogoku . The decision will be up to @stasm, but I'll state why I believe this would not really work for you:

It may look like it's about for...of, but it's so much more. With the approach we hold today, we basically support delayed evergreens. That means that our target is moving. Today we do for...of, in a month we use async generators and in half a year maybe decorators or private methods.
Getting just for...of would only shift the painpoint to another thing IE11 does not support.

I understand that you're in a position where you need to support IE11, and the size of the polyfill is scary. I'm wondering if there is a simpler babel polyfill that doesn't try to be pixel perfect with Symbols, but instead does the basics right which should be enough for our case?

[dogoku]

Thanks for the reply @zbraniecki. Like I said, I know how big of a change it would be to stop using modern features of the langauge, just to support IE11.

I isolated for...of as an extreme case where using modern features comes with a significant disadvantage for legacy browsers, which far outweighs its benefits.

We have played around with the compatibility build of fluent-web, replacing babel-preset-2015 with babel-present-env and even specifically loading only the required polyfills from core-js, but that still only dropped the size of polyfills to 27kb.

We even tried to switch to buble for transpiling, which has a "dangerous" transform for the for-of, however, buble does not support as many features as babel, at which point is seemed like a lost cause to try and switch to it.

In any case, we completely understand your decision and do not wish to waste any more of your time, so I am more than happy to close this issue, given @stasm has the same view as you.

[zbraniecki]

We even tried to switch to buble for transpiling, which has a "dangerous" transform for the for-of, however, buble does not support as many features as babel, at which point is seemed like a lost cause to try and switch to it.

I think my basic hope is that someone already hit this problem (of babel using Symbol to compile for...of loops) and wrote babel plugin to do without them. But I didn't find one yet :)

[zbraniecki]

Let's not close it. Even if we're not ready to do this, we may want to use your ticket to document the recommended polyfilling for IE11, and I hope we can do better than 50k.

[stasm]

Thanks for filing this issue, @dogoku, and being very thoughtful in your comments. And thanks, @zbraniecki, for summarizing the position which I also share. Going all-in on modern JS allows us to avoid hurdles of remembering which features are okay to use and which aren't—now and in the future.

I counted 24 occurrences of for…of in all of fluent-web. I wonder if it would be a lot of work to write and maintain a small patch/branch which replaces them with other forms of iterations for your needs. A custom Babel plugin might also be a way forward. I really hope that supporting IE11 is becoming a special request-type of requirement for web apps so I'm trying to think in terms of special request-typed solutions.

[dogoku]

@stasm We actually attempted to replace all the for...of, however some cases are not as straightforward and given our lack of knowledge of the project and not knowing what other dependencies might appear in the future, we decided against that approach in the end.

Perhaps a custom babel plugin, might be the path of least resistance. As long as no one is manipulating the collection size inside a for...of loop, using a less safe transform that does not depend on iterators, should be possible.

[stasm]

After a long discussion in #133 we settled on the following list of supported browsers for the compat builds:

"Firefox >= 52",
"FirefoxAndroid >= 52",
"Chrome >= 55",
"ChromeAndroid >= 55",
"Edge >= 15",
"Safari >= 10.1",
"iOS >= 10.3",

These are all the browsers which natively support async functions. IE11 is not, of course, one of them. I realize that this decision will make it harder for some projects to use Fluent. Supporting these old browsers came with an engineering cost which was too significant for our small team. In particular, I got stung more than once by regeneratorRuntime being declared as a global in compat builds. Choosing to support only the browser on the list above solves this problem (and many other) completely: by removing the need to even use regeneratorRuntime in the first place.

The change landed in #225. It will go live in next releases of each package in the fluent family. I'm closing this issue: we officially don't support IE 11 now.