They write "Now that web apps are capable of reading and writing files", and link to their article about the File System Access API, which is a Chromium only API. They're trying to make it look like Chrome only apps are regular web apps, and if they doesn't work in other browsers that's on them and you should just switch to Chrome instead. They want Chrome to be thought of as the default web experience.
There are basically four votes that matter, corresponding to the four major browsers: Google (Chrome), Apple (Safari), Microsoft (Edge) and Mozilla (Firefox).
Google claims that "browsers" support an API if it's supported in Chrome and in Microsoft Edge, a Chromium-based browser.
Microsoft could have blocked File System Access, for some of the same reasons that Mozilla did, but they didn't; they elected to enable the feature.
Since Microsoft + Google together have 70% share of desktop web, and since Microsoft agrees with Google that the File System Access API is a good thing for the web, I think it's not wrong to say that "browsers" support this feature.
Now, you might say, "Microsoft shouldn't count!" but Edge's market share is bigger than Firefox, and we all agree that Mozilla's vote should count (at least as long as they can hang on to 3% market share).
Looking at the sources used on the wikipedia page[0], it seems pretty skeptical. For one, the services for collecting the data seem to be depending on tracking APIs from partnered sites. Does Firefox typically allow those through? Is it reasonable to question whether that's a reliable methodology when one of the values of the browsers is preventing such tracking in the first place?
And it shows NetMarketShare data being as current as of May 2021, despite NetMarketShare not providing data beyond Oct 2020[1]. And the last dataset of NetMarketShare has Firefox at 7%. Publicly, at least. Looking around the site it seems people may have access to the internal API, but questions about data integrity remain (now in conjunction on whether unverifiable data from an API should be used on Wikipedia).
Is there something more I and others should know about these data collectors?
As you noticed, https://netmarketshare.com/ is not a great site for browser share data. For one thing, as you point out, they stopped providing new data points in Oct 2020.
But also, for some reason, NMS automatically filters the view by "desktop/laptop."
As of Oct 2020, NMS says that Firefox's overall percentage was 3.32%, and that Edge overtook it over the course of the previous year.
GlobalStats StatsCounter says that as of May 2021, Firefox has 3.36% share, down from 4.38% the prior year. Focusing on desktop browsing, Firefox had 8.91% share last year, and has 7.36% share today.
If Firefox loses another 1.5 points of desktop market share this year (and I see no reason why they wouldn't), they'll dip below 5% desktop share; and well below 3% share when you add in mobile.
> Now, you might say, "Microsoft shouldn't count!" but Edge's market share is bigger than Firefox
That honestly surprised me, but you're right [0] - though only 0.01% (StatCounter) or 1.65% (NetMarketShare) in it, depending who you listen to.
I'm not sure about the latter, but I'd have thought 0.01% is down in the noise of misreported user agent, which FF users are probably the most likely to be doing.
Largely because they are falsely and anti-competitively claiming that Firefox is unsafe with warning text and/or pop ups if you try to install it on windows
This might be me being pessimistic but there are no web standards any more. It's Chrome standards. You can fall in line or drift into obsolescence. We never really got rid of the IE dominance on the web, we merely exchanged one boss for another. I get it it's not _quite_ the same since we don't have the ActiveX nonsense any more but it certainly feels like we're living in Google's vision of the web. Monocultures are harmful but that's we get to live with.
We are living in Google's vision of the web, but isn't that the cost of disruption? The Chrome team set out to build a better browser and even open sourced the core, Chromium. Many browsers are built on Chromium now and there is a standard for extensions on the horizon.
No one is stopping another company from disrupting Chrome and making their own vision of the web by building a better browser. It's not going to be easy, but neither was it for Google. Many new web technologies like PWAs originated with Chrome and are slowly diffused to the other browsers. Apple, on their own, would never have pushed for PWAs and even now, their support for them are lackluster.
It's a problem because Google is constantly implementing new APIs, creating new file formats that are "open-source" but de facto controlled by them, and "advancing" the web by advancing their own interests rather than the interests of consumers of the web.
There are so many web apps that fail ungracefully on Safari and Firefox that work perfectly fine on Chrome. Or apps that have significantly better performance on Chrome, including Google's own products like Gmail and Youtube. As a tech enthusiast I know that the reason is because Google makes it work that way, but for a typical user they'll likely blame the browser that is being shoved on them by their tech-literate family member and run back to Chrome because it "just works."
The only check against Google's hegemony of the web is Apple not allowing anything but webkit be the renderer on iPhones. It's the only platform that is large enough and important enough that Google doesn't have completely unfettered access to implementation of features that advance their ad-tech needs.
There's a difference between being disruptive and destructive. Google's a destructive force to the web.
> It's a problem because Google is constantly implementing new APIs, creating new file formats that are "open-source" but de facto controlled by them
But this is a critique of open source as a whole. The maintainer (or the team) will have final say and control about the product they built. If the product is extensively used, then that team will have heavy influence.
These new APIs will be used by early adopters and if they provide actual value, they should be added to the other browsers. One would think most production apps will not use Chrome only APIs until they are supported by all major browsers. But at least the ball is rolling in the right direction.
Apple and Microsoft had a chance to compete with Chrome early on but brushed it aside. When Chrome added search in the URL bar, it was innovative. When they add new APIs now, it's too much?
> But this is a critique of open source as a whole. The maintainer (or the team) will have final say and control about the product they built. If the product is extensively used, then that team will have heavy influence.
It's not, really. Yeah, maintainers of large projects have large influence over that particular project but much of open source is insulated from the real world through various abstractions, including the web.
Developers of React might have a lot of influence over how programmers approach web development but that's not something visible to end users. When Google pushes something like WebP to the web, it becomes a standard simply because it's supported by Chrome and not because of any process of standardization outside of Google. Safari only just added support for WebP last year but if a website used WebP without a fallback to jpeg/png then the website becomes functionally worse and is visibly broken to consumers.
> These new APIs will be used by early adopters and if they provide actual value, they should be added to the other browsers. One would think most production apps will not use Chrome only APIs until they are supported by all major browsers.
There are many many cases online of websites that simply do not function at all correctly on Safari and/or Firefox because they do use chrome-only APIs or they only test their web apps on Chrome. There are large corporations whose web apps (like their online shops) don't even work correctly on iOS' browsers. One would think, but reality doesn't match your expectations.
> Apple and Microsoft had a chance to compete with Chrome early on but brushed it aside. When Chrome added search in the URL bar, it was innovative. When they add new APIs now, it's too much?
Improvements made to user chrome has no implications on the web as a whole. Adding search to the address bar doesn't make Youtube or Gmail function worse on other web browsers.
I think it's important that browsers are able to improve the web. I'm not against the idea of Google proposing adding new functionality through new APIs. The problem is that they can do that without any oversight from anyone else. They create a new technology that is controlled by them and introduce it to the web where they already have massive influence (#1 search, #1 video website, #1 email, etc) and expect everyone else to simply fall in line. Companies like Mozilla don't have any recourse here. No single company should have that much influence over the web.
Yet here we are where one company has control over some of the biggest websites on the web while having influence over how visible any other website is due to being the biggest search engine on the web while also controlling the browser that everyone is using while also controlling the operating system that is the most used in the world all while being a company that their primary business is harvesting people's information to serve targeted advertisements.
> The Chrome team set out to build a better browser and even open sourced the core, Chromium.
I think that rewrites history a bit. They started with a Free Software browser - Konqueror/KHTML - and were required to release changes under a compatible license.
We should be thankful that Konqueror/KHTML was released under a Free Software license, rather than a permissive open source license that would have allowed Google to deny us the rights that they had been granted by their upstream.
> We should be thankful that Konqueror/KHTML was released under a Free Software license, rather than a permissive open source license
Your wording suggests that permissive licenses are not “Free Software” licenses, which is incorrect. Even the FSF acknowledges that permissive licenses like BSD, ISC, MIT, and Apache are free.
> No one is stopping another company from disrupting Chrome and making their own vision of the web by building a better browser.
It's is almost impossible for anyone to create a new browser. Even for a corporation with near-unlimited resources it would be a daunting task. Hell, Microsoft gave up, and they are definitely not short on resources.
At the time of this writing Chrome ships 7600 web apis [1]. Firefox and Safari ship 6500 and 6300 respectively. Chrome will happily ram its own internal APIs through standards committees with nothing but a lip-service to the other implementors because this only assures Chrome's dominance. This also assures that no other browser will ever appear.
> Many new web technologies like PWAs originated with Chrome. Apple, on their own, would never have pushed for PWAs and even now, their support for them are lackluster.
Ah yes. The bad-bad Apple. How can Apple not be bad when we have the great saviour of the web, the Saint Disruptor Chrome.
Meanwhile, both Apple and Mozilla are increasingly on the same side with regards to the non-standards that Chrome rams through: they are vocally opposed.
And yet, Chrome will have you believe that these standards are not only there, but that they are complete (so many of them are just drafts that have been cobbled together by some googlers), and that they are immediately available and can be used (they can only be used in Chrome).
I do get your point, Chrome is launching new APIs faster than the other guys can catch up. My issue is that the others guys had a lot of time to create the APIs Chrome is creating now and has created. When Chrome was focused on making the web better, these guys were working on making it more restrictive.
These seem like useful APIs. Mozilla seems against these due to security risk, but then why not work on a protocol that is safe? Bringing NFC, USB, and Bluetooth to the web is important in my opinion. Apple still doesn't let you connect a bluetooth device via WebKit, but guess what? You can pay to install a browser on the App Store that does.
Nothing is going to be perfect at the beginning but if Mozilla is so against it, the best response is a better product.
> When Chrome was focused on making the web better, these guys were working on making it more restrictive.
What the hell are you talking about? Safari and Firefox were building a better web long before Chrome even came onto the scene.
Safari precedes Chrome by 5 years.
Firefox precedes Chrome by 6 years.
They were both making the web better when IE6 held something like 99% of the market.
> Mozilla seems against these due to security risk, but then why not work on a protocol that is safe?
What the hell are you talking about? You want Mozilla to implement a new safe protocol to replace USB?
> but if Mozilla is so against it, the best response is a better product.
Yes, and both Mozilla and Safari are against WebUSB for one simple reason: they want a better product that doesn't compromise user security. But sure, why they don't just build one, right?
Chrome doesn't care and ships it anyway, and for some reason you're saying it's Google who are building a better product. No. They are building a product that's better for Google, first and foremost, and everyone else (including security, privacy, long-term health and sustainability of the web) be damned.
I think Apple was first with progressive web apps (PWA) as in web apps that could be installed to the "home screen". iPhone was meant to only run these web apps. Then Apple made a 360 in favor of "native" apps in order to get more performance.
Also FirefoxOS was and still lives on (KaiOS) using web apps.
It is actually sad that other browsers are not going ahead supporting this API. The authors of this spec are really trying hard that other browsers also move forward with this API, but the maintainers of the other browsers confusingly think this is a threat to the web ecosystem.
Note that PWA is a concept, not a specific set of features or APIs. This makes a lot of this discussion confusing and mostly meaningless. Furthermore this bug is about a browser feature. The similar "PWA" API here would be https://developer.mozilla.org/en-US/docs/Web/Manifest/displa... which is supported by Firefox for Android so it isn't like Firefox won't support "PWA" as a whole and will reject all of the related APIs.
And remember that PWA is Progressive Web Application. The P is from Progressive Enhancement[1]. This means that missing an API or two doesn't mean that your browser doesn't support PWAs. It just means that some PWAs will have less functions or give a less "app-like" experience.
https://caniuse.com/native-filesystem-api