Our great sponsors
-
uBlock-Safari
uBlock Origin - An efficient blocker for Chromium, Firefox, and Safari. Fast and lean.
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Interesting, I had not heard about this (looks like it was announced at the most recent WWDC), but the Vimium devs already have![1]
Vimium and uBlock Origin are pretty much the only two plugins keeping me from switching away from Chrome/Firefox to Safari.
Given all the hype around Safari’s performance on new M1 Macs (and the fact that only Safari supports Apple Pay), I’d love to have parity on these two extensions extensions. It seeems like Web Extensions will not provide enough to fully support uBlock Origin, but maybe their Content Blockers will be a close enough approximation.
At the very least, I hope that Safari will gain a larger userbase from these changes, regardless what I choose to use. Having multiple large, evenly distributed userbases will only make web developers think more about Chrome-first or Chrome-only development.
[1] https://github.com/philc/vimium/issues/3610
Same. I can't use Safari without Ublock Origin. The web is a horrible place without it.
[1] https://github.com/el1t/uBlock-Safari/issues/158
https://github.com/nishanthvijayan/CoderCalendar-Extensions/
I'm going through converting a Chrome extension to Safari 14, and the process isn't nearly as seamless as shown, although it's nice to have the converter tool.
Chrome extensions only support the 'chrome' namespace, while Firefox supports 'chrome' and 'browser', but Safari 14 only supports 'browser'. So our extension had been using the 'chrome' namespace which worked under Firefox, but now needed to be converted. 'chrome' uses callback functions, while 'browser' uses Promises. So you have to port your Chrome extension to use 'browser' and use the following polyfill: https://github.com/mozilla/webextension-polyfill
Here's some incompatibilities between Chrome and Firefox to consider: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Also had some html/css glitches to fix in Safari. Some other issues others have mentioned such as notifications and webRequest APIs.
I've used this to convert a small Google Meet push-to-talk extension: https://github.com/BashVideo/google-meet-push-to-talk/pull/2...
That one's really simple, but doing the Firefox port first seems to have ironed out most of the compatibility issues. Mostly APIs with newer versions where Chrome is the only one to support the old API.
But just exploring web extensions a bit (this was my first time interacting it), it feels like supported features differ quite a bit between browsers. Chrome has the lead here, and Safari seems 'minimal' in comparison. UI elements can also behave very differently between browsers.
Apple is dead-set on having you use the App Store to distribute even web extensions. The converter works fine, but just this way of doing things does bring along a bunch of frustration for unfamiliar devs. There was a Twitter thread on this recently started by a member of the Safari team, which gives an idea: https://twitter.com/jensimmons/status/1338558758025367553
Related posts
- List of people offering their time for free to have a "coffee chat"
- Getting Started with Next.js: Part 1 - Setting Up Your Project
- UX Case Study: Markdown Heading
- System & Database Design (Day 1) - Creating a SaaS Startup in 30 Days
- Como foi fazer um decodificador do zero para o projeto final da 1ª parte do OracleONE