That's weird I was about to disagree with you but then I refreshed the page and had the same problem. The debug console showed a lot of content security policy violations for inline scripts.
After some more refreshes it came back. The bug seems intermittent and thus not easily reproducible.
I've been a Chrome user since 2011. I recently switched to Firefox and I got comfortable instantly. It was the case back in the day that Chrome was super blazing fast. No more. Firefox is amazing, fast and there are few things that still annoy me but they'r minor compared to the philosophical issues I have with using Chrome. Fuck AdTech and fuck Google.
I've also completely switched from GMail after 15 years. I remember signing up for GMail when it was in beta. Now I have a free iCloud email and it works just fine. Plus, Apple is about the only company that I can even begin to trust.
Pragmatically, it does. I don't want to be forced to "get off the Chrome pony" right now as Chrome still is notably faster than Firefox on my computers (which are 5 and 8 years old but still do the job). If the next version of Chrome is the one that is going to break compatibility with extensions I use I'm just going to disable updates and this will give me at least a year - many people use even more outdated browsers are okay.
There are going to be multiple good options based on Chromium that will not break extension compatibility. Brave Browser being the most well-known and polished, but there will be more.
As of this month a Google post claims that the anti-adblocker stuff is still under development. I can't find any sources claiming it is in 76, so I don't think it is.
The change is going to be part of Manifest V3. As of yesterday it is still "very much in development" https://groups.google.com/a/chromium.org/forum/#!searchin/ch... Also they're planning a transition period after which Manifest V2 extensions will be removed from the store, so you'll definitely notice when that happens.
And also it isn't anti-adblocker tech. It is pro-privacy tech which will require adblockers to reengineer how they work which has caused their authors to throw a whine fest and feed some good click bait quotes to the press.
As a veteran chrome extension developer, I'm more inclined to trust extension authors than I am to trust the chrome extension API development team, because it's a bad API with bad documentation and bad performance.
Google's claims that the new API will be faster were already shown to be a blatant lie.
Accusing someone of astroturfing is specifically against the site guidelines (for good reason, it’s like being accused of being a witch. There is no defense against it).
You deploy application once on the web and it can be installed on desktop or mobile device as native app, if user chooses to do so. Or used as webapp in browser.
When installed your app has homescreen/desktop icon, opens in separate window.
And the best thing - you don't need to pack a whole internet browser with your app (Electron) and worry about pushing updates to user - you just update your app on web.
Imagine, that instead of downloading desktop client for Slack, you go to slack.com and click "Install" button.
Current negatives are that PWAs still missing support for advanced features like file system access, but browser developers are already working on it.
I hope in few years installing VSCode will be as simple as going to their website and clicking "Install".
Desktop PWAs are just like regular desktop applications, except that they work in a web browser as well. This is good because you don’t have to blindly install an app hoping that it will work well and solve your problem, but instead you can just use the app in your browser, and if you like it, you can install it.
It's the only way to make a really cross-platform GUI app. Code once, run everywhere. Many devs/designers also like web tech for letting them make it look and feel almost any way they can imagine.
Run terribly everywhere, with lowest-common-denominator functionality.
I loathe this trend. With everything calling back to a backend in the sky anyway, it should be easier to make light, efficient native shells with good UIs.
Perhaps this is a matter of personal taste but I don't want cloud-backed apps, I won't use anything but 100%-local as long as I have choice.
I also don't want to invest time in developing anything that won't run on all the three major OSes (Mac, Linux and Windows) when built, nor to invest any serious additional effort to achieve this. Being able to run the app in a browser after minimal modification is a nice-to-have bonus (probably very important for many people who develop web-first).
As for now I use WinForms and Qt frameworks to achieve this but I probably am going to switch to Electron if Flutter Desktop doesn't get released soon.
Nevertheless, as a user I would indeed prefer native GUI desktop app talking to their web server for data over a web site.
Perhaps people would develop apps this way if there was a native GUI framework as powerful and easy as web frontend frameworks are and if there was a way to publish you apps a way people could discover and run them in a couple of clicks. Perhaps MS UWP with WPF and Windows Store could do the job much better than web apps but sadly it's not cross-platform.
Maybe I should have added the /s at the end of my comment.
I am aware that the change to the webRequest API has not been implemented yet.
However, I just could not resist having a bit of fun when I saw this headline.
And yes, I actually did switch to FF in light of this announcement from Google.
I actually tried to switch a few times in the past but never really had the motivation to do so. Google gave me the motivation, so I guess, thanks Google!
AFAIK the new proposal allows dynamic filtering, which addresses the primary concern with adblocking tools like uBlock, I believe.
> The Declarative Net Request API now allows for the registration and removal of dynamic rules - specified at runtime rather than statically in the manifest. We’ve also added the capability to remove common tracking headers, such as Referer, Cookie, and Set-Cookie.
There is a limit of 30k rules though, which isn't enough to contain even uBO's defaults. While it looks like they are moving to a 150k global limit, even that is less than my current uBO setup of over 200k.
No, as far as I can tell Gorhill's position on the policy hasn't changed since dynamic filtering was introduced. The primary concern isn't that rules can't be modified, it's that they're declarative -- meaning developers can only use filtering schemes that Google explicitly supports.
It's inaccurate to say that the revised v3 addresses all API concerns.
It is not implemented, and ad blocking still works. Also they recently announced more changes to the proposal. To be fair they have some good reasons to change existing api. World is not ending yet.
UBlock Origin, UMatrix, Privacy Badger, Decentraleyes, and HTTPS Everywhere are all not available on Safari, in part because the APIs they rely on aren't available.
I'm not sure why people make the claim that Safari is just as good at blocking ads as Firefox and Chrome. It's not. The extension options on Safari are comparatively quite limited, in no small part because of technical decisions like this.
I'm on a Mac and just checked the Safari extension store. The only extension I see for Ublock is a fork of Ublock Origin called Ublock Safari. It hasn't been updated in a year, and is thousands of commits behind the official version.
It also isn't distributed by Gorhill, even though the extension lists him as the author in the extension store. In fact, none of this information is listed on the extension page itself.
I'm not sure the extension you're using is what you think it is -- I would be at least mildly cautious about installing it.
See also this issue (https://github.com/el1t/uBlock-Safari/issues/145) on Ublock Safari's Github filled with people complaining that the extension doesn't work and that Safari's tech restrictions mean that there aren't suitable alternatives.
Even if they end up implementing Apple-style simple blocking, they said at the beginning that they would adjust the limits. Most recently, they said the limit would be 150k, which is three times the number Apple allows. https://blog.chromium.org/2019/06/web-request-and-declarativ...
We are definitely going back to IE-like days