I am curious why Safari in particular is getting a lot of the hate here when firefox supports even less of the features which leads me to believe that the reason many of these features have not been accepted is because they have not been accepted by the larger ecosystem and is just google pushing their own things as standard (Feels like IE days in many ways).
That being said, I am not sure why I would actually want most of these features in the browser? Many of these things feel like they further complicate what a browser is supposed to be doing and opens up security concerns at the same time.
I think the idea of using a web app for many tasks instead of apps is fine, but I don't think the idea that a web app can do everything is the way to go.
Edit: To be clear about the Firefox comment, notice that many of the features that are not supported non chromium browsers don't support on any platform. So the question on whether these are considered web standards is outside of whether iOS allows other engines.
Edit again: Apparently the third column is based on your current browser instead of always comparing chrome, mobile safari, and firefox like I assumed. I am currently on Firefox on Windows, and there are more red X's under Firefox for me. Seems like a weird choice to not always compare all major browsers.
Safari is a monopoly on iOS and iPadOS, that's a problem if you want to make a bleeding-edge PWA app, in that it's probably not going to work very well on iPad and iPhone and there is no web alternative on those platforms.
Firefox is entirely optional, not a monopoly anywhere.
The problem for me isn't making bad web browsers, it's enforcing those bad browsers as the only option on a computer platform.
Firefox is not in a position where it is the only browser allowed to run on a platform.
On iOS, you’re either doing a native app, sharing 30% of your income with Apple, or you’re restricted to Safari’s feature set. No browser in iOS can use anything but WebKit
It came out in the Epic trial that 90% of App Store revenue comes from loot boxes and other pay to win game mechanics - cry my a river for those companies.
The other companies that are making money from mobile are usually front end for services that don’t monetize directly through in app purchases or give you the option of not paying through the App Store.
The first million in revenue is 15% not 30%
But also if it is just Apple, why do the same companies create apps for Android?
Let’s say in this world where there was an alternative browser engine that supported everything that you wanted, how much uptake do you think you would have for your app if someone had to download an alternate browser first?
Did I also mention that in the US at least you can link out to your own payment system?
Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
Going through some of the list from the top:
* Shortcuts in the manifest: This seems to be standard. Would be nice if mobile Safari supported it.
* Protocol Handling: This is non-standard.
* File Handling: MDN doesn't contain a reference to a standard, and it has this caveat: "At present this feature is only available on Chromium-based browsers, and only on desktop operating systems". So not only does it seem to be non-standard; Chrome on Android doesn't even support it!
* Contact Picker: This seems to be moving through the standardization process and is not yet standardized, if I understand MDN's "experimental" label correctly.
* Face Detection: This seems to be yet another not-yet-standard API.
* Vibration: This is standard, it's a shame Safari doesn't implement it.
I'll stop here but you get the point. 2/6 are actual standards; 4/6 are just features Chromium implemented even though they aren't standard.
I'm glad mobile Safari doesn't follow every Google whim. Google has enough power over the standardization process as it is; we don't want them to control which features browsers add outside of the standard too.
In addition, parts of the list seems to be extremely outdated: Safari on iOS does support the Web Push API and most of the Notifications API (at least for apps added to your home screen as PWAs). These APIs have been supported since iOS 16.4, according to MDN.
>Even so, conflating "Safari is holding the web platform back by not implementing standardized web features" with "Safari is holding the Google platform back by not implementing non-standard Google features" is kind of disingenuous.
You missed the point completely.
Apple >forbids< any browser engine on iOS other than their own Safari. So you can't just install Chrome on iOS, because when you do you get Safari instead.
I would not care how Apple cripples their own web browser if they didn't force other browsers on iOS to use their browser engine. They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
I am not an iOS app developer, I'm a web developer. I don't have the resources to support that kind of code when I already have a perfectly working web app on the competing platform. I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
It doesn't matter what the standards are or aren't. Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
And to make it worse, Apple is on the board that decides what standards get into W3C, so they are blocking useful APIs based on their own greed.
This is part of the reason Apple is currently being sued by the DOJ
Mobile safari is arguably the only thing standing between Google and total browser dominance. It's the reason why Google "only" has roughly 75% of the mobile browser market even though it has a 90% market share in desktop. I'm principally against the idea that Apple can prevent users from installing the software they want on their own devices, but we can't deny that it's better for the health of the web.
Anyway, if you want to exclusively argue "Users should be able to install the browser they want", that's fine. But you're not; both your comment and the pwa.gripe page brings up how Apple is "crippling" their own web browser. Since you use the same wording as pwa.gripe, I assume you too view the lack of non-standard Google-only features as "crippling mobile Safari". I disagree.
You seem to be conflating my opinion of "iOS's lack of browser choice has the consequence of preventing Chromium from achieving total dominance" with some imaginary other person's opinion of "iOS's lack of browser choice is a benevolent act where good guy Apple valiantly defends the open web". I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't. (Not purely because Firefox is technically inferior, mind you; products don't compete purely on technical merit.)
I think Chromium out-competing every other browser engine is a bad thing.
As the ball of mud that is web standards grows, the less likely that it becomes that things can “sort themselves out”. Even as things are you need a literal army of developers to build and maintain a modern standards compliant browser, making any real threat to Chromium dominance unlikely, and that only intensifies as Google rolls ever more crap into the katamari. If users can then be harassed into switching to Chromium based browsers it’s likely that it will never be toppled short of some new technology superseding the web entirely.
If Google abusing it’s dominant position in web browsers is a problem then the solution is legislation and anti trust action. Letting Apple abuse its own position because it currently provides benefit is not a good approach.
Same thing played out with ads and tracking a few years ago, and now look at the ads situation in the App Store.
Are you talking about Google or Apple? Because Apple is being sued by the DOJ for monopolistic and anticompetitive behavior. There are numerous examples of it spelled out in the lawsuit:
Both of them. To the extent that Google uses their position with chrome to give themselves in another domain they should be sued. Likewise, Apple refusing to allow consumers to install whatever applications they want on their own devices is so egregiously anticompetitive.
In their wildest of wet dreams Microsoft didn’t imagine they could get away with what Apple is getting away with.
I can do neither, actually. I can merely observe reality as it is and look at which forces affect the direction of the world. And right now, I observe a reality where one of the most significant forces which counteract a completely Chromium dominated web is Apple's user-hostile insistence on preventing browser engine competition on iOS.
I have very little faith in a legislative solution here since I believe politicians care about browsers, not browser engines. They see Chrome, Brave, Vivaldi, Edge and Opera and see a diverse marketplace with sufficient browser competition. They don't seem to care about the technical monoculture behind it all.
> I think Chromium out-competing every other browser engine is a bad thing.
Hmm. I believe that Apple can compete with Google if they want to. They have the money, they have the marketing chops, they have the incentive ($20B search engine deal) and they are the default browser.
(also, they have trained iOS users that Safari is the only default browser on iOS for 14 yrs by not allowing other browsers to be set as the default)
All Apple has to do is actually compete, not just rely on their monopoly.
I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
> Hmm. I believe that Apple can compete with Google if they want to.
I don't think that would happen. I don't have much faith in Apple's abilities in this area, and their incentives are structured such that the less viable web apps are as a replacement to native apps, the more money they get from their 30% cut.
Again, your arguments would make sense if my opinion was: "good guy Apple valiantly defends the open web from Google out of the goodness of their hearts". But that isn't my argument. I don't care whether Apple could compete with Google if they tried. I care whether Apple would compete with Google, and they wouldn't.
> I mean, keeping one monopoly at bay (Chromium) with the other (WebKit requirement) isn't really how this is supposed to work, right?
WebKit isn't a browser monopoly, it has less than 20% of the browser market share. That 20% share is big enough to push web developers towards making websites work in browsers other than Chromium, but it's not big enough that there's a danger of web developers thinking, "everyone uses WebKit anyway so we won't bother testing on anything else".
Sure, it's a monopoly on iOS, but I don't see how this is relevant to my argument. The web is more important to me than iOS is.
> I care whether Apple would compete with Google, and they wouldn't.
They receive $20B a year from Google (search engine deal). Some estimates put WebKit/Safari's budget at $500M. That's a rounding error away from $20B of pure profits. I completely agree that Apple is not in it for the good of the web. They are in it for $20B a year.
And even if they wouldn't want to compete: fine. Let them give up. Make room for browsers that do want to compete (or at least, let them try).
> WebKit isn't a browser monopoly, it has less than 20% of the browser market share.
That monopoly on iOS is enough, though. The web has to work on iOS because the wealthiest users have an iPhone, and all they have is WebKit. I work at a place where most of our users are on mobile, and most of them are on iOS. So WebKit sets the bar for what we can do. In other words, Apple is in full control of what we are able to do. Building features for Android users is often not worth our time and money, so we just don't build it.
Letting my users have access to the Web Bluetooth API is not making Google somehow take control of the web. If Apple won't implement it, and they won't allow other browsers on their platform, that's plainly an abusive business tactic. It's far worse than what Microsoft did by simply include IE with Windows - Microsoft never forced every browser application to use Internet Explorer. Can you imagine the outrage if they did??
But somehow Apple gets a pass, and you think they're somehow saving the web? Just stop.
You're shadow boxing. I never said Apple isn't engaging in abusive business tactics. They clearly are. I just think the result benefits the open web by taking power away from Google.
And I pointed out that they don't help the open web, they stifle innovation of the web by abusing their power for profit.
Which I think is far worse than anything you think Google is trying to do.
I'm not giving Google a free pass here, sure they can be abusive, I hated "AMP" and I'm glad it got thrown on the junk pile. That was clearly abusive. But implementing Web Bluetooth? Not abusive, it's progress. And it's too bad Apple abuses their power and stifles progress in this case.
I can't say anything other than "I disagree"; I think it does help the open web. You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance. That's a purely good outcome in my book, as much as I dislike the lack of user freedom that's behind it.
>You already admitted that you in your day job has been forced to make your site work in non-Chromium browsers thanks to Apple's authoritarian stance.
I did not say that at all. I'm not supporting iOS at all for the features that Apple won't implement in Safari. Tough titties Apple users. And why should I? iOS and MacOS world-wide are a small percentage of all users. And Apple doesn't care what their users don't get to access, so long as Apple is making money.
Apple is not the good guy here.
They are actually doing the opposite of you want, not sure how you can't see that. "The web" is now essentially all Apple will allow it to be, for their own greedy reasons.
I don't think it does benefit the open web. If consumers can't get value from the web, they'll go where they can find it. That is currently native apps, which is a closed and proprietary ecosystem. This causes the market itself to shrink, which means fewer and fewer people will invest in the web [1].
> I do, frankly, think that mobile Safari couldn't compete that well in an open market, just like desktop Firefox can't.
Couldn't compete isn't a justification to exploit platform control and ban competition. If Apple's so worried that Safari usage will fall off in favor of Chrome, then they can invest in Safari to make it a level playing field to keep their user base.
You clearly haven’t tried to design anything complicated that has to run on safari iOS. Safari iOS is a massive piece of shit. I’ve been working on a web game for a while now using canvas and most of my pain comes from making it compatible with safari. So much stuff is broken on safari so you have to find work arounds. Like a simple but annoying one, CSS filters don’t work on canvas so you have to write all those filters your self and apply them by using imgData.
Also the constant crashing when using canvas and the web audio api, it’s a disaster to be honest and it feels intentional, like they want me to write an app instead so they can rent seek.
As a non-web developer I'm interested if anyone can answer this question:
If you're designing for <X> browser, how hard is it to make it work on <Y> browser?
Answering with at least {Chromium,Safari,Firefox}
Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
What I want to distinguish is the biases in being used to programming in one environment and actual ease of programming for an arbitrary browser. Regardless of what official standards are, there are "in practice" standards, what is used in practice.
What would be nefarious is if Google is promoting people to program in ways that are not compatible with other browsers, cementing its monopoly. (This may even be achieved without explicit direction. Achievable simply by Chromium devs building tools for devs but not carrying about compatibility with other browsers). After all, the web is for everyone, but just because it's open doesn't mean monopolies/oligopolies/collusion/<other nefarious actions> can't happen.
Tdlr: does developing on chromium encourage browser incompatibility?
> Because if it's hard when targeting Chromium and adapting to {Safari,Firefox} but easy when targeting Safari and adapting to {Chromium,Firefox} then honestly it seems like Chromium is the problem.
Exactly. Test and develop against Firefox and/or Safari first and Chrome afterwards. If it’s not a true web standard and isn’t widely implemented, don’t use it.
The web worked fine for decades without smart fridge integration or whatever weird thing Google has decided that browsers must be capable of most recently.
It's not easy, though. Most of my day job is spent trying to get html interactives on an e-learning platform to work reliably with iOS's ridiculous nonstandard interaction rules around when media is allowed to play. It's worse than working with the 20 year old jsp+servlet system that serves the interactives and business logic. no other browser behaves like iOS safari and to debug and develop against it you need an ios and macos device sitting on your desk. Firefox and Firefox on Android are a breeze but a rounding-error in our usage metrics, even accounting for our development. Apple desparately hobbles the web platform to collect IAP taxes.
> with iOS's ridiculous nonstandard interaction rules around when media is allowed to play.
Are there any standard interaction rules on when media is allowed to play? I thought everyone implements it differently based on their own ideas of security and user engagement
The problem is not Google, I hate Google so I’m not white knighting them or anything but a lot of basic things are just badly implemented on iOS safari. Also if something works in chrome it probably works in Firefox as well. The only odd duck is safari and people who defend clearly have no experience trying to develop for it.
Making things work in chrome and Firefox is trivial and is never hard but when it comes to safari you have to figure out the special dance to make things work properly even when targeting it first.
No developing for chrome does not encourage browser incompatibility.
The argument which has been provided so far about why Safari is crippled is that it does not implement non-standard Chromium-only features. There are other problems with Safari, but they are not found in the page we are discussing.
I compiled a "short" list of why amd how Safari is crippled. Not entirely on topic for the post, but seems appropriate as a reply on this particular comment ;)
This article is quite literally the only one that actually discusses actual Safari problems.
And even this article falls prey to "failures in web platform tests" which are a very poor indicator. E.g. Safari passing all accessibility tests is much more important than Safari failing most accelerometer tests that only Chrome passes (because this is Chrome-only API).
Seeing that there are cross platform game engines, it seems to me that making a web game is not the best way to go. How do you plan to monetize it? Get people to put their credit card on your website? How is your web game performing on Android? Have you tested the performance on the typical mid range Android phone?
Why isn’t it the best way to go? I’m not a fan of those web game engines so I made my own.
I have various avenues of monitization; sponsored ads and letting players buy cosmetic items.
I have yet to test it on android because my priorities are making it work on desktop and iOS first and then android after. Why? because of my past experiences with making games.
Monetization? But does making your own engine “make the beer taste better”? Does it lead to a better experience for the users? Does it give you an advantage in the market?
You really don’t think you need to consider the hardware capabilities of the average Android phone?
Hint: Facebook rewrite their apps years ago to not use web based technology because performance was horrible on the average Android phone.
Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
I will eventually test it on android but I don’t see why it would not work with out any issues.
I wouldn’t use Facebook as a reference, I have an inside joke that they have the worst programmers. They managed to make a site that shows text and images make my computers fans spin which is honestly just embarrassing all things considered.
You really don’t see how inefficient it is running a game on a web browser compared to a game engine running native code for the platform? And you think you are going to write a better performing game engine in a web browser?
> Yes it does because it’s optimized and efficient because there is no bloat, everything in the engine is there to serve this specific game.
Everything is there to serve your game except the entire web browser.
You can still build a PWA and get most of the benefits (I use a few PWAs on my iPhone daily). Or you can package it through Expo and rely on the Reader app exception without letting users sign up on iOS (although the rules around that are changing and you might be able to).
I get the gist of the article but what specific features do you need to let people just use your app as a PWA on iOS? Do you need access to the NFC, for instance?
> They are forcing me to write a native app instead of just tell my customers to install Chrome to have access to the APIs my product needs (web bluetooth).
Why don’t you encourage them to get an Android? What makes you think that people who prefer an iOS device over Android would even install Chrome after you nag them with dark patterns?
> I also do not plan to sell anything through my webapp, which is why Apple wants to force developers to create a native app, where they can collect 30% (or whatever % it is now) of anything sold through the app.
Sorry, not following you: Apple is forcing you to give them 30% of nothing? How exactly is that a problem?
> Apple are just being greedy assholes and what they are doing is absolutely worse than what Microsoft did to get sued in an antitrust case when they simply bundled IE in Windows.
Yes, how dare Apple look after their [checks notes] customers by preventing devs from using the features that would most annoy their customers?!? Such a greedy thing for a company to do, to give customers what they want! The only true purpose of a company ought to make it easy to slurp up customer data and monetize eyeballs!
That people would use Firefox on iOS. That fact. Do you know English? It seems like you understood what I said, but still had a hard time comprehending it. Are you okay?
Guess what? You not having the resources to have anything but a shitty PWA is not my problem.
Do you really think that you are going to get any level of monetization by forcing users to first download a hypothetical web browser that has all of the features you want? That web browser doesn’t exist on any mobile platform
You have no idea what my web application is, or whether it is shitty or not. So thanks for the troll - it reminds of my days on reddit, but now this pointless internet interaction is over.
No it's not. The percentage of people who actually can use alt stores is so small that nobody will really dedicate money to make browser build for iOS. Why would they when Apple would just make the work impossible anyway.
It's pure malicious compliance from Apple. Anybody defending Apple on this is simply delusional.
Browsers with alternative engines can be offered in regular AppStore. That's why I wonder why isn't this a thing. At the end of the day, browser makers probably want to reduce confusion and complexity of maintaining two vastly different applications under the same name. This most likely isn't a case of malicious compliance, you got yourself carried away here I think.
I think the main technological limitation is that other browsers cannot just-in-time compile (JIT) JavaScript or any other embedded language. Except in the EU.
ETA: your link includes JIT; I’m pointing out that that’s why they don’t exist outside of the EU. Non-JIT browsers would just not be very performant.
Now it's straight up protectionism from USA. You touch our tech margins, we won't do business with you. So yeah the regulators are unable, even if they wanted to something.
Doctorow is right when he keeps saying that countries should make it legal to jailbreak devices. The problem is that first country that tries that will get hammer from the almighty POTUS.
Because it’s essentially propaganda. By conflating “Not Implementing something Google did” with “Intentionally Crippling”, they hope to pressure Apple by through either the general public (the PR game) or through Government mandates (the lobbying game).
This has been going for at least as long as Blink was forked off WebKit.
And why Apple? Because Apple’s the only other browser giant, and they do have motivation to not implement a lot of these features. Frankly a lot of these are features I don’t want in my fucking browser either. But web developers, and businesses that predominantly rely on the web (such as Google) want as many complex APIs as possible implemented in the browser.
> why I would actually want most of these features in the browser
The page is about PWAs, applications that can be installed by the browser rather than the platform's App Store. Native applications already have those capabilities and a lot more.
Some of Mozilla's positions are based on Apple's, such as the refusal to implement Web NFC [0].
Since Webkit has been the only engine allowed on iOS, ultimately this is a disagreement on app distribution. I can see Apple and Mozilla's argument regarding Web NFC, but I also don't want to write a whole app so my friends and I can play around with NFC tags. I find it irresistible to draw comparisons to the new Android situation regarding non-Play Store apps. If there was a developer registration list for websites (that was better than DNS registrar records and TLS certificates), would Apple and Mozilla find that acceptable? After all, I need to give my real name and payment details to Apple just to write an app.
But for good measure I will add one for Mozilla too. Firefox Android still doesn't support the Web Codecs API [1], so I need to use the "jpeg" codec on Selkies remote desktop sites, which I assume is rather poor for my bandwidth and battery.
And chrome still does not support plugins on android, to my great surprise, while Safari has them on iOS. I honestly much rather have plugins than web nfc, or whatever the chrome bully decide should go in a browser.
Google’s choice to exclude extension support on Android can’t be a coincidence. Great example of conflict of interest with a web ad giant running a web browser.
It doesn't have to be an either/or situation and I certainly want both in my mobile browser!
Ad hominem is also not a valid argument against NFC. One of my friends built a whole automatic mahjong table with NFC tags. NFC apps are used in access control for offices, college dorms, apartment complexes. Businesses have obvious use cases for it, from inventory management to payments. Governments want to use NFC for government functions and visitor prearrival processing. Sure, maybe some of them want you to install apps for other reasons, but I can assure you not all of them do, so it's a shame that this function is so exclusive.
I think western users using NFC for payment, transit, gym access, etc. are not aware how apathetic the rest of the world would be if phones start taking out NFC, and one of the ultimate causes is that it's so difficult to work with across all users. It's just so much easier to make a website that shows a QR code that your PoS system or gym access gate can scan. Bottom of the barrel Android phones in India and China already ditched it and that's just going to exacerbate the issue. If it goes the way of the 3.5mm and microSD card in the next decade, we can put this in its autopsy report.
The third column is your current browser and platform, and for me it's showing Firefox on macOS missing a lot of features. When I switch over to Brave, I see Chrome on macOS. Interestingly, Chrome on macOS apparently supports vibration, despite the hardware for it being nonexistent.
But on macOS you can switch to a browser that can do all these things. A company could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable).
Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add web features). Apple is not just gatekeeping native (through the app store), but its competition, too (the open web, through the webkit requirement)
If you ask me to run a different browser, if at all possible I’m going to use a more reasonable competitor instead. I’m not about to return to the bad old days of sites badgering me to install IE because the dev thought it was a great idea to use ActiveX or whatever.
I'm not trying to defend Apple's decisions, I'm merely pointing out that the site is showing the feature support that Firefox has or doesn't have on macOS, or whatever other platform someone is using to access the site.
No, because any browser can decide to ship a feature that it thinks is worthwhile. Users can decide which browser they trust to be their User Agent. The distribution model is open. You type a URL, you click a link. No single company in control.
> No, because any browser can decide to ship a feature that it thinks is worthwhile.
Yes, yes they can. They don't get to call it standard or essential. And Chrome-shilling sites like the pwa.gripe and a slew of others don't get to call those features "essential standards of the web".
> No single company in control.
That is literally not how standards work in the browser world by literal agreement of all browser vendors.
We literally lived through this with IE pushing its own non-standard features and calling it a day. Hence the whole "let's reach a consensus, and have several independent implementations of a feature before calling it a standard".
And if "no single company is in control", why then you're so enthusiastically pushing for a Google's full control of the web?
While true, that does not seem to align with what the checkboxes for firefox, looking at many of the ones that Safari does not support other non chromium browsers don't support on any OS. Mobile or not
The difference is that, on iOS, you can't switch to a different browser that does support these features. Om very other OS you can.
A web app could ask you to use a different browser (not ideal, but if the web app requires a specific API, it's not an unreasonable).
Safari is in a very special position because it controls what the web can do on iOS (all browsers on iOS have to use Apple's WebKit engine, they can't add web features). Apple is not just gatekeeping native (through the app store), but its competition, too (the open web, through the webkit requirement)
True, but putting aside that limitation on iOS for a moment.
The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.
Which is where whether or not any non chromium browser supports any of these on any platform. Which many of these features they don't.
That completely changes the conversation here, from Apple purposefully ignoring standards to Google pushing things that are not standards yet. Which I will admit that the reality is a bit of both here, but it should not be considered a negative when a browser does not support a feature that is non standard... we heavily criticized IE for exactly this and yet we celebrate Chrome for it?
>The very important part about this is whether or not these features are actually considered a web standard or is it Google pushing their own agenda.
Apple is on the W3C board that gets to decide what APIs become standards, so Apple is definitely pushing their own agenda on the W3C.
So you can't really complain that Google is pushing their own agenda with these APIs when Apple is the one refusing to make them a standard. In this case, Apple is the one doing shady shit by holding back things like web bluetooth for no good reason. No, "security" is not a reason, this API has been in use on other platforms for a very long time with no real security issues.
There are lots of other standard APIs that have been implemented, but Apple refused to let the ones that eat into their app store go forward.
>we heavily criticized IE for exactly this and yet we celebrate Chrome for it?
I remember when IE implemented XMLHTTPRequest, and it did a lot of good for the web.
I also remember when Microsoft got an antitrust case for simply bundling IE with Windows, yet Apple seems to get a pass for forbidding all other browser engines on iOS? Well, fortunately Apple has its own antitrust case in the DOJ now for its own abusive business tactics.
Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?
We really need to stop putting google on a pedestal as if they are truelly on the side of an open web, like every company they are looking out for their own interests. Which is fine, they are allowed to do this.
That doesn't change that many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is. A discussion about why it may not be standard is worth it, but that is also a very important distinction that is not made on this page. Right now it is framing it as google supports a standard that the other's (including Firefox) do not.
Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX
> many of these are in fact not a standard according to W3C and should not be implemented in any browser until it is.
That's not exactly how standards work. A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:
"Working Groups don't gate what browsers ship, nor do they define what's useful or worthy. [...] In practice, they are thoughtful historians of recent design expeditions, critiquing, tweaking, then spreading the good news of proposals that already work through Web Standards ratified years after features first ship, serving to licence designs liberally to increase their spread."
> A browser (or anyone) comes up with a spec, a browser can ship it (to test the waters in an origin-trial, to gain traction if they believe in it), and the standard (often) comes after the fact:
1. Google often doesn't bother even with a spec. Or it creates a semblance of a spec, throws it up on a googler's Github account, ships it and advertises it as "emergin standard" on web.dev
I mean, the status of many (if not most) of the APIs that these sites push are literally "napkin scribble, not on any standards track".
2. Google pushes a lot of APIs quickly into production even if there's a very explicit open objection from other browser vendors (any objections are routinely ignored: from general objections to the shape of APIs to whether it can even be implemented outside Chrome).
3. I wouldn't really quote Alex Russel on anything related to standards, as he is responsible (directly or indirectly) for quite a few of those because of his work on Web Components. E.g. Constructable Stylesheets were shipped in Chrome because Google's own lit project needed them. They shipped it in production when the design contained a trivially triggered race condition, it was called out, and Google completely ignored it because "users want it" or something.
4. Browser vendors quite literally agreed not push incompatible only-exists-in-one-browser shit after the browser wars. The whole standards process is designed to minimize this. Well, Chrome is the dominant browser, so of course they shit all over the process, and quite a few people cheer them for that.
Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them
Chrome in the 2010s-2020s: shits out a bunch of own non-standard crap, people cheer and blame other browsers for not implementing this crap because... Google is "the champion of open web" or some such bullshit.
> I'm sorry, but that doesn't seem to be right. They have a process:
Yes, they do. It's their process, and their timelines. Many features on the page we're discussing are literally "drew on a napkin, not part of any standards process at all, shipped in Chrome"
3. So what, bugs can be fixed. It's nowhere near as abusive as what Apple does by forcing Safari on every iOS browser.
4. You think the "browser wars" are over? Apple's actions clearly indicate the war is on, and they've selected the nuclear option of forbidding any other browser on their platform.
>Internet Explorer in the 2000s: shits out a bunch of own non-standard crap, people boo them
Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.
When you deliberately ignore what Google is doing, every view that is not praising Google's take over of the web is skewed.
> So what, bugs can be fixed.
No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
> Did people "boo" XMLHTTPRequest? Because it actually revolutionized the web, and people cheered it.
And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
>every view that is not praising Google's take over of the web is skewed
I am not praising Google. I'm simply pointing out that Apple is using abusive business tactics to prevent any competition. It's antitrust territory, and the DOJ agrees. I don't care which browser implements the APIs I need to access, so long as one of them does.
>No. Not on the web they can't. Once it's shipped, people depend on the functionality. That is why we're stuck with so many crappy unfixable APIs in the platform.
Just more skewed nonsense. This can and have been fixed on the web. I've had to reimplement countless APIs for all kinds of services. There are new APIs that make old ones deprecated all the time. Maybe you should try to keep up instead of stagnate like Apple is.
>And yet, they didn't cheer ActiveX. For some reason you assume that every single API Google pushes out is XHR, and not ActiveX
Just more bullshit from you. I'm tired of it. You aren't even attempting good faith arguments.
>Google is also involved in W3C and do I really need to bring up the topics API as Google attempting to use their position to push their agenda as well?
How is Web Bluetooth an evil agenda of Google??
It's making web browsers more capable. It's not some evil conspiracy to enrich Google. If Apple wants to let the W3C move forward in making it a standard, then all browsers would benefit, and all users that would like to use a bluetooth enabled web-app would benefit.
The only one that benefits from not allowing it to become a standard is Apple, because they get to force developers to make a native app, where Apple can extract a % of sales through the app.
>Just because Google does something it doesn't mean the rest of the industry should follow. If we did that in IE days we would still have ActiveX
IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0". Everyone was glad that they created it, standards or not when it was first implemented.
If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.
Never said it was, notice how in the thing you quoted I said "Topics API"? That is extremely evil and was only introduced to benefit a single company, Google.
I never made a claim that every single thing on this list that safari does not support is a negative.
> IE was the first to implement XMLHTTPRequest. It changed the web fundamentally, and was the basis for "web 2.0".
Fantastic, that is an example of things working as they are supposed to work.
However IE also introduced things that were not made standard just as equally we celebrated that those things failed.
> If we didn't have browser manufacturers pushing the limits, we'd be stuck with "web 1.0" and browsers that did nothing interesting outside of loading animated gifs of dancing babyies.
Obviously that is true or the companies would not be involved in W3C. But that does not mean that every idea they introduce is necessary in a browser and deserves to be a standard feature. Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.
If everyone is in agreement instead of it benefiting a single company.
> The only one that benefits from not allowing it to become a standard is Apple
I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop. Your argument does not support why Mozilla has not implemented this feature. Which again, makes the "Apple bad" spin on this not as cut and dry.
>Google alone cannot and should dictate a standard, even though apparently we are fine with them attempting to do just that.
They did not "dictate a standard". They saw a good use case for an API and made one for it (Web Bluetooth is what I'm really focused on). If the other W3C members want changes made, then they can make suggestions, and Google or someone else can implement the changes. They can even implement their own API and have a discussion about that. Then they can put their heads together and come up with a spec everyone agrees on. That is how it normally works. Nobody "dictates" as you suggest.
Apple is flat out refusing to let Web Bluetooth move forward based on "Security rEaSoNs", and they are just shutting down the entire feature set.
Where is the security risk when users have to explicitly opt-in to use the feature? I'm sorry if your grandma clicks yes to everything, but blocking my users from the entire feature because your grandma lost her mind years ago is asinine. There is no real security threat posed by Web Bluetooth and I'd love to see you argue how there is when plenty of other existing APIs already ask for permission before you can use them. Fingerprinting can be done in a lot of other ways.
But the real crux of the problem is Apple not allowing other browser engines on their iOS platform. If that changed, I wouldn't care what one company implements or blocks in the W3C.
>I would like to point out, once again. That this feature is also not available on Firefox for Android or Desktop.
I don't care at all what Firefox does or doesn't want. Neither do most people. Firefox also does not block other browser engines from running on iOS, so people are free not to use it. Unfortunately we're not free to use the browser engines we want on iOS.
You continue to dwell on Bluetooth while ignoring that there are reasons to not just blindly follow Google which is what pages like this are advocating for. I honestly don't care about Bluetooth and I don't have any stakes on whether or not it is supported, and I also don't know enough about it to actually talk about security on it. I will leave that to people that actually know what they are talking about instead.
I would love if you can actually respond to Topics API and other initiatves that google has attempted that only furthers their agenda, just like you are saying Apple is doing. The fact is both companies are incentivized to do exactly that, and as I have already said both companies do this, and yet you seem to want to give Google a free pass and ignore when they have been problematic.
Regarding Firefox, them not implementing something is a very important piece of the puzzle and you cannot choose to ignore them just to try to strengthen your own argument. This is my fundamental issue with this page since they do not by default show Firefox because it completely breaks the "Apple Bad" narrative they are trying to push.
The fact is, Firefox on both mobile and desktop has not implemented many of the same API's that Safari has not and in some cases has implemented less. The Why there is extremely important because it directly impacts the conversation. Mozilla does not have any of the incentives that either Google has for pushing these features or that Apple has for not implementing them and yet they have chosen not to implement them.
I do find it quite fascinating that you have written this phrase 5 times in this thread instead of actually being able to engage in a conversation you disagree with. Frankly it's not cute.
Sure it is pointless but you also chose to start engaging in the conversation since you were confident in what you wanted to say. Just as I am.
On multiple occasions you are purposefully ignoring what people are saying and attempting to just talk about something else. I have acknowledged your bluetooth comment but you refuse to acknowledge topics api or any other instance that Google has also used their power to try to do exactly what you claim Apple is doing.
Google is not your friend, neither is Apple. And you may not care what Mozilla does but W3C does so they matter and they don't have the incentives Apple does and yet they also chose not to implement many of the same features, which you also won't acknowledge.
There is much more to a web browser than just its rendering engine. When you install Firefox on iOS, you get Firefox. It uses the WebKit rendering engine, but it’s still the Firefox browser.
To be frank, it’s pretty insulting and dismissive to all the people putting huge amounts of work into building browsers only to for you go around telling people that all their work is really just a mirage.
The problem is that it has to use the WebKit rendering engine, and not that it happens to.
I think it's more insulting to browser vendors that they have to throw away their browser engines to appease the monopolistic tendencies of one company.
It absolutely is a mirage. It's like those Ferrari kit cars where you take a Ford or whatever car frame and remove the outer shell and put a Ferrari shell on top of it. It's not a Ferrari, it only looks like a Ferrari.
The browser engine is the majority part of the browser, everything else around it is window dressing. So when you install Firefox on iOS, you are getting Safari with a thin wrapper around it. You are not getting the Firefox rendering engine, which is the most important part of a web browser.
I think anything that mentions Apple in a negative light gets reflexive upvotes.
I use both Apple and Android ecosystems, so I’ll occasionally participate in normal user conversations about features, how-tos, etc. Posting anything about the Android ecosystem, unless I was talking about Samsung features I disliked using, is no more or less likely to get down/upvoted than anything else I post about any other technology. Using any tone more positive than a negative-leaning neutral when referring to any Apple product reliably collects a handful of downvotes, and often a negative comment or two. Same thing with negative sentiment and upvotes. I’ve never seen such a passionate dislike of a corporation among a small number of people. Even with famous brand loyalty rivalries like Ford/Chevy in the 80s and 90s it was more mutual. It wasn’t like 99% of drivers not giving a shit, .5% of Ford users being smug, and 2% of GMC drivers just being super mad at a product they don’t own.
I don't think you're wrong, but what's especially interesting about this is that up until just a few years ago, it was completely the opposite. Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times. Having been reading HN now for ~13 years (I lurked for years before starting to participate), that's been my number one dislike about HN is the complete inability to have objective discussions about Apple. At one point I even wrote a quick browser extension to filter out posts that had Apple in the title because it was so nauseating. Ideally the pendulum wouldn't swing, but instead would just settle in the middle, but alas that just isn't human nature.
> Giving any criticism of Apple would get so many rapid/reflexive downvotes that it often killed the comment before many people even got a change to see it. I experienced it myself a number of times.
I’ve never found myself in any online community that meets that description. Certainly not HN, and HN hardly seems big enough to have Apple fanboy niches that you could accidentally find yourself in.
In the heyday of Steve Jobs’ Apple there was certainly a lot of praise here, but also constant prominent complaints about Apple being overpriced, or not open enough, or too litigious, or having too many fanboys.
I’ve seen way more complaints about Apple fanboyism than actual fanboyism. I’m genuinely curious how you could find yourself in one of those communities by accident.
Same. I have always found people talking about the hoards of rabid Apple fanboys but I’ve just never seen it in the wild. That’s even having been critical of Apple countless times over the years going back to the mid 90s even before Slashdot, let alone OS X. I’ve obviously seen the odd Apple fanatic out there but less frequently than , say, Linux evangelists or zealots for any given gaming platform over the past couple of decades or sports teams or cult band followers. Maybe in, like, the Apple subreddit? Brand subreddits are always where fanboys live for everything.
I think it’s a combination of underdog vibes and confirmation bias that people have adopted as a community identity.
I am still quite shocked that anyone looked at the side by side images within Nvidia and actually thought this was good and no one would have an issue with this.
Now I will admit that if you don't compare them, the final image looks ok. Like if I did not know what was happening I likely wouldn't give it a second thought. It looks off but so many video games already look off that I don't think I would have really thought anything other than "well it's a video game".
But when compared to the original image it is so obvious that the artistry and the original intent is just completely lost.
They claim that the developers and artists have more control over this, well maybe if that is actually true (because we all know guardrails on AI have been perfect so far...) they should have been involved in using that control for the video showing this off. Otherwise I honestly hope this never ships.
But even if it does, the power requirements for this make it kinda DOA anyways.
As demoed, it's obviously very bad. But before giving up on it completely, I'd like to see a version that can remain faithful to the original color grading and tone mapping. Those changes affecting the overall look of the whole frame really distract from comparing the more subtle lighting differences where they might be onto something good.
But I'm also skeptical about whether they can pull this off in a way that doesn't exacerbate the already-severe issues DLSS has with latency and temporal stability. Enhancements that make for great screenshots often don't translate to great realtime gameplay.
An issue I haven’t seen anyone bring up: how are they going to keep the randomly generated sexy new AI face for the characters consistent between shots?
A frame of the character shown 20 hours into the game doesn’t remember the random generated sexy face it gave that character 1 hour into the game.
Well, because I'm not getting 80-100ms latency. In a first-person shooter, 100ms would be 6 frames and make the game basically unplayable with a mouse. Also there's nothing intrinsically expensive about DLSS to cause such a latency. I suspect something is wrong with your setup?
If you dont believe me you can look up latency tests for it. without DLSS rendering is ~15ms. With preformance mode DLSS that raises to about 30-35MS. Balanced is about 60ms and beautiful is 90-100ms input latency.
Gaming isn't even a side project for them anymore, last time I checked it was under 3% of their revenues, I wouldn't be surprised if it's under 1% now, I don't think they care much if at all about this domain anymore
I have been waiting to for the next version of the Max for a while and I am disappointed that we still don't have some sort of wireless charging solution for it.
My biggest issue with the Max I have now (and why they just don't get a ton of use) is keeping them charged. I would love for a dock or something. I know there are third party solutions but they require putting a little plug into the plug in the headphones, and it is not hard to find issues that people have had with those so I have not done it.
An official solution from Apple would be amazing, something as simple as what the Astro A50 does.
I am... cautiously optimistic without Whedon being involved. But also very curious how this will work since it doesn't seem like it's a reboot, unless I missed something.
Tara Butters from Dollhouse being involved makes me a feel a bit better, since I love Dollhouse (actually rewatching it right now). Now I can only hope this actually succeeds and maybe Dollhouse can get similar treatment.
I am sure some will be upset that it's animated, but if that is what it takes (and it turns out good) I'm fine with it.
Okay so a little bit of out of universe trivia on Dollhouse: It was planned for 5 seasons. With the risk of cancellation, the second season and the two Epitaph episodes were a severely compressed telling of 4 seasons of plans. And, personally I think it worked well. Something similar happened to Babylon 5, Manifest, Jericho (IIRC), Firefly (Serenity was the original ending that would have played out over multiple seasons), and the Escaflowne anime: the main plots towards the end got compressed to create a faster pace at the climax while ensuring the story could be finished (though I wasn't a fan of how Manifest ended).
My concern about original writers being involved in reboots is if they want to fill out the story they couldn't tell the first time around and end up with a more standard pacing that's less exciting, and end up getting cancelled before finishing. Then we end up with things like Tru Calling and Dark Matter, which had planned plots they couldn't finish.
I think it worked well with the Epitaph episodes being as short as they were. I don’t think I’d have enjoyed that much darkness for many seasons. They were great though, to show sobering consequences of what they were toying with.
My best guess based on another good series with a similar 5-season arc, the 3rd season would have been when the main characters realize Rossum's larger plans (Topher's breakdown when he puts together schematics from the individual Dollhouses, or the visit from one of the execs using Victor's body, for two examples that did make it into the series), 4th season would have been the dark one when everything goes to crap, and 5th season would have been the hopeful restoration of Epitaph One / Two.
The only thing I remember reading for sure is, the 2nd season would have largely been about exploring what was happening to Echo because of what occurred in the 1st season aired finale (episode "Omega") - which did happen, but it I don't remember it dominating the season. Didn't sound like it would have been a dark season, but looking back on it seems like it would have been painfully slow.
They could also just implement sign in with apple on their website, they have the ability to sign in with google so not supporting Apple is still a weird choice they are making.
Apple should not have had to require developers to have options other than Google for authentication, but clearly some companies have to be dragged kicking and screaming.
So clearly they support it, and there is no reason it should not work on the web also.
There are a lot of websites that only support third party login, so that is not always an option.
They don't have to bend for another, but they made a choice to put an app on iOS. They added support for apple signin, and then for some reason did not put it on their website.
You can criticize Apple for requiring that all you want, but they clearly have support for it and are choosing to not put it on their website which is causing a worse user experience.
IF apple did not support website loggin than sure, but they do. So the ability to fix this is on Anthropic (and many other websites).
If you are already going to support third party login you should not limit it to only Google accounts and there is no reason to support Apple on iOS and not the web.
Also for the record, Apple only requires sign in with apple if you already support third party authentication. So if you are already going to support that, giving the user more choice (and making it so we are all a bit less dependent on google) is a good thing.
No criticism from me towards apple or Anthropic. Both parties made their choice. Apple was late to the identity business and the other ships had already sailed.
Third party logins are an extension and a massive risk to any website that doesn't include email hosting.
We have see identity providers dissapear, and people may change their mind.
Easiest way is to register you rown domain and use it with an identity provider of your choice and be able to move it anywhere.
Otherwise we are a faceless citizen of a corporation that can handle access to our identity and everything attached to it without recourse or access to anyone.
Are you seriously trying to justify offering Sign in with Google but not ALSO offer Sign in with Apple because of some contorted principle, the method which HELPS users maintain their privacy? What the actual f.
Antrhopic's UX is just trash, the worst of all the major AI products.
They have this "I'm special" syndrome where they think they can get away with doing shit weirdly and not offer basic features that everyone else does, and the reason why I never purchased any of their services again after the first month, and had to replace my payment info with a throwaway card because they wouldn't let me remove it, again unlike everyone else.
I don't think it's hard to understand why a service would want to support Google as an identity provider but not Apple. Google is probably the most commonly used provider out there, at least outside of the enterprise space.
Apple's identity service is not as common, and newer than the ones that were established before.
It's ok that Anthropic wasn't a fit for your prompting preference, it doesn't have to work for everyone, and it doesn't mean it wont' work for others. LLMs in general have proven that trying it once a few months ago can be a great way to miss changes. There's something out there for everyone.
This was my first thought as well, all this does is further remove the user from seeing the chat output and instead makes it appear as if the information is concretely reliable.
I mean is it really that shocking that you can have an LLM generate structured data and shove that into a visualizer? The concern is if is reliable, which we know it isnt.
Its' a reasonable concern. Often it can be mitigated by prompting in a manner that invokes research and verification instead of defaulting to a corpus.
I am still sad that they stopped putting it into iPhone, I think the tech is great and the watch really proves what can be done with it when it is a fundamental part of the hardware and the OS can be built around it. But we never had a situation that every compatible iPhone had force touch so everything that could be done with it had to work in other ways.
I think the iPad made that even more complicated since I doubt we would have ever gotten it on a screen that large, if it would have even worked.
As far as it being on the trackpad, it is honestly pretty wild when you realize it. It does an incredible job of faking feeling like it is actually moving. Was similar with the fake home button that some iPhone’s had for a little while.
I remember being totally flummoxed when I was trying to figure out why my trackpad wasn't clicking when the machine was off. I had no idea it wasn't a mechanical lever anymore!
I know it is not the target use case this, but I have been thinking more and more about how this could serve a need of a terminal or a kiosk computer in a scenario where a tablet may not be the most suitable due to the need for a full keyboard.
I use an iPad mounted to an arm in the kitchen for cooking but always had issues whenever I needed to modify a recipe (or add a note for later modification), I am debating on switching it out for a Neo. Possibly some other use cases of a permanent computer in places that a tablet worked but a full computer would be far more flexible.
I just first need to find an arm that would be rock solid enough to not wobble a ton while typing, if anyone has any recommendations.
I keep wanting to build this but I have seen people talking online that they changed the legs and they are now hollow and not really suitable for this.
That has made me very cautious to use this for any serious amount of mounting.
Edit: Apparently there is a section on that page about it, but does not give a ton of confidence that it won’t give me a lot of issues.
I swear every year that passes it sounds more plausible that IKEA has a bunch of people chewing on wood and putting it together into furniture like they were building wasp nests. Their stuff makes frickin' papier-mâché look like a steel girder in comparison.
I have an old Lack (20 years) and while I've never used it as a rack, it'd just been retired from under the TV as I got a new one with a wider base. I notice that even though it's never been moved much, it doesn't feel very stable any more and I wouldn't trust it with a rack of heavy equipment, especially with HDDs that could suffer catastrophic failure if they fell. That said, attaching brackets would sure up the legs a bit. Ideally you'd want to attack brackets at the back as well I guess.
I also had a Billy sat next to it, and did similar to this (but again not racked), with all of my AV gear inside. The door was great, it'd make any status lights diffuse and so they wouldn't interrupt watching a film in the dark (and my old Sky box used to have annoying blue LEDs with an animation when playing back a recorded show), but at the same time remote controls still worked through the glass. Literally best of both worlds. I cut a big hole in the back for cables, which also served well for airflow. I considered adding a fan, but never needed it. I suspect there would be issues with negative pressure doing that though.
The tops of the posts are still solid. You could mount a single rack unit and be okay, but fully populating lack legs is not recommended. Cute way to hide a network switch, though.
Because they were basically OEM'd PCs with an Apple logo at one point, and used it as a selling point, but I don't think it was a particularly popular feature among the general userbase. I've personally seen more Hackintosh laptops than Macs running Windows.
That being said, I am not sure why I would actually want most of these features in the browser? Many of these things feel like they further complicate what a browser is supposed to be doing and opens up security concerns at the same time.
I think the idea of using a web app for many tasks instead of apps is fine, but I don't think the idea that a web app can do everything is the way to go.
Edit: To be clear about the Firefox comment, notice that many of the features that are not supported non chromium browsers don't support on any platform. So the question on whether these are considered web standards is outside of whether iOS allows other engines.
Edit again: Apparently the third column is based on your current browser instead of always comparing chrome, mobile safari, and firefox like I assumed. I am currently on Firefox on Windows, and there are more red X's under Firefox for me. Seems like a weird choice to not always compare all major browsers.
reply