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

Maintain browser compatibility #411

Open
arildm opened this issue Nov 29, 2024 · 2 comments
Open

Maintain browser compatibility #411

arildm opened this issue Nov 29, 2024 · 2 comments
Labels
maintenance Oiling the gears, preventing future problems question

Comments

@arildm
Copy link
Member

arildm commented Nov 29, 2024

Do we need to support web browsers lacking modern language features?

Some users may be unable or unwilling to switch/update their browsers.

Offering a wider support requires refraining from new language features or adding transpilation or polyfills.

@arildm
Copy link
Member Author

arildm commented Nov 29, 2024

I did a little case study. We have been recording analytics with Matomo since March 2024, so I took a look at the browser versions used at our Korp site since then. Then I looked up which browsers support the JS ?? operator at Can I Use (inspired by the discussion in #410) and summed up the number of unique visitors from browsers with or without this feature:

Supports ?? Unique visitors % Comment
Yes 24365 96.1%
No 2 0.0% Firefox 49.0, Mobile Safari 4.0
? 996 3.9% Not listed at caniuse.com

Among the browsers not listed at caniuse.com, the most used ones are Facebook (1.9%), Brave (0.8%) and Google Search App (0.6%).

@janiemi
Copy link
Contributor

janiemi commented Dec 3, 2024

@arildm, thanks for the statistics. Based on them, it would appear pretty safe to use the ?? operator. I haven’t looked at our logs from that point of view, but I’d expect the result to be similar.

Now that I investigated the issue a bit, it seems to be even more complicated than I thought, as browsers don’t in general implement a certain ES version but instead individual features. In principle, you’d then need to check the support for each feature. However, could you in practice assume that at least most of the core features of an ES version are implemented in most relatively recent browsers? If so, would ES2020 be a reasonable choice? (??= seems to have been introduced in ES2021, but I personally find the ?? and ?. of ES2020 much more important.)

I see that you’ve converted a large part of the Korp frontend codebase to TypeScript. Do you also intend to convert the rest of the code to TypeScript? If so, I’m wondering if or how that will affect the issue of browser compatibility, as you then have a certain (minimum) version for TypeScript having certain features and as you can specify the ES version the code is transpiled to. Based on package.json, you’d seem to be using TypeScript version ^4.0.0, that is, something between 4.0.0 and 4.9.5. Am I right? And do I understand correctly that "target": "es6" in tsconfig.json means that the TypeScript transpilation target is ES6?

Should we then in fact stick to ES6 also for JavaScript code as long as there is some around? As far as I can see, the JS code in Korp didn’t use ?? before fixing #410.

Previously, Korp used to use Babel to support older browsers while allowing more modern code. I’m wondering why you stopped using it. Did it complicate the build process? Or did it add unnecessary or slow code? Or do the majority of browsers today support the features used in the code well enough? Or was it because TypeScript is the way to go? And no, I don’t wish Babel back; I’m just wondering, as the commit 65e94eb8 removing it doesn’t mention any rationale for the removal.

By the way, doc/frontend_devel.md still says: “We use Babel to transform modern Javascript to something that works in all browsers.” I suppose that should also be removed or edited.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Oiling the gears, preventing future problems question
Projects
None yet
Development

No branches or pull requests

2 participants