Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make list of supported browsers be the list of supported browsers #133

Closed
Pike opened this issue Jan 24, 2018 · 18 comments
Closed

Make list of supported browsers be the list of supported browsers #133

Pike opened this issue Jan 24, 2018 · 18 comments

Comments

@Pike
Copy link
Contributor

Pike commented Jan 24, 2018

Right now, we're claiming to support:

'browsers': [
'>1%',
'last 4 versions',
'Firefox ESR',
'not ie < 9'
]

The option about market share is completely useless, per the algorithm, this is the last 4 versions of any browser, or a Firefox ESR, but not old IEs.

If we wanted to reduce the list of supported browsers according to market share, it'd need to be a

'not <1%'

but that excludes any version of Firefox or IE that by itself doesn't have that market share, including ESR, http://browserl.ist/?q=last+4+versions%2C+Firefox+ESR%2C+not+ie+%3C+9%2C+not+%3C1%25.

My suspicion is that our list was intended to be "of all the browsers with at least 1% market share, support the last 4 versions, IE aside". Such a query doesn't exist, sadly.

The only way we could emulate that is to manually maintain the list of browsers we support, and then restrict to the last 4 versions, or so.

@stasm
Copy link
Contributor

stasm commented Jan 24, 2018

According to https://caniuse.com/usage-table there aren't many browser versions above 1% market share. For instance, only Firefox 57 meets the criteria and I doubt we need any transpilation at all to ensure compatibility with it. Maybe there's something more forgiving than not <1%?

How about last 4 versions, Firefox ESR, not ie < 9, not < 0.1%? It's at 91.28% global coverage vs. 91.63% currently:

last 4 versions, Firefox ESR, not ie < 9, not < 0.1%

@stasm
Copy link
Contributor

stasm commented Jan 24, 2018

@zbraniecki, @mathjazz, @adngdb — do you have an opinion about this? What's the best reasonable set of browser versions that would also make sense for Pontoon?

@zbraniecki
Copy link
Collaborator

I'm against linking our support range to React's. I believe we should support evergreens. Period. We're a 0.5 library, by 1.0 we hopefully will only have evergreens on the market, and if we need to support a single outlier (IE11) - then let's weight the cost/reward for it individually.

Supporting Safari 9.1 is completely out of scope and the cost seems disproportional to any potential value to me.

@mathjazz
Copy link

Pontoon's primary target audience is Mozilla, so I don't have a strong opinion on this.

@stasm
Copy link
Contributor

stasm commented Jan 26, 2018

OK, how about this then: last 2 versions, not < 0.1%, Firefox ESR? The global coverage is at 86.24% and most of these browsers are pretty modern.

obraz

@Pike
Copy link
Contributor Author

Pike commented Jan 26, 2018

Chrome for Android release version is 64. I'm just not impressed by the data, and it feels wonky that we're trying to be driven by that data.

@zbraniecki
Copy link
Collaborator

IE10 - released on September 4, 2012...

I question the applicability of this data onto our customer or potential customer population. Major web assets don't support IE10 and IE11. We're a pre-1.0 modern client side library. Major apps like ZenDesk stopped supporting IE10 in 2016.
I believe that there are still users on IE10, but I expect them to use the Web very very differently from other people. Specific old websites that work for their needs. Chances that one of those ie10-enabled websites will want to switch to Fluent is 0.

Secondly, I question the data source. StatCounter is notoriously listed as the very worst data source for browsers marketshare. I'd prefer not to sink us into supporting esoteric browsers because StatCounter overrepresents them.

In short - as since the beginning of Fluent project I believe we should only support evergreens and IE11, and I'd like us to stop supporting IE11 asap.

Salesforce stopped supporting IE11 in December 2017 [0]. I believe we can expect IE11 to not be supported by many major players by the time we release Fluent 1.0 and I'd like us to consider dropping it then.

[0] https://releasenotes.docs.salesforce.com/en-us/summer16/release-notes/rn_mobile_s1_newfeat_win8_ie11_eos_warning.htm

@Pike
Copy link
Contributor Author

Pike commented Jan 26, 2018

Our conversations about updates in Firefox for fluent have demonstrated that we shouldn't build too many arguments on our version number, and make too strong assumptions on when we'll actually have to declare 1.0.

I don't see IE11 being on a strong decline.

@stasm
Copy link
Contributor

stasm commented May 31, 2018

5 months later, this has become a pressing issue. We're using async generator functions in Gecko's L10nRegistry which supplies resources to apps localized with fluent-dom and (soon) fluent-react. Having to support old browsers has real cost in terms of developer resources and our ability to easily upgrade fluent in deployed projects.

I'd like to drop IE support ASAP. I reached out to Common Voice, Test Pilot and Screenshots to ask what their browser support matrix was. Common Voice explicitly doesn't support IE. I tested Test Pilot and it doesn't work in IE 11; I don't know yet if that's intended. Screenshots works in IE and I'm waiting for their reply.

Transpilation for compatibility can be thought of as a layered process and can roughly be represented as the following 4 stages:

  • Async generators can be transpiled to a simple _AsyncGenerator wrapper.
  • Async iteration can be expressed with async functions and a loop calling await iterator.next().
  • Async functions can be expressed as generator functions wrapped in a simple _asyncToGenerator.
  • Generators can only be transpiled using the regeneratorRuntime.

By dropping IE, we can focus on browsers which support sync generators (browerslist):

Firefox >= 26,
FirefoxAndroid >= 26,
Chrome >= 39,
ChromeAndroid >= 39,
Edge >= 13,
Safari >= 10,
iOS >= 10

We can also go further and require browers which support async functions (browserslist):

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

This would help reduce the size of compat.js builds. In the example of cached-iterable, the build goes down from 10 KB to 7 KB.

@Pike
Copy link
Contributor Author

Pike commented May 31, 2018

Interesting localization problem:

From https://www.udacity.com/tech-requirements:

An up-to-date version of Chrome is strongly recommended.
We also support the latest versions of Firefox, Safari, Opera and Microsoft Edge.
At this time, mobile browsers are not fully supported, but you can download our iOS or Android apps to access courses on your mobile device.

From https://de.udacity.com/technische-voraussetzungen:

Eine aktuelle Version von Chrome, Firefox oder Safari wird empfohlen.
Wir unterstützen aber auch Internet Explorer 9 und aktuellere Versionen.
Zurzeit werden Mobile Browser nicht unterstützt, aber du kannst dir unsere iOS oder Android Apps downloaden, um dir die Kurse unterwegs anzusehen.

Errr. @hkasemir ?

@stasm
Copy link
Contributor

stasm commented May 31, 2018

I really hope this is an outdated translation :)

@zbraniecki
Copy link
Collaborator

I'd be incredibly happy to drop IE11. Looking at https://caniuse.com/#search=async it seems like we should be able to set the bar on "async functions" and I'd like us to do that.

@hkasemir
Copy link
Contributor

hkasemir commented Jun 1, 2018

hmm, I don't speak German, but I'll ask our website team about it

@stasm
Copy link
Contributor

stasm commented Jun 5, 2018

An update on the browser support of Mozilla websites which use Fluent:

@stasm
Copy link
Contributor

stasm commented Jun 6, 2018

@hkasemir Would dropping IE11 and requiring the following browser versions work for Udacity?

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

@hkasemir
Copy link
Contributor

hkasemir commented Jun 7, 2018

hey! I think that would be fine :) I brought up the mismatched translations with our marketing dev team, and they are working on updating our localized sites to match the US one. Based on that, I think we should be safe with that list of browsers.

@stasm
Copy link
Contributor

stasm commented Jun 7, 2018

A correction to the list of browsers above. It looks like async functions shipped in iOS Safari 10.3. For clarity, I've also removed the Android versions of Firefox and Chrome, which ship with the same JS features support as their desktop counterparts.

Firefox >= 52
Chrome >= 55
Edge >= 15
Safari >= 10.1
iOS >= 10.3

@stasm
Copy link
Contributor

stasm commented Jun 14, 2018

I've been keeping track of my communications with projects using Fluent in #133 (comment). Today I was able to confirm the last project on the list. Here's the complete list again:

I'm going to open a PR to change the browser support matrix for all fluent.js projects to the following one (browserlist query):

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

Thanks to everyone for taking part in this discussion!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants