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
What does our browser support matrix look like? #1180
Comments
Looks like json2 is probably not needed for example |
This may also help #1054. |
@mekarpeles any ideas on how to think about this? |
Ideas but will need some time to gather; thx for reminder! |
Most modern browsers have JSON support, so thus do not run JavaScript on browsers which do not have JSON support. This begins attempt to define and limit our JavaScript to browsers we can reliably run JS on. Fixes: internetarchive#1180
Most modern browsers have JSON support, so thus do not run JavaScript on browsers which do not have JSON support. This begins attempt to define and limit our JavaScript to browsers we can reliably run JS on. Fixes: internetarchive#1180
@mekarpeles i plan to drop support for any browser with less than 1-5% traffic. Can you get that information? |
I typically drop browsers with < 2% traffic, but in the case of this project's global scope that may be difficult. I'd be interested to know how many versions back we're seeing used and filtered by country. |
In scanning through the JS, I noticed an |
Yeh this is one of the reasons why I brought this up. There is modern JS, strict JS, old JS... vendor prefixes galore and even IE5 hacks! Thus knowing this will help drive a bunch of things. |
Okay.. I want to make progress on this, so in lieu of traffic information I'm going to propose we follow Wikipedia's browser support matrix: https://www.mediawiki.org/wiki/Compatibility#Modern_(Grade_A) Patch to follow. |
We will use Wikipedia's browser support matrix as it is based on traffic for Wikipedia. Given Wikipedia's traffic, I think we can be confident this will also be suitable for OpenLibrary. Add a transpiler to allow us to adopt ES6 syntax in the codebase. The addition of the babel loader and browserslistrc ensures that the code we ship to end users will always be suitable syntax for those users. Note we must still be careful when adopting ES6/7/8 functions as no polyfills are provided, so care must still be taken by frontend developers working with this codebase. We can add protection via eslint later if that becomes a problem. A single variable is changed to a `const` which does not appear in the built assets in static/build to demonstrate this is working. note the minor bundlesize update (but remember we just shaved 5kb off!) Fixes: internetarchive#1180
We will use Wikipedia's browser support matrix as it is based on traffic for Wikipedia. Given Wikipedia's traffic, I think we can be confident this will also be suitable for OpenLibrary. Add a transpiler to allow us to adopt ES6 syntax in the codebase. The addition of the babel loader and browserslistrc ensures that the code we ship to end users will always be suitable syntax for those users. Note we must still be careful when adopting ES6/7/8 functions as no polyfills are provided, so care must still be taken by frontend developers working with this codebase. We can add protection via eslint later if that becomes a problem. A single variable is changed to a `const` which does not appear in the built assets in static/build to demonstrate this is working. note the minor bundlesize update (but remember we just shaved 5kb off!) Fixes: internetarchive#1180
It's unclear which browsers we need to support.
Ideally, we should base this on data showing what browsers are users are using. Do we have this information?
If not, we should probably follow a browser matrix similar to other projects e.g. MediaWiki
Once defined we can likely through away a lot of CSS code (and maybe JS).
The text was updated successfully, but these errors were encountered: