Many do, for long term archival at least, but tape still has only 30 years lifespan and has other limitations. As an example, the media wears relatively quickly when in use, so if there’s a need to access the data even relatively often optical media would make sense. That’s often not an issue in archival though.
SEO is of course a problem, but it’s been a problem for a long time, and there are ways around it for those who know how to seek information. Proper use of keywords, blacklisting sites with known spam information, searching specific sites, mandating specific words and phrases to be contained in the search etc. It’s true, however, that information has become less discoverable during the latest decade – at least reliable information has.
While AI-written spam articles and such have been a pain sometimes, gatekeeping content is in my opinion as big of a threat to the proper use of search engines for finding information. As more and more sites require you to log in to view the discussion (social media is the worst offender here) much of the search results is unusable. Nowadays the results lead to a paywall or a login wall almost more often than to a proper result, and that makes them almost completely useless. I understand this kind of thing for platforms which pay for creating the content, e.g. news sites, but user-generated content shouldn’t be locked behind a login requirement.
I fear the day StackOverflow and Reddit decide the users’ discussions should be visible for only logged-in users. Reddit has already taken the first steps with limiting “NSFW” content to logged-in users only (on new reddit). Medium articles going behind paywall also caused some headaches a while back.
My best guess is the dates on which the feature was added, which can also be seen on CanIUse. Firefox added OPFS support in March this year, and much of the userbase (AFAIK e.g. Firefox ESR) is still lacking the feature – in any case it’s a very recent change on Firefox. However, webkit/Safari has had OPFS for over two years by now. I was personally unaware of the support having been added to Firefox as well, last time I checked the discussion they told they weren’t going to implement the API.
By no means is this an acceptable excuse in my opinion, this kind of check should always be done by checking the existence of the feature, not the UA string. Though it might be that the check is still performed in the correct way as Safari users stuck on older version are also encountering the issue. But if they’re fine with using OPFS, where you need to export the files separately to access them outside the browser context (as the storage is private), there’s no reason to complain about recent Firefox versions that support this feature.
But, the same point still stands, kind of. The main underlying problem is Google forcing new standards through Chromium, without waiting for industry consensus and a proper standard. Then, as 80% of the userbase already has the feature everyone else is forced to get on board. I still don’t really see Adobe as the main culprit here, despite the apparent incompetence in writing compatibility checks, but Google with their monopolistic practices with the Chromium project. Adobe isn’t innocent and has done the industry a lot of harm in the form of being one of the original pushers of subscription software, but I don’t think this instance should be attributed to malice rather than incompetence.
Edit: So, a bit of additional advice for someone trying to get this to work: in case the UA spoofing doesn’t help, check the Firefox version in use – it has to be 111 or newer, as 111 was the release where File System API support was added. Firefox ESR probably doesn’t have it available. Also check that FS API / OPFS doesn’t need to be enabled through some flag or configuration parameter, and that it’s not blocked by some plugin.
Well, in this case it might even be a technological limitation, which can be solved with a workaround but leads to a poor user experience.
Firefox, for security reasons, doesn’t allow opening local files for writing. That means, it’s not possible to make a web application that can autosave to your machine after you open a file, meaning you have to download a new version of the file every time you save. You can get around this issue by importing the files in question to the browser’s local storage, or by using cloud storage via an API, but local saving is a feature that people have come to expect and missing it will lead to complaints from the users.
The missing API is called File System Access API and has been available on Chrome for years. I’ve personally had to write my web apps around this limitation multiple times, since I want to support Firefox. By no means is this a valid reason to exclude Firefox in my opinion, but I can also easily see why a company would want to not bother with user feedback on ctrl+s not working in their web application.
Given that there are engineers involved I wouldn’t be at all surprised if that was deliberate. Trying to get potentially offensive or otherwise NSFW acronyms past marketing without them noticing is practically an industry-wide joke at this point, which is why they are so prevalent in the FOSS space. (no marketing staff to complain)
If that’s true in this case, though, hats off to whoever managed to get it though to official commercial standards