
Safari is adopting an extensions API similar to Firefox’s WebExtensions - skellertor
https://hacks.mozilla.org/2020/06/welcoming-safari-to-the-webextensions-community/
======
drenvuk
It's still gimped.

No blocking requests.

"Unlimited" storage (which is necessary for most non-trivial extensions) is
actually limited to 10MB.

You're stuck in Apple's app store which is equally as draconian as Chrome's
and Firefox's but now you have to pay $99/year.

No IndexedDB.

The extensions aren't usable on mobile.

I care little for Safari's users if I have to deal with all of this.

~~~
Jaxkr
Nobody really uses Safari except for on iPhones, and I suspect I will drop
dramatically as they’re adding support for choosing your own browser in iOS
14. Even among non-technical people I know, nearly everyone replaces Safari
with Chrome or FF. Even my grandfather uses Chrome on his Mac and iPhone.

~~~
kjakm
>> Nobody really uses Safari except for on iPhones

Have you got _anything_ to back this up? I’m willing to bet the majority of
Mac users use Safari (given it’s the default browser). I use it and it’s a lot
less clunky than Chrome and Firefox. I also repeatedly run into an attitude of
“if my users don’t user Chrome then I don’t care about their experience” and
find it very off putting.

~~~
MintelIE
I bet they don't. All the Mac Safari users I know also run Firefox because
Safari's ad blocking sucks.

I only know of a few Mac users of Chrome.

~~~
jeromegv
2020 and people still rely on random anecdotes heavily influenced by their
techie friends instead of actually looking at the data. Fascinating.

~~~
MintelIE
What data? Show me the data.

~~~
hombre_fatal
[https://gs.statcounter.com/browser-market-
share/desktop/unit...](https://gs.statcounter.com/browser-market-
share/desktop/united-states-of-america)

USA desktop browsers, May 2020:

\- Chrome: 58.97%

\- Safari: 15.65%

\- Firefox: 8.24%

Doesn't have much in common with your anecdote except that it's in the reverse
order of popularity that you seemed to claim.

------
freediver
Apple had a great opportunity to natively support web extensions in Safari.
Instead they choose to do it through the app extensions System. Meaning a
developer needs to have and pay for Apple dev account. They need to have a Mac
to port and compile it. They have to sign it. And then maintain it.

This will certainly affect adoption. Forcing an open standard into a closed
system seems intuitively wrong.

But at least kudos to Apple for recognizing the need for webextensions
support.

~~~
balladeer
At this point I think I should just switch to Firefox. It's just that Firefox
still (unfairly) lags behind in performance because it's a Mac.

~~~
ebg13
Forget about performance. Firefox still lags horribly behind in battery life.

~~~
toyg
Everyone "lags behind" Safari in battery life on mac, unsurprisingly: a mono-
platform app can pull tricks that multi-platform ones cannot.

When comparing apples to apples, Firefox imho is actually lighter than Chrome
on battery, at least on Macs.

~~~
npunt
Understandable from perspective of how apps are developed, but from the user
perspective comparing Firefox on Mac to Safari on Mac is literally comparing
software on Apples to software on Apples.

------
AnonC
I don’t have a lot of hopes that this will satisfy my needs. I just want these
extensions in Safari, to start with:

* uBlock Origin (confirmed as of now as not supported, and unlikely to be supported in the future either, with content blocking handled at the browser engine level)

* Privacy Possum or Privacy Badger

* Session Buddy or some good Session saving extension

~~~
baggachipz
Seriously. Not being able to block ads with Safari makes an automatic no-go
for me. Even if they make their own built-in ad blocker, you can bet they'll
let companies pay to become "platinum sponsors". No thanks.

~~~
peruvian
I've been happy with Wipr on macOS and 1Blocker on iOS for years. In fact I
think you can just use 1Blocker in both platforms now. Neither is as "good" as
uBlock Origin but I don't really care.

~~~
a2tech
I believe Wipr works on both iOS and macOS. I'm also a happy Wipr user.

------
erdaniels
I really wanted to stick with Safari a little over two years ago when I moved
off of Google products. It was (is) snappy and battery conversant. Beyond poor
extension support, I realized the absolutely most important features to me in
a browser are password, bookmark, and history synchronization. Since I use
Windows and macOS, Safari was out of the question (RIP Windows edition of it).
Thankfully in the last year Firefox has mad leaps and bounds on performance
and battery life consumption on macOS (on Windows it is fantastic).

Also at the end of the day, you have what I believe is the most unlimited ad-
blocking experience on Firefox compared to Chrome, Chromium, and Safari.

------
tester89
What does this mean for Ad-blockers like UOrigin which were removed after
Apple disabled the API they used?

~~~
bluedays
I'm going to be downvoted for saying this but... ublock origin actually does
slow down rendering your webpage. I think that it's sad that there seems to be
so much pushback from vendors in regards to options like ublock origin, but I
have found equally impressive results with system wide options like adguard
without it reducing the speed of pages rendering.

~~~
surround
Yes, I’m going to downvote you, but only because you misunderstand how ad
blocking works. uBlock _does_ marginally slow down webpage render because it
has to inject CSS rules (cosmetic filters) to improve blocking quality. If you
don’t want this feature, you can disable cosmetic filtering entirely within
uBlock’s settings.

The problem with AdGuard is that they charge for system-wide blocking which
can be done for free with a hosts file or pi-hole.

~~~
bluedays
You are being presumptuous about my knowledge in regards to ad blocking. So
I'll explain in further detail why I personally use adblock, and why ublock is
unnecessary.

First, the css rules are available on adguard as well. You can actually review
the documentation here: [https://kb.adguard.com/en/general/how-to-create-your-
own-ad-...](https://kb.adguard.com/en/general/how-to-create-your-own-ad-
filters#example-cosmetic-rule)

Second, adguard is free. There are certain premium features, however. For
instance, filtering ads outside of your browser requires a premium license.
However, if you are comparing it to ublock this was already not a feature that
was available to you.

Of course, even that comes with an addendum, which is that this is only
something that you need to worry about on mobile devices. Should you be using
the desktop version you will actually see that adguard is free and available
here on github:
[https://github.com/AdguardTeam/AdGuardHome](https://github.com/AdguardTeam/AdGuardHome)

In regards to pi-hole. The cumbersome nature of pi-hole makes it undesirable
_for me_. There were many sites which were blocked for inexplicable reasons
the last time I used a pi-hole and creating a whitelist for these sites
requires more work than is necessary. First you must navigate to the portal,
and then you must make changes to either the whitelist, or remove a site from
the blacklist depending upon why the site is not accessible. It was not
seamless design. However, those that find this feature desirable will find
that adguard actually offers the same experience with adguard home:
[https://github.com/AdguardTeam/AdGuardHome](https://github.com/AdguardTeam/AdGuardHome)

And as a matter of fact you will notice that there are comparisons between
ublock origin available on the github page for your review. There are actually
a number of features which are missing from ublock which are simply not
possible with ublock origin. As for the accuracy of these features you’ll have
to determine that on your own but you can review them here:
[https://i.imgur.com/5fSLuHx.png](https://i.imgur.com/5fSLuHx.png)

Also, ublock origin does not _marginally_ slow down a webpage rendering. It
_significantly_ slows down a webpage rendering. As evidenced here:

With ublock origin:
[https://i.imgur.com/4NxOysN.png](https://i.imgur.com/4NxOysN.png)

without ublock origin:
[https://i.imgur.com/jIlof5e.png](https://i.imgur.com/jIlof5e.png)

That means that when you are running ublock origin your browser is working at
87.85% capacity. Or in otherwords, a 13.15% decrease in speed. To put this in
real world terms it would be similar to reducing the speed to 50mph* on a road
that was originally 60mph.

So feel free to keep using ublock origin. As a matter of fact I also use it
occasionally in a pinch. (It does, after all, significantly speed up rendering
of some webpages. I find it especially useful on webmd.) However, for my daily
driver I find it to be a poor solution.

*Rounded down, the actual number is 52.11.

~~~
gorhill
> That means that when you are running ublock origin your browser is working
> at 87.85% capacity.

No it's not, at this point your are spreading FUD about uBO.

This is a benchmark specialized for one thing, the creation/deletion of DOM
nodes, a completely unrealistic scenario in the real world -- web sites do not
repeatedly create nodes just to have them deleted as soon as they are
inserted, as fast as possible.

uBO's code which deals with the DOM represents a _fraction_ of what uBO needs
to do, and yet you extrapolate the benchmark as if it represents _all_ the
work uBO does, leading to your nonsensical conclusion.

Here is how uBO compares to other comparable content blockers with an actual
real-world scenario, as per recent debugbear benchmark[1] -- it's the least
CPU hungry of the bunch:
[https://twitter.com/gorhill/status/1273263792785326085](https://twitter.com/gorhill/status/1273263792785326085)

Note that the above is a worst-case scenario for content blockers, since this
was about loading a page from `example.com`, where nothing is blocked,
consequently where a content blocker acts only as an overhead. See reference
[1] for a more typical scenario.

* * *

[1] [https://www.debugbear.com/blog/2020-chrome-extension-
perform...](https://www.debugbear.com/blog/2020-chrome-extension-performance-
report#performance-impact-of-ad-blockers)

~~~
om2
I don't know what to conclude about ad blocker perf from Speedometer, but it's
not just creation/deletion of DOM nodes. It runs multiple implementations of
TodoMV using various JS frameworks[1, and performs real operations in the web
app. DOM is not the bottleneck. The test stresses many parts of the engine,
JS, CSS, HTML, rendering, etc.

Google's V8 team (not the original creators of Speedometer, that was WebKit)
did a study of real-world JavaScript and found that it was highly correlated
with Speedometer[2]. It's likely to be a good proxy of load time and
responsiveness for many web sites, especially ones built with modern JS
frameworks.

I don't know why uBlock Origin would slow down Speedometer and I'm actually
surprised to hear it's true.

[1]
[https://browserbench.org/Speedometer2.0/](https://browserbench.org/Speedometer2.0/)
, click on "about Speedometer [2] [https://blog.chromium.org/2017/04/real-
world-javascript-perf...](https://blog.chromium.org/2017/04/real-world-
javascript-performance.html)

~~~
gorhill
Care to comment about the debugbear benchmarks? Why is the supposed undue
overhead as per SpeeDOMeter not showing up in there?

I encourage whoever to actually speculate less and measure page load times
from the top 500 Alexa and make the case that uBO is an issue CPU- and memory-
wise. I confidently predict that you will find that there is no correlation to
the SpeeDOMeter benchmark.

There are other 3rd-party benchmarks out there which also found that uBO does
indeed save CPU and memory resources.[1][2][3]

* * *

[1]
[https://twitter.com/gorhill/status/1246085758580142081](https://twitter.com/gorhill/status/1246085758580142081)

[2]
[https://twitter.com/adildean/status/936183316134416384](https://twitter.com/adildean/status/936183316134416384)

[3] [https://www.raymond.cc/blog/10-ad-blocking-extensions-
tested...](https://www.raymond.cc/blog/10-ad-blocking-extensions-tested-for-
best-performance/view-all/)

~~~
om2
> Care to comment about the debugbear benchmarks? Why is the supposed undue
> overhead as per SpeeDOMeter not showing up in there?

I'm not familiar with what you mean by debugbear benchmarks. If you mean the
content linked here:
[https://twitter.com/gorhill/status/1273263792785326085](https://twitter.com/gorhill/status/1273263792785326085)

Then my explanation would be that these measurements measure different things
than Speedometer. CPU time is a power metric, First Contentful Paint is a page
load speed metric, memory is a memory metric, none of these are web app
responsiveness measurements. All of these data points can be true at the same
time!

Personally, I would expect any content blocker that does a lot of blocking to
speed up page load, reduce memory use, and save power, because less stuff
loads and less stuff gets processed. That any ad blocker would reduce
Speedometer score is kind of a surprise to me, but if it's real, I believe it.

I really have no stake in which ad blocker is best or more efficient. I just
wanted to clarify what Speedometer does, and why it's a relevant measurement.

------
felixfbecker
As someone who works at a company with a web extension, one big thing I care
about is automated deployment. We have automated releases with Chrome and
Firefox (although it has to use Puppeteer). The new Edgium recently wanted to
get us to publish but I found zero docs on potential automation so that's a
blocker. Wonder what process Safari has to offer here?

~~~
kccqzy
Perhaps you can do it through Apple Configurator to create a configuration
profile?

------
MBCook
Does this mean Safari may get the React or Redux extensions? That’s all I care
about.

~~~
silviogutierrez
I'm hoping for that too. I really try to make Safari my daily driver
(performance, privacy, battery life). But the dev experience is lacking.

Also the network tab is just... odd.

~~~
om2
Have you tried it lately? A recent-ish rework made it more like Chrome's, but
with cleaner design.

