Usually I tend to work on Chrome, because for me it's like most dominant browser on mobile phone and also on computer. Also it's always on top regarding the different APls, it always has the last. So I tend to focus on this browser. If something doesn't work I look at Mozilla to see how it works in their browser. So I have at least those two working together. For me I guess it's enough. I'm concerned about compatibility but I'm looking at where the most users are and I tend to focus on these points.
How about Safari on desktop or mobile?
Safari is almost like Chrome, but I don't like these browser vendor prefixes. So if the Chrome API works in Safari it goes fine, otherwise I will not test it, so I will never know if there's a bug happening.
PWAs
What was the last issue you had with vendor prefixes?
It's been a long time. Now my biggest issue is when you try to make a progressive web app manifest, it's different for each [browser], so it's a bit... repetitive task to create multiple manifests for different browsers.
Different browsers required different things?
Different sizes of logos, different information, different scopes. That was enough, like "OK." Some frameworks tend to automate it, but I didn't event... now I'm already focused on the JavaScript part, trying to work offline, looking for a project where I can include web workers in a very efficient way, so for now I'm not really focused on the manifest anymore. But it's a point I wanted to discuss, because I think it's [inaudible] if you want to make [inaudible] to progressive web apps, it's good to have a manifest that's easy to build for any developer.
JavaScript
You work with vanilla JS, any recent compat issue?
Made with FlippingBook - professional solution for displaying marketing and sales documents online