> Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum.

Do many companies actually do this though? I've only ever been with companies that test against Chrome. The one time at FF bug was found, that company told that client to switch to Chrome.

I know there was a kerfuffle about Airbnb and Groupon only doing Chrome as well.

https://www.reddit.com/r/AirBnB/comments/dv7v6n/customer_sup...

https://thenextweb.com/dd/2017/11/28/please-build-websites-w...

Maybe in theory all platforms are considered, but in practice many companies just do one and the others mostly just work.

Yes, absolutely. Every company that I've ever worked at had a list of officially supported browsers that included Chrome, FireFox, Safari and Edge/IE. QA engineers would make sure to rotate through various browsers while testing, and for crucial features would run through every scenario in every supported browser's oldest and newest supported versions.

Pretty much the only reason to use Saucelabs is browser compatibility testing.

We don't run everything through it, but we run karma to make sure the code runs and the right events fire. It is still possible to write code that runs everywhere but IE.

Most companies today use frameworks that have good cross-compatibility so it tends to just work. In my opinion though, a responsible web developer is going to test on multiple browsers at the very least.

Safari is huge. Doing Chrome only is suicide. Thankfully, cross browser compatibility is much easier these days, specially if you don’t use flex or grid.

In a previous company we had to do FF and Chrome. Not IE though, which was a big time saver. QA ran all their test cases on the latest stable of both FF and Chrome, and features would not be deployed to prod if they didn't work on both browsers.

And in recent years this has gotten much easier. Cross browser support used to be a pain in the ass.

Now most of the time changes aren’t even needed. Besides maybe the odd Firefox or Safari thing.

Funnily enough in my experience it's usually Chrome and Safari that do weird things, which as a Firefox user always gets me dinged on PR reviews :p

Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).

But we know from web statistics that these are very few people and shrinking every year.

That is not how it works on Windows, as you have to ship either the Webview2 runtime or installer with your app - otherwise you’re stuck with the old rendering engines.

At which point, it’s just easier to ship Electron.

Shipping Electron and bundling the WebView2 runtime are practically the same level of difficulty.

Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.

>Making an installer is not that hard, and you should have enough respect for your users' compute resources to go through the modicum of effort it takes.

No. As shown by the slew of other comments in this thread, it's not just about getting the runtime to load. You still have other issues involved.

You should have enough respect for your own time and money to ship the product and not open yourself up to a litany of cross-platform issues. Your job is not to fix OS vendors failing to get a common UI framework in place.

Signed, someone who has literally dealt with cross-platform-webviews in a shipping product in the past six months, and who builds native Mac apps.

Tauri's Bundler will automatically take care of shipping the Webview2 runtime, so there won't be any extra work required of you.