Browser Support Update

[Joolyan]

Does the browser support page require updating for swup 4?

The current page advises of "full support" for Safari 9+, however Safari 12.1 doesn't support JavaScript operators 'Optional chaining' (?.) or 'Nullish coalescing' (??) which I believe is used by the latest version of swup.

Issue #822 was fixed is swup 4.4.3 to provide support for Safari <= 13.1. May be this works when swup is installed via npm and the JavaScript is transpiled to provide support for Safari 12.1 and not installed via https://unpkg.com/swup@4

[daun]

Looks like the page indeed needs updating! Thanks for pointing that out. The current maintainers are still in the habit of transpiling their projects and the browser support page was created on user request, so this wasn‘t (isn‘t) very high on our list of priorities. I can imagine it‘s also not easy to figure out reliably in the first place.

Would you care to submit a PR to the docs repo with what you found about Safari support?

[Joolyan]

Thanks. I wasn't sure if it was my error. I only discovered the issue whilst testing on an old MacBook with Safari 12.1.2

Happy to help if I can, however I've never submitted a PR before. I'll first need to read the GitHub docs for PR's.

[daun]

This is interesting. Looks like I'm halfway down the rabbit hole 🤠 There seem to be two very useful eslint plugins for measuring browser compatibility as well as syntax compatibility.

Regarding browser APIs, the updated list seems to be:

• Chrome 66
• Firefox 60
• Edge 16
• Safari 13
• iOS 13

Syntax compatibility is a bit harder to measure, currently working on a way of linting the dist folder...

[daun]

Turns out this can be automated! I've created a separate ESLint config that scans the dist folder against compatibility data. With that, the new compatibility table looks something like below. @Joolyan If you come around to it and/or feel like doing it, that would be the up-to-date information to include in the PR. If not, no problem, we can also create the PR ourselves.

• Chrome 80
• Safari 13.1
• iOS 13.4
• Firefox 74
• Edge 80

[Joolyan]

That's very impressive! I would never have been able to do anything even close to this.

The Browser support page already advises that polyfills can be used to improve support, so the only thing I would add is to mention that bundling swup with tools like Parcel can also improve support for earlier browsers.

I will read up on how PR's work, but I think you've already done the hard work on this one. Many thanks.

[daun]

We already had the ESLint stuff set up, so it was mostly looking for the right combination of plugins :) I like that suggestion! It's probably also worth mentioning that most of these tools make use of browserslist and that the correct browserslist config is essential in determining the baseline to which the existing code is transpiled to.

[daun]

@Joolyan We've updated the Browser Support page of the docs, if you're curious :) Thanks for suggesting the overdue update!

[Joolyan]

Wow! That's what I call great support. Thanks.

The advice "plugins may differ in the list of supported browsers" could be a little concerning for some users. Moving forward it would be great if all core plugins (excluding third-party plugins) offered the same browser support as swup itself, unless advised otherwise.

My own site uses the body-class-plugin, debug-plugin, preload-plugin and the scroll-plugin, so testing each plugin may add unnecessary concerns for some users. I haven't found any issues myself and was hoping these core plugins provided the same browser support as swup itself.

My own user experience of swup has been great. The only other issue relates to the slide-theme and deprecated dependencies #34.

[daun]

Gotcha. That's great feedback. In theory, they should have the same browser support in terms of syntax as the core and the plugins share the bundler and build setup. What's a bit harder to check is the browser APIs across all plugins. Not sure how to do that across twenty repositories without losing our minds 🤪 But hey, it's open source! If you think it's worth checking the support for the plugins you use most, we certainly appreciate a helping hand.

[Joolyan]

Reading the issue 'Create ESLint config for checking browser compatibility #872' you created, provides a good starting point. I may not know what I'm talking about, but the process could be simplified as you already have a "compatibility table" for swup itself. If the plugin passes, it's labelled as a "core plugin" so you can state that swup and all core plugins have the same browser compatibility. It would overcomplicate the issue to provide difference compatibility tables for each plugin. Just a thought?

[daun]

It's a bit more complicated, unfortunately. Each plugin has its own repository, so we'd still have to install the new ESLint config into each plugin and tweak the list of browsers until everything passes. That's probably half a day's worth of work, and pretty boring work to begin with 🤠 We might come around to it at some point, but it's not a great priority at the moment – unless someone else chooses to give this a go.

[Joolyan]

"tweak the list of browsers until everything passes" - wouldn't this reduce swup's browser support to the requirements of the worst supported plugin, even if the plugin has relatively few users? As you said, most should have the same browser support in terms of syntax as the core. Only the plugins that fail the lint:compat test are an issue and the solution may be to update the plugin rather than reduce browser support for all.

I agree this is not a priority. You have already significantly improved the swup documentation. Thanks again.

[daun]

wouldn't this reduce swup's browser support to the requirements of the worst supported plugin

Indeed it would! Not sure how else to handle this. Assuming the syntax is identical across all plugins, this is then about browser APIs. If a plugin feature requires a newer browser API like e.g. IntersectionObserver or resource hints, that will necessarily lower browser support across the bar. There's no way of "updating" the plugin to increase browser support.

The only option is polyfilling the feature, and that should happen at the last possible step, in the actual project of the consumer, as the consumer needs to decide which browsers they ultimately want to support. That's what the note about polyfills in the docs is about — it's impossible for us to decide where the cutoff point is on this.