browserslist VS caniuse

Yeah, supporting iOS 12 in 2025 is odd. I was investigating browser support levels just recently for a library and also settled on iOS 16 as a reasonable level.

For reference, iOS 12.x and below are used 0.33% globally https://browsersl.ist/#q=safari+%3C+13+or+ios+%3C+13. Selecting iOS 16 would still exclude less than 1% globally https://browsersl.ist/#q=safari+%3C+16+or+ios+%3C+16. In both cases the vast majority would be older iOS which is unfortunate because I assume they're on older devices with no upgrade path, but you have to decide on the transpile /polyfill cutoff at some point and browser support has an extremely long tail.

a browser targeted script in lib/ with the original ES Module exports, leveraging a browserslist query for which browser features to transpile support for

This plugin automatically converts modern JavaScript and adds necessary polyfills based on Browserlist-targets using Babel.

For a production build, you are likely using Browserslist, by default Vite targets browsers that support native ES Modules, native ESM dynamic import, and import.meta.

Not these days, where most people are using evergreen browsers and iOS users upgrade very quickly.

Take a look at the defaults for browserslist, for example:

https://browsersl.ist/#q=defaults

It just barely supports Safari 15, on iOS only, and that’s likely to go away imminently because it’s under 1% usage.

browserslist

We compile JS only for modern browsers. The list of default browsers in Next can be overridden in your browserslist.

In the latest versions of Next.js, targeting specific browsers or features is a breeze using the Browserslist configuration in your package.json file. The latest version of Next.js (v13) uses the following configuration by default:

For a more general answer to browser support, check out https://github.com/browserslist/browserslist. That seems to be standard tool to help you with that.

(I submitted a PR for caniuse a few days ago :-) https://github.com/Fyrd/caniuse/pull/7523 )

Off-topic, but, Safari seems to be the only browser that doesn't support Temporal yet. It looks like the only blocker for adopting it on web.

https://caniuse.com/?search=Temporal

Browser support varies. Use caniuse.com before committing. For features you must have everywhere, polyfills exist. For features that gracefully degrade, feature detect with if ("foo" in window) and ship the better experience to capable browsers.

Last time I checked caniuse.com (early 2026), AVIF support looks like:

To prevent these situations, you can use Can I Use before adding cutting-edge features, and you should always provide a fallback style.

Totally fair question. I've actually been a longtime Gecko/Firefox user myself, so this one stings a bit.

The short answer: Firefox doesn't support the File System Access API (https://caniuse.com/?search=File+System+Access+API).

We made a deliberate decision to go client-first. Video editing happens entirely in your browser without us uploading your entire footage on our end. No bandwidth costs for you, no storing your raw video on our servers. The File System Access API is what makes that possible, and unfortunately Firefox just doesn't have it yet.

It's not a forever thing though. For cloud-based projects where files live on our end anyway, Firefox support is very much on the roadmap. But for the local-first editing flow, our hands are a bit tied until Mozilla ships it.

Hope that makes sense, and fingers crossed Firefox adds support soon!

To make it perfectly clear, no browser support outside Appleworld

https://caniuse.com/?search=HEIC

I mostly am a DSLR photographer but for the occasional iPhone shot

https://mastodon.social/@UP8/115740936297822037

I use Photoshop. (Where's Cindy when I need her?)

> you end up with no clear picture of which browsers support these records to which end.

> Unfortunately even the otherwise ever so useful https://caniuse.com/ does not provide that information

Not quite the same, but Cloudflare's statistics show that 8.1% of all DNS requests to its public resolver are for HTTPS RRs [0], and the statistics on the authoritative DNS server that I run [1] show that only 1.11% of requests were for an HTTPS RR [1].

[0]: https://radar.cloudflare.com/dns#dns-query-type

[1]: https://ns.maxchernoff.ca/