Regardless, Safari 16.4 is astonishingly dense with delayed features, inadvertantly emphasising just how far behind WebKit has remained for many years and how effective the Blink Launch Process has been in allowing Chromium to ship responsibly while consensus was witheld in standards by Apple. It simultaneously shows how effective the requirements of that process have been in accelerating catch-up implementations. By mandating proof of developer enthusiasm for features, extensive test suites, and accurate specifications, the catch-up process has been put on rails for Apple. The intentional, responsible leadership of Blink was no accident, but to see it rewarded so definitively is gratifying.
I found this pretty boggle-worthy - the repeated use of the word “responsible”, painting blink/chrome as such a bastion of good internet citizenship while pushing their own standards, several of which have serious end user privacy concerns (web usb, etc). I mean, how dare everyone else not ship chrome’s de facto (“we have market share, so we can make our own standards”) standards right away?!
After clicking “about” on the blog it makes a bit more sense how/why the author might make such an assertion.
Yeah. I also note that the “delayed features” that are supposedly holding back the “Open Web” are on average things that landed in Chrome in 2018-2019. It’s as if the browser-pushers want us to think that the web of 2018 is obviously intolerably backward and unusable. Bro, please.
It may have snuck up on you, but 2018 was five years ago. I would count a feature that fails to land on major platforms for that long as effectively dead. It’s not that 2018 was the stone ages, but you don’t want to be in 2018 forever.
Other than security upgrades and fixes, why not? What have we gained in the 5 years since that hasn’t primarily been in service of companies like Google extending their data gathering / advertising pimpage?
A lot of mobile web apps are DOA without the Push API which shipped in Chrome in 2015 and Firefox in 2016. They are a big part of this Safari 16.4 release.
Chrome may be abusing its dominant status to push defacto non-standards but Safari is actually very behind.
A royalty-free video codec that isn’t ancient and doesn’t suck. HTTP3, which makes a real difference to performance, especially on iffy connections. Lazy loading hints so that heavy content doesn’t have to be loaded unless the user is actually going to see it (without lag-inducing JS hacks). Motion sensing support for phones (or whatever devices have gyros/accelerometers.). Tools for making layouts that aren’t ass-backwards when the content is in an RTL language. Some more stuff in general for making pages that look nice even without a gigabyte of tool-generated CSS and JS.
And of course, every millennial’s favorite, the ability for a media query to check whether the system-wide “dark mode” is enabled.
One of the most important things about an open ecosystem which ties in closely to responsibility is sustainability. The level of resources Google puts into adding features into Chromium is nigh-impossible to match sustainably. This isn’t to say that Apple doesn’t have a) the resources, or b) reasons to de-prioritise features, especially ones that duplicate native application functionality to their lucrative App Store, but even MS pulled out of this game with a reasonably competitive modern browser engine in EdgeHTML.
Given how much sway MS/Google have over the browser market with their position in WHATWG and Chromium/Blink’s market share, it’s not really much better than the “dictated standards” of the past, like PDF or OOXML - having an open spec to meet regulatory requirements many governments have about “open data standards”, but driven entirely by stakeholders who effectively control that ecosystem.
It’s the old “Fire and Motion” strategy that Joel Spolsky used to write about in the context of Microsoft. Google can simply fire bursts of new “standard” features at everyone else, and then blame competitors for being unable to keep up. And developers will happily take up the chant of “Safari is the new IE! The new IE! The new IE!” despite the fact that it’s Google and Chrome using the old Microsoft tactics.
I know this is the most unoriginal, most oft-repeated point, but I’ll say it anyway. And I say this as a very long-time user of Firefox on desktop. Browser choice is objectively less important to the health of the web than in-field browser diversity. And Webkit’s exclusivity on iOS is now unequivocally the last stand against a browser engine monoculture.
It’s like we’ve all forgotten why the MSIE 6 era was so bad, so unhealthy. This should be obvious to anyone who has studied browser history. It wasn’t because Microsoft was denying browser choice. The problem was the lack of in-field browser diversity. 2002 was the closest we ever got to single-browser dominance, and it was fuelled by developers who treated Internet Explorer as the platform, rather than web standards.
It’s amazing how so many people are now complaining about Safari not keeping up with Chromium, seemingly hypnotised into believing that whatever Chromium does is the definition of web standards. By that definition, all other browsers are behind. By that definition, control of the web platform is ceded to Google. Sorry but no. I like that Safari is taking a more considered approach. I like that it isn’t racing ahead at maximum speed. If you disagree that’s fine, but understand that yours is—like mine—just another opinion.
seemingly hypnotised into believing that whatever Chromium does is the definition of web standards
Unfortunately, due to Google setting the agenda for WHATWG, and Microsoft backing them up, “whatever Chromium does” basically is the definition of web standards today.
For several years now at least, I have already been comparing the experience of trying to solve for safari quirks (especially for iOS) to trying to keep IE 6 happy.
I am not a hater; safari on macOS is the browser I use most and prefer.
But it’s got problems, and they tend to malinger for years. I agree that we don’t want a monoculture, and I’m happy with the pushback on privacy issues related to new APIs, but I’m not sure it will ever be long-term tenable for a browser to be the only reason a site/project is forced to test UA strings.
I would argue that any future where web developers think they don’t need to test in more than one browser is a web dystopia. We know this because we’ve been there before with Internet Explorer.
By testing UA strings, I don’t mean to imply that developers shouldn’t test their sites in more than one browser.
I mean that having code that checks which UA is in use in order to treat them differently (at least, in a codebase that would prefer to be testing feature support instead of UAs) is a smell that one or more of them might be broken or have conflicting implementations that we’re left to work around.
Firefox is at an all-time low of relevance. WebKit, by being the default and only browser engine on the iOS platform, is effectively the only thing between Google and a complete Chrome monoculture in which “Web standards” are redefined as “whatever Google felt like shipping in Chrome this month”, and anyone who uses an alternative browser engine will be served a “To continue, please download Chrome” banner.
This doesn’t mean that the way iOS is managed is good. It just means that, at the moment, it’s the lesser of the available evils. But don’t worry – the EU is doing its best to ensure victory for the greater evil via regulations which will break Apple’s “monopoly” and usher in the permanent unbreakable Chrome monoculture.
Seeing a restriction on user choice as providing for a greater freedom is just quite a take.
Dismissing Firefox is just giving into the WebKit monoculture that Blink is part of. A year ago Firefox & Safari both had about 10% on desktop. Now allowing Firefox on iOS means that Mozilla can’t offer a browser across many peoples’ set of devices, harming their ability to innovate. And for my many misgivings about Mozilla’s leadership, I trust them more than Apple to care about peoples’ privacy and freedom.
Would freedom be helped if for “security” reasons the next version of macOS didn’t allow non-Safari browser engines?
Firefox is, from a practical perspective, not relevant. Its market share is small enough to pose no serious threat whatsoever to Google/Chrome, especially because Google is its primary source of funding.
Safari has enough market share and Apple enough financial independence from Google that web developers cannot ignore it and go Chrome-only. It has that market share because of Apple’s iOS policies.
No matter how much you personally dislike Apple or Apple’s policies, these are simple facts about the market. And I do indeed believe it is the lesser evil compared to a permanent Chrome monoculture. There is, currently, no viable third option.
Also, there is Firefox on iOS. I use it every day, and it nicely syncs my bookmarks/history/tabs/etc. with Firefox on desktop. What there isn’t on iOS is a version of Firefox that uses the Gecko rendering engine.
I’m very old and I remember in the early 2000s when IE had above 95% market share.
What gave us the explosion of other browsers: Mozilla & Firefox on Gecko, Safari & Chrome on WebKit, etc was user choice, not vendor lock-in.
I believe freedom begets freedom. I do not believe, as Orwell’s Big Brother said: “Freedom Is Slavery”. You’re free (as far as I’m concerned) to make your choice on that question.
I was building websites in the 2000s. I was active in the early web standards communities.
And it really is not constructive to dismiss everyone else’s arguments with clichés that aren’t relevant to the argument being made. Nor is it constructive to put words in someone else’s mouth that they didn’t say. Both of which you have done here, repeatedly.
But I will try to put my argument as simply as I can: if you want to increase competition and choice in the browser market, you must have a prioritized list of problems to tackle in order to do so. And in order to have any chance of success, that prioritization list must put breaking up the market-threatening monoculture of Google-driven Chrome and Chrome-derived browsers at the top; forcing Apple to allow alternative engines on iOS can be done after that.
Until the Google problem is tackled and dealt with, Apple’s policies for browser engines on iOS are in fact the lesser evil.
Now, do you intend to engage with that argument constructively and in good faith? Or do you intend to make the same type of non sequitur meme replies as your prior posts?
My argument is that taking away peoples right to choose a browser with their engine of choice is not how we get more browser engine choices.
We have a kind of beautiful flourishing of browsers these days. They’re largely based on Chromium (not Chrome) and my own take (based on experience building browsers ~15 years ago) is that it’s because Chromium is a less painful upstream to deal with than Mozilla or Apple. They’re not choosing Chromium because it implements this or that web platform feature because everything still works in Safari and Firefox.
If we want a diversity of browsers built on a diversity of engines then Apple and Mozilla need to start caring about other browsers as much as Chromium seem to. When I worked on several open source browsers based on Gecko, Mozilla were actively hostile to us, and I’m still bitter about it.
Having a choice of browser only matters if you can use alternate browsers. I have yet to see any websites that mandate a browser other than chrome. “You must use IE to use this site” is now “You must use chrome to use this site” - the only reason many sites work in anything other than chrome now is because they need to work on iOS.
Your argument is “if we let people use things other than webkit on iOS that will mean there will be more browsers and so developers will not be able to make things chrome only”, the reality -as we can already see today, is that developers will say “you need to install chrome to use this website”. Which is by design - google’s primary income is advertising, and chrome is at this point the only browser that isn’t just not working to improve user privacy, but actively works to undermine it. Google considers pro-privacy browsers to be an existential threat, and that fundamentally means all non-chrome browsers.
My argument is that taking away peoples right to choose a browser with their engine of choice is not how we get more browser engine choices.
I am delighted to hear that you agree with me, and will be dedicating your efforts to ensuring the Google/Chrome monoculture is broken up as the first priority.
If we want a diversity of browsers built on a diversity of engines then Apple and Mozilla need to start caring about other browsers as much as Chromium seem to.
Oh. So actually your anger is at the browser-engine monoculture of WebKit on iOS, which you feel stifles innovation, and your proposed solution is a browser-engine monoculture of Blink on every platform, which you feel will lead to a blossoming of innovation?
This does not make sense.
When I worked on several open source browsers based on Gecko, Mozilla were actively hostile to us, and I’m still bitter about it.
You should have been much more up-front and honest about this earlier, to say the least.
You mean everyone should use the same browser, manufactured by a company who’s entire business model is predicated in users of that browser not having privacy?
Or you mean everyone must use IE, manufactured by a company who’s business model depends on every other OS being unable to exist?
Seriously we have seen the one browser world, and recognized it as so bad that people like Alex use it as pejorative phrase (albeit incorrectly).
No, I mean, is it one browser engine that people object to, or the consequences of that one browser engine? If it’s the latter, then there might be ways to get to a better world without multiple browser engines.
To be clear, I take no position here, because this has very little impact on my day to day life. And my professional career predates Fast Ethernet, so it’s not that I’m forgetting the Browser Wars of Olden Days or anything.
It is about single engine that is in almost unique control of corporation that does everything it can to reduce privacy of the users using that engine.
What gave us the explosion of other browsers: Mozilla & Firefox on Gecko, Safari & Chrome on WebKit, etc was user choice, not vendor lock-in.
That is objectively false. I can say that with absolute confidence because it’s historical fact that “user choice” and lack of “vendor lock-in” variables didn’t ever meaningfully change on Windows in the 2000s. The same “user choice” and same “vendor lock-in” was present when the web became an MSIE monoculture and it was present when it was lost.
The problem was that the web was increasingly becoming “built for MSIE” rather than built for web standards. This happened because Microsoft gained market share by destroying the business model of its only significant competitor, by giving away Internet Explorer for free. This destroyed Netscape’s old business model. Microsoft continued to develop Internet Explorer until it was better than the abandoned remnants of Netscape Navigator 4. And then Microsoft let it stagnate.
It took a while before a different business model (open source plus search engine referral revenue) became sufficiently viable to make a browser which dethroned MSIE6.
You just refuted your own point. The problem back in 2000 wasn’t vendor lock-in — because there was no vendor lock-in. The problem was that the corporation with the most money (Microsoft) destroyed the business model of its only major competitor (Netscape). And this corporation with the most money also had the most influence on default choices, managing to convince everyone to use their browser.
For years there were no competitors geared up to compete. Open source eventually came to the rescue. Back in the early 2000s, the web was simple enough that small teams had some hope to implement a web browser competitive with the dominant player. Today? Approximately 100% of new alternative browsers are just Chrome under another name. I’d wager that it’s functionally impossible for anyone to catch up to Safari/WebKit, let alone Chrome.
I understand your feelings but Lobste.rs prides itself on not being filled with vitriol or turning every technical disagreement into personal attacks. Please try to chill out a bit in future.
For the sake of a harmonious community, I have edited it. But I will still reiterate that this person doesn’t actually care about browser diversity. Getting more Chrome into more places is only important for Google sympathisers and lazy web developers who are too slovenly to test in more than one web browser.
Seeing a restriction on user choice as providing for a greater freedom is just quite a take.
All anti-monopoly laws end up being short term restrictions on user choice in an effort to get long term freedom of choice. Sometimes they work out; sometimes they don’t.
To be honest, I suspect a lot of antitrust can also backfire, or is for the benefit of not the consumer, but a more inept capitalist who wants a cut of the pie without having to spend any effort. IBM antitrust created the software industry with copyright on software, AT&T antitrust backfired creating several incompetent ILECs instead of one competent one (the original deal of just splitting Western Electric made far more sense), and Microsoft antitrust was a simultaneous slap on the wrist (pretty much no little guy benefited) and permanent psychic damage to Microsoft (major lack of focus after antitrust) - didn’t help it was really over the wrong thing (everyone shipped a browser, the real harm was the Windows monopoly, not bundling IE). Apple antitrust creating a Google monopoly instead would be icing on the cake.
There is an open question whether the prevailing regime of antitrust interpretation in the US is actually pro consumer, even as it holds consumer pricing to be the only meaningful standard to use. It’s a pig’s breakfast, IMO, and stems from a very wrongheaded and indeed highly ideological and intentional misreading of the relationships between market exchange and larger structures of social power, but this might not be the right place for that discussion.
The fact that you would consider that a sufficient reply speaks volumes. I’ll take that as an admission that you are unable to argue with the substance of my point.
Before around 2020, I never had to open more than one web browser to use the Internet. In the last couple of years, I’ve actually had to switch away from Firefox to use certain critical websites because they were broken. (Not because Firefox lacked any features, but because content permission errors were being correctly handled by Firefox and quietly ignored by other browsers.) This is the reality today: some web developers building interfaces for major financial institutions, not testing on anything other than Chrome and Safari. This is fucked up. This is scary. If you can’t understand this, you have thick partisan blinders on and I don’t know what to say to open your eyes.
I think there’s a really good argument for iOS’s webkit lock-in directly contributing to FF’s demise.
You might be worried about Google eating Apple’s lunch in that world, but Chrome can get away with being on iOS thanks to Apple’s policies meaning that Chrome can “just exist”, whereas FF is relegated to being an odd skin with weird perf issues.
That’s patently ridiculous. Firefox isn’t cratering in real desktop browser market share today because of some hypothetical future changes to iOS which haven’t happened and is literally made up.
I guess I remain the only one who actually wants native to not just stick around, but thrive. I don’t like the way the Web has evolved under Google’s stewardship, and I regularly find myself desperately trying to find native apps for services I rely on. I’m in the planning stages of starting a business around writing native apps for some of these services, and from my early studies I’m not alone in the desire to get the Web back to being an information platform instead of a software delivery platform.
Also: I was quite happy with Safari’s twice-yearly releases. I can live with releases eight times a year. But one of the reasons I switched from Firefox to Safari in 2021 was because of how often Firefox was releasing and how many changes I had to endure. I had serious upgrade burnout.
Lastly, I don’t want or need any of the features outlined in this article: Web Push is far too easy to abuse; custom elements are either useless or a great way to implement dark patterns; screen wake/lock APIs are going to enable even more privacy invasion; SIMD has, IMO, no place in the browser; etc, etc. Hopefully the Develop menu will allow some/most of those to be disabled.
I’m in the planning stages of starting a business around writing native apps for some of these services, and from my early studies I’m not alone in the desire to get the Web back to being an information platform instead of a software delivery platform.
Wow, this sounds very nice. I very much belong to these people. Good luck with your endeavors! I’ve only witnessed abuse of the latest features, like some sketchy news sites wanting to deliver push notifications.
The problem with native apps is that they already have even more of the privileges that web apps are gaining: the ability to keep my phone awake and active, digging around my desktop’s personal information, and so on. I agree with wanting the web to be information-first, but I also reject installing a native app just to interact with a CRUD API.
So an unhealthy browser monoculture means what we have now. People building tiny apps that maybe talk to a crud api and instead ship an entire browser rendering engine. Then Google pushes what system level access a browser should have (File API, USB API, etc). So instead of 5 small compiled apps that maybe talk to a CRUD API (something that is for a browser only? What?), you have 5 google browsers on your machine slowing it down.
I reject the idea of installing 5 different chromium browsers to talk to 5 different CRUD APIs.
“the lack of AVIF and AV1 holds media and streaming businesses back.”
Won’t somebody think of the media and streaming businesses.
I do some webdev at work, but I guess I’m not in the target audience of this post, as I’m trying to support as many browsers as possible, including ones that have many more “missing features”, and I think the “web platform” has gone completely off the rails.
Speaking as a website hoster, AVIF saves me tens of dollars per month in bandwidth that doesn’t have to be spent. The AVIF versions of images are about 10% of what the source files are, sometimes less. Some of those furry stickers that the orange site hates get down to 10-20 kilobytes. AVIF is a phenomenal invention, but I thought it already worked on iOS? Most of my web traffic comes from iOS and iPadOS, this is where AVIF has saved me the most data.
I also want to use AV1 on my website because AV1 would let me serve higher quality video at a lower bitrate. I’m talking the same mpeg4 video could be 1/10 the size and bitrate without affecting the visual experience.
You don’t have to be a megacorp to see the advantages of these innovations.
I can’t edit my comment now, but since I have gotten reports that it’s being lampooned: my CDN costs with AVIF are only $5 per month. AVIF saves me on the order of 3x my current monthly CDN spend. Here are the stats for some random hero image from my blog:
I also want to use AV1 on my website because AV1 would let me serve higher quality video at a lower bitrate. I’m talking the same mpeg4 video could be 1/10 the size and bitrate without affecting the visual experience.
You may be a small fry not worth suing for your use of ffmpeg without purchasing a patent license*, but anyone with a notable business is forced to pay fees to a bunch of patent holders just for the privilege of generating videos for Safari.
*) that’s right, software patents were allowed cover abstract ideas and math, and allow extortion of users of every piece of software anybody has ever written that touches the idea, regardless of the software’s license.
Apple’s standards engineers have a long and inglorious history of stalling tactics in standards bodies to delay progress on important APIs, like Declarative Shadow DOM (DSD).
Here is the thing though. The Shadow DOM is a shitty API. It’s absolute bollocks. If it were good, then the JS framework people would be using it. It’s not like they don’t have things they want. You can read whole reams of text from them if you’re interested. Instead, a handful of ideologically driven JS people are using Shadow DOM for Web Components which have not and will not catch on because they’re just SPAs with a web standards veneer. Declarative Shadow DOM is an attempt to stop the pop-in for WC, but really the whole thing is just a dead end. It’s like getting excited for a car with a Wankel engine when all the effort for the last few years has been moving to electric cars. The isolation that Shadow DOM provides is better provided as a feature of CSS, and Custom Elements are just reactivity plus MutationObserver. Build reactivity and morphDOM into the browser and watch as all the JS framework people jump up and down to add it.
Anyway, the moral is the Chrome team has lots of bad idea. Dart was a bad idea. Web Components were an interesting idea and sort of happened anyway, but the actual API is older than React and very bad and should be abandoned. I for one am glad that not all of Chrome’s ideas are instantly implemented. It’s good to have some modicum of friction before things get added to the browser. Unlike a normal GUI API like Win32 or AppKit, the browser is forever. It’s never going anywhere. Old features can’t be removed (although Chrome team did try to remove alert!). Therefore, it’s not good to just add everything as quickly as possible. Some level of moderation is needed. Was Safari goldbricking for a long time? Yeah, probably. But there has to be something in between “Whatever Google farts out gets added to the browser tomorrow” and “Let’s wait five years for Apple to add a feature.”
To be clear this “inglorious” history he’s talking about is because Alex is not a good engineer, and basically takes the stand in every standards body that anyone not worshipping his glorious and mostly half baked and poorly conceived APIs is an anti-open web enemy. Hence he regards any attempts to try and not create brand new APIs that are half baked, poorly conceived, filled with privacy problems, etc is a “stalling tactic”.
Apple engineers, MS (at the time) engineers, Mozilla engineers, and even other google engineers understood that creating a good specification and API takes effort, and put effort into doing just that.
But Alex doesn’t understand that - he’s an arrogant and opinionated asshole that has apparently never had to maintain an API, but has never had an issues insulting anyone in a standards committee who dared to disagree with him, or suggest that their were factors beyond his own tech demos that needed to be considered.
As for why he has made hating Apple (and shitting on those apple engineers just trying to avoid creating new shitty APIs that have to be maintained forever) his personality I don’t know.
Yeah, I just listened to the JS Party episode he was on talking about “The Market for Lemons” and it felt like a lot of hot air to me. It is clear from reading him that he doesn’t think Vue, Svelte, WC are crap. He just dislikes React and Angular. So, he’s not actually against SPAs, just bad SPA frameworks. Which is fine, whatever, but the conversation was so high level it’s hard to see that this is his actual position unless you read his blog thoroughly.
Similarly, he talked about how he would meet with PMs and ask to see their phones and be made that it was a new iPhone instead of an old Moto G4. I own a Moto G4. I bought it for work. I turn it on every month or two to look at our site when we launch new features. But I don’t carry it around and use it as my daily driver. Does that make me a bad person?
I also run a US-centric site, so I don’t care about how slow my site is for users outside of the US. I do care about how it is for rural users with bad cell connections, but that’s not necessarily the same set of issues, so it’s sort of weird to collapse them.
Anyway, I agree that Apple the company deliberately under-resourced the WebKit team for a while because they didn’t care about the web strategically, but I don’t think that’s the same as saying that e.g. the Web device APIs are a good idea (I really don’t want websites to start popping up a box asking for permission to use Bluetooth!!).
Really a lot of these APIs are tacked-on workarounds so the browser can be the ultimate run anything app. So that developers can only write Javascript. If developers weren’t so self stigmatizing about what they do and don’t know (ex. stigma: C++ can be harder than JS) then we’d probably have more native app developers.
Yeah, a lot of Google’s “standardizing” is mostly to give Chrome feature parity with an operating system. Which helps Google because they ship Chrome as, effectively, an operating system on Chromebooks, and encourage companies and schools to adopt “do and run everything in Chrome” workflows.
I’m becoming convinced that cross-platform GUI is a folly in terms of quality of developer and user experience. The differences behind the scenes can be surmounted, but at a cost. I think it’s best to just support the platform you know best. well.
cross platform UI doesn’t work because different platforms have fundamentally different UI semantics, and so “cross platform” toolkits generally just become “a linux app on windows” or “a windows app on Mac”. E.g. everything using windows key chords for shortcuts instead of the correct Mac ones, using ctrl where command is correct, not using shared pasteboards. This is before we get to text entry where you get all sorts of incorrect handling of IMEs depending on the original OS for the framework (if they even handle IMEs at all, which many don’t).
That’s a real concern, but on the other hand, is Electron any better? Even paying the price of a full browser runtime per app, you don’t get native widgets.
Funny enough, you actually do; at least better than what Qt gives. On macOS at least, IIRC, the typical readline editing shortcuts that work in native text fields work in Electron apps, but get sketchy with Qt.
Fundamentally blink/chrome get their text entry logic from webkit, which does the correct thing if you’re targeting macOS (for obvious reasons). Things go wrong when people decide to handle text entry themselves because “it can’t be that hard”, yet it remains something devs (often webdevs) seem hell bent on doing :-/
I’ve been having wonderful experiences with Qt as of late, which has JS/Python interfaces and even some of their own ECMA-esque interfaces QML language.
I believe GTK also has cross platform bindings or at least interfaces with JS/Python languages.
I’m not trying to be facetious but what makes the web a terrible experience and it’s offering of the available toolkit, frameworks, libraries, etc. is the churn of the “it’s supported, no it isn’t, but here’s a new paradigm”. I think it’s a great place to start but I think more developers, especially new ones should try typed, compiled stacks and then rack the idea of a browser against what you’re actually trying to build.
GTK supports a lot of languages, but the cross-platform story is only so-so. Apparently it’s pretty bad on MacOS. Qt has better cross-platform support, but much worse language support; it’s apparently relatively difficult to generate bindings for new languages.
Qt is pretty bad on macOS as well. It implements its own controls, which behave in subtly different ways to the native ones that end up being really jarring.
You’ll still end up with code that checks the platform
Based on most PWAs I’ve seen, no they won’t, you just ship a website that believes it can do better than the browser and then break a bunch of basic functionality
It’s like getting excited for a car with a Wankel engine when all the effort for the last few years has been moving to electric cars.
This is completely unrelated, but there are in fact many people getting excited about the new Wankel engine coming in the Mazda MX-30 PHEV, and that car even happens to be partially electric.
My experience working with Alex is that he’s an asshole, who is unwilling to accept or to allow any opinion other than his own. He has a pathological and frankly unprofessional hatred of Apple, and always has - even pre-blink his behaviour towards the apple engineers he was ostensibly working with was one of dismissal and derogation. Post-fork he became even more shitty to be involved with in any standards body he was still involved with.
He was historically involved in many web standards, and proposed many different things, but treated any disagreement, or any raised issues, as being made up to undermine his perfect plans - you could not discuss any proposal with him, or work on any standard, as he seemed incapable of working in good faith.
He was easily one of, if not the most, awful people from google that I had to interact with, and for me if he was involved in anything I would simply avoid the entire topic - his relentless antagonism, and his unwillingness to even consider anyone else’s opinions meant that any attempted discussion was just going to be a waste of time.
It’s someone astounding that we’re listening/reading his opinions about standards developments given his general disdain for any standard isn’t “whatever I want to do right now is right and anyone who disagrees with me is anti the ‘open web’”.
You can see it even in this post: there are plenty of things that webkit has implemented that chrome hasn’t, but they aren’t what he wants therefore webkit is holding back everything, but chrome’s failure to implement features is not, because if Alex doesn’t need/want the feature it’s not a critical part of the open web. We don’t see him bemoaning chrome’s lack of basic user privacy protections, or even the most basic anti-tracking tech that Safari and Firefox have because to him user privacy is not critical to the web. Being able to spam notifications however is - because he has a use case for that, and potential for abuse doesn’t figure in anything he thinks about or has proposed (historically anyone bringing up the potential for his half assed feature proposals to be abused would be accused of being anti-open web, or the abuse and privacy implications would be dismissed as unimportant).
To be very clear, when he says
Apple’s standards engineers have a long and inglorious history of stalling tactics in standards bodies to delay progress on important APIs, like Declarative Shadow DOM (DSD).
The “delaying tactics” he’s talking about are ensuring there aren’t new privacy holes being added, or ensuring that the APIs are reasonably complete and aren’t just yet another half assed web spec that will have to be maintained when a new spec that does the right thing is developed - basically the standard steps taken in any API development where you know that they will have long term support requirements. His entire mental model for web specification development is the boneheaded and delusional “well if we get it wrong we can just make another API that does it right, so creating a poorly thought out and half assed spec is fine and has no long or short term cost”. While I don’t think he specifically ever did it, I lump Alex’s approach to specifications in with the people who said jQuery is clearly amazing and should be standardised and built directly into browsers, and who post-jquery mania moved onto new libraries and said the same thing.
Comments like this are too hot for Hacker News, but I’m glad you’re able to make it here. Thoughful people will be able to read that comment and take it for what it is—hopefully it doesn’t get nerfed by a moderator. It’s an interesting perspective and, while I have no way of validating anything you’ve said, it’s a surprisingly good jigsaw puzzle fit for why Alex writes how he does.
the people who said jQuery is clearly amazing and should be standardised and built directly into browsers
To be fair, the one truly killer feature of jQuery did get standardised as document.querySelector().
As a moderator, I am fine with the top level comment here. Assessing people’s character is important in discussing their work, it’s part of the process. Turning it into personal back-and-forth is what we wish to avoid. I felt that olliej did an excellent job of saying important stuff without being incendiary (or “hot” as you suggest).
I’m going to refrain from speculating on whether indeed this kind of thing can’t be said on Hacker News, or why that would be. I do think that it is factually incorrect to flatten every nuance of discussion into how “hot” a remark is, and that thinking that way will be counterproductive.
I do think it is factually incorrect (and unkind) to imply that I was flatting the nuance of this discussion into how “hot” the remark was. My reply was simply to show gratitude to the author for taking the time to write this rather long post and to show gratitude to the site for respecting their audience in allowing it to remain.
I think that the core point you’re asserting–that the article fails to give the same benefit of a doubt to Safari as to Chrome for some of the same omissions, and so forth–is a valid and reasonable criticism that is even supported directly by the text.
I would caution that the large part of the rest of your post boils down to “this person is a tremendous asshole”, and whether or not that is true I don’t think we should be encouraging and normalizing that here on Lobsters.
In general, please avoid ad hominem attacks–especially when it’s easy to disagree using only the article itself.
Apple’s protectionism towards Safari’s participation-prize under-achievement hasn’t withstood even the faintest whiff of future challengers, which should be an enduring lesson: no vendor must ever be allowed to deny true and effective browser competition.
I agree with this. I’m the rare nerd who actually appreciates the walled garden approach to curating a mobile applications environment, but that IMO has nothing to do with allowing competitors inside.
There is no earthly reason why Chrome and Edge and Brave and any others who can meet Apple’s security / app store admission requirements shouldn’t be allowed to ship on IOS.
There is no earthly reason why Chrome and Edge and Brave and any others who can meet Apple’s security / app store admission requirements shouldn’t be allowed to ship on IOS.
The reason is very simple. Whenever the EU forces Apple to allow alternative browser engines on iOS (alternative browsers are already allowed, they just have to use the stock WebKit engine the system provides), there will be a period of about five microseconds between Chrome-with-Chrome’s-engine being approved for the app store, and every Google property flipping on the “Please use Chrome to continue” banner.
And that’s the end of “browser choice”. The web will become a Chrome monoculture and every other browser, except maybe Edge, will wither and die. And regulation will not stop this, because it will be fought and appealed and re-appealed for years on end, and no other browser will be able to sustain itself long enough to come back if the Chrome monoculture is ever forcibly broken up.
I’m actually less worried about Chrome web browsers on iOS and more worried about the flood of lazy developers switching from embedding WebKit to some kind of Electron-esque framework for iOS app development. At least if app developers use WebKit I don’t have to worry about simple apps draining my battery.
It just boggles my mind how the simplest of desktop apps, like Balena Etcher and 1Password (which should have tons of money to pay developers!) are now just copies of Chrome pretending to be native software. This is certifiably insane.
Part of the problem driving the monoculture is complexity.
The body of standards that comprise a modern browser are positively mind bogglingly complex.
I don’t know what we do about that as it seems like there’s no stopping people from treating the web as the universal platform byte code for applications.
And honestly, who can blame them? In a capitalist world, developing bespoke native applications is expensive and a whole lot of users simply don’t care and just want us to Make it Go :)
This is why EU regulators are also constantly fining Google for browser favoritism since forever ago.
I think society should really think about ways in which we can prevent bad things from happening beyond just happening to intersect with business needs of large corporations
It is possible to hate both the rent-seeking of Apple and Google’s special pleadings here, right? I use Apple hardware, and I like most of it, but the strategy tax that their services group imposes on the rest of the platform really makes it hard to be optimistic about their future direction.
I think we have a problem across the board where we’re seeing the result of unrestrained Capitalism, but nobody wants to drop the government regulatory A-bomb to kill this flea.
I think part of the problem is that some of the APIs that evil, greedy Apple won’t add to their browser would kind of allow circumventing some of that garden. E.g. things like the Device API (so, Web Bluetooth or WebUSB, even if only for installed PWAs). I miss the Internet Explorer age as little as anyone else, but given the recent privacy history of Google and Microsoft and the inherent difficulties involved in impedance matching native OS permissions and browser-granted permissions, I’d… also be far more comfortable knowing there’s not even the technical possibility of a PWA getting Bluetooth access via the Web Bluetooth API. Which I don’t even want to know why is a thing in the first place.
I think that there is a symbiotic relationship between the web technology stack and the extractive and abusive business models that are enabled by it. I am fully on board with user freedom, but that’s entirely orthogonal to what’s being discussed here. Users are no freer in a world dominated by Google than they are in one dominated by Apple’s App Store.
I don’t want any of it, but until there’s some evidence to the contrary, I will prefer the native application world, and Apple’s imperfect implementation of it, to the modern web.
I think part of the problem is that some of the APIs that evil, greedy Apple won’t add to their browser would kind of allow circumventing some of that garden.
That’s a really interesting point and one I hadn’t honestly considered.
FWIW I’d love it if we could get past moralizing about megacorps. They’re neither good nor evil. They just are. Their motivations are pure profit seeking and we’d all have a better time of things if we could get our collective heads around that :)
Their motivations are pure profit seeking and we’d all have a better time of things if we could get our collective heads around that :)
Oh, yeah, I was just being sarcastic about “evil, greedy Apple”. The author of this piece tries to paint it like Apple is unwilling to do all that because they hate standards, competition and users. Which, I mean, they probably do, because all large companies do, although that’s kindda rich coming from someone at Microsoft, of all places.
But, realistically, this is a game in which Microsoft would have had zero stakes if they hadn’t placed all their bets on cloud offerings a la Office 365. They’re not doing this out of a love of standards, they’re doing it:
Out of a love for that sweet premium Apple platform marketshare that they’re currently playing second fiddle to because their main tech stack (web) is a second-class citizen there
Because, as long as they’re forced to make their janky cloud apps work on Safari, they are literally working against Blink world domination, so their apps division is kind of sabotaging their browser division’s strategy
I would totally understand this and I can absolutely appreciate it as good strategy, but all that bullshit about the power of competition and the importance of not gatekeeping users is getting in the way of my appreciating it :-).
People can gnash their teeth all they want about how the browser should just be about static documents.
The fact is, it’s now also an app distribution platform. One that has a lot of advantages over the apple and google stores. Anything that makes it easier to write cross platform apps is a net win for me, and I - along with many others - will continue to push PWAs now that apple is coming to the party.
If you don’t like it - be the change you want to see in the world. I’d love to see more gemini capsules.
I found this pretty boggle-worthy - the repeated use of the word “responsible”, painting blink/chrome as such a bastion of good internet citizenship while pushing their own standards, several of which have serious end user privacy concerns (web usb, etc). I mean, how dare everyone else not ship chrome’s de facto (“we have market share, so we can make our own standards”) standards right away?!
After clicking “about” on the blog it makes a bit more sense how/why the author might make such an assertion.
Yeah. I also note that the “delayed features” that are supposedly holding back the “Open Web” are on average things that landed in Chrome in 2018-2019. It’s as if the browser-pushers want us to think that the web of 2018 is obviously intolerably backward and unusable. Bro, please.
It may have snuck up on you, but 2018 was five years ago. I would count a feature that fails to land on major platforms for that long as effectively dead. It’s not that 2018 was the stone ages, but you don’t want to be in 2018 forever.
Other than security upgrades and fixes, why not? What have we gained in the 5 years since that hasn’t primarily been in service of companies like Google extending their data gathering / advertising pimpage?
WASM threads were released in Chrome in 2019, I would guess many other improvements to WASM have been released as well.
So… nothing then.
A lot of mobile web apps are DOA without the Push API which shipped in Chrome in 2015 and Firefox in 2016. They are a big part of this Safari 16.4 release.
Chrome may be abusing its dominant status to push defacto non-standards but Safari is actually very behind.
The push API is a terrible idea, it sucks hard, and I’m glad to see it fail.
A royalty-free video codec that isn’t ancient and doesn’t suck. HTTP3, which makes a real difference to performance, especially on iffy connections. Lazy loading hints so that heavy content doesn’t have to be loaded unless the user is actually going to see it (without lag-inducing JS hacks). Motion sensing support for phones (or whatever devices have gyros/accelerometers.). Tools for making layouts that aren’t ass-backwards when the content is in an RTL language. Some more stuff in general for making pages that look nice even without a gigabyte of tool-generated CSS and JS.
And of course, every millennial’s favorite, the ability for a media query to check whether the system-wide “dark mode” is enabled.
One of the most important things about an open ecosystem which ties in closely to responsibility is sustainability. The level of resources Google puts into adding features into Chromium is nigh-impossible to match sustainably. This isn’t to say that Apple doesn’t have a) the resources, or b) reasons to de-prioritise features, especially ones that duplicate native application functionality to their lucrative App Store, but even MS pulled out of this game with a reasonably competitive modern browser engine in EdgeHTML.
Given how much sway MS/Google have over the browser market with their position in WHATWG and Chromium/Blink’s market share, it’s not really much better than the “dictated standards” of the past, like PDF or OOXML - having an open spec to meet regulatory requirements many governments have about “open data standards”, but driven entirely by stakeholders who effectively control that ecosystem.
It’s the old “Fire and Motion” strategy that Joel Spolsky used to write about in the context of Microsoft. Google can simply fire bursts of new “standard” features at everyone else, and then blame competitors for being unable to keep up. And developers will happily take up the chant of “Safari is the new IE! The new IE! The new IE!” despite the fact that it’s Google and Chrome using the old Microsoft tactics.
I know this is the most unoriginal, most oft-repeated point, but I’ll say it anyway. And I say this as a very long-time user of Firefox on desktop. Browser choice is objectively less important to the health of the web than in-field browser diversity. And Webkit’s exclusivity on iOS is now unequivocally the last stand against a browser engine monoculture.
It’s like we’ve all forgotten why the MSIE 6 era was so bad, so unhealthy. This should be obvious to anyone who has studied browser history. It wasn’t because Microsoft was denying browser choice. The problem was the lack of in-field browser diversity. 2002 was the closest we ever got to single-browser dominance, and it was fuelled by developers who treated Internet Explorer as the platform, rather than web standards.
It’s amazing how so many people are now complaining about Safari not keeping up with Chromium, seemingly hypnotised into believing that whatever Chromium does is the definition of web standards. By that definition, all other browsers are behind. By that definition, control of the web platform is ceded to Google. Sorry but no. I like that Safari is taking a more considered approach. I like that it isn’t racing ahead at maximum speed. If you disagree that’s fine, but understand that yours is—like mine—just another opinion.
Unfortunately, due to Google setting the agenda for WHATWG, and Microsoft backing them up, “whatever Chromium does” basically is the definition of web standards today.
Only according to people who want to criticise Safari for not being Chrome.
You don’t like Dart?
For several years now at least, I have already been comparing the experience of trying to solve for safari quirks (especially for iOS) to trying to keep IE 6 happy.
I am not a hater; safari on macOS is the browser I use most and prefer.
But it’s got problems, and they tend to malinger for years. I agree that we don’t want a monoculture, and I’m happy with the pushback on privacy issues related to new APIs, but I’m not sure it will ever be long-term tenable for a browser to be the only reason a site/project is forced to test UA strings.
I would argue that any future where web developers think they don’t need to test in more than one browser is a web dystopia. We know this because we’ve been there before with Internet Explorer.
couldn’t imagine living in any kind of dystopia that sure would suck
By testing UA strings, I don’t mean to imply that developers shouldn’t test their sites in more than one browser.
I mean that having code that checks which UA is in use in order to treat them differently (at least, in a codebase that would prefer to be testing feature support instead of UAs) is a smell that one or more of them might be broken or have conflicting implementations that we’re left to work around.
George Orwell would be proud of that one.
What’s factually wrong about it?
Firefox is at an all-time low of relevance. WebKit, by being the default and only browser engine on the iOS platform, is effectively the only thing between Google and a complete Chrome monoculture in which “Web standards” are redefined as “whatever Google felt like shipping in Chrome this month”, and anyone who uses an alternative browser engine will be served a “To continue, please download Chrome” banner.
This doesn’t mean that the way iOS is managed is good. It just means that, at the moment, it’s the lesser of the available evils. But don’t worry – the EU is doing its best to ensure victory for the greater evil via regulations which will break Apple’s “monopoly” and usher in the permanent unbreakable Chrome monoculture.
Seeing a restriction on user choice as providing for a greater freedom is just quite a take.
Dismissing Firefox is just giving into the WebKit monoculture that Blink is part of. A year ago Firefox & Safari both had about 10% on desktop. Now allowing Firefox on iOS means that Mozilla can’t offer a browser across many peoples’ set of devices, harming their ability to innovate. And for my many misgivings about Mozilla’s leadership, I trust them more than Apple to care about peoples’ privacy and freedom.
Would freedom be helped if for “security” reasons the next version of macOS didn’t allow non-Safari browser engines?
Firefox is, from a practical perspective, not relevant. Its market share is small enough to pose no serious threat whatsoever to Google/Chrome, especially because Google is its primary source of funding.
Safari has enough market share and Apple enough financial independence from Google that web developers cannot ignore it and go Chrome-only. It has that market share because of Apple’s iOS policies.
No matter how much you personally dislike Apple or Apple’s policies, these are simple facts about the market. And I do indeed believe it is the lesser evil compared to a permanent Chrome monoculture. There is, currently, no viable third option.
Also, there is Firefox on iOS. I use it every day, and it nicely syncs my bookmarks/history/tabs/etc. with Firefox on desktop. What there isn’t on iOS is a version of Firefox that uses the Gecko rendering engine.
I’m very old and I remember in the early 2000s when IE had above 95% market share.
What gave us the explosion of other browsers: Mozilla & Firefox on Gecko, Safari & Chrome on WebKit, etc was user choice, not vendor lock-in.
I believe freedom begets freedom. I do not believe, as Orwell’s Big Brother said: “Freedom Is Slavery”. You’re free (as far as I’m concerned) to make your choice on that question.
I was building websites in the 2000s. I was active in the early web standards communities.
And it really is not constructive to dismiss everyone else’s arguments with clichés that aren’t relevant to the argument being made. Nor is it constructive to put words in someone else’s mouth that they didn’t say. Both of which you have done here, repeatedly.
But I will try to put my argument as simply as I can: if you want to increase competition and choice in the browser market, you must have a prioritized list of problems to tackle in order to do so. And in order to have any chance of success, that prioritization list must put breaking up the market-threatening monoculture of Google-driven Chrome and Chrome-derived browsers at the top; forcing Apple to allow alternative engines on iOS can be done after that.
Until the Google problem is tackled and dealt with, Apple’s policies for browser engines on iOS are in fact the lesser evil.
Now, do you intend to engage with that argument constructively and in good faith? Or do you intend to make the same type of non sequitur meme replies as your prior posts?
My argument is that taking away peoples right to choose a browser with their engine of choice is not how we get more browser engine choices.
We have a kind of beautiful flourishing of browsers these days. They’re largely based on Chromium (not Chrome) and my own take (based on experience building browsers ~15 years ago) is that it’s because Chromium is a less painful upstream to deal with than Mozilla or Apple. They’re not choosing Chromium because it implements this or that web platform feature because everything still works in Safari and Firefox.
If we want a diversity of browsers built on a diversity of engines then Apple and Mozilla need to start caring about other browsers as much as Chromium seem to. When I worked on several open source browsers based on Gecko, Mozilla were actively hostile to us, and I’m still bitter about it.
Having a choice of browser only matters if you can use alternate browsers. I have yet to see any websites that mandate a browser other than chrome. “You must use IE to use this site” is now “You must use chrome to use this site” - the only reason many sites work in anything other than chrome now is because they need to work on iOS.
Your argument is “if we let people use things other than webkit on iOS that will mean there will be more browsers and so developers will not be able to make things chrome only”, the reality -as we can already see today, is that developers will say “you need to install chrome to use this website”. Which is by design - google’s primary income is advertising, and chrome is at this point the only browser that isn’t just not working to improve user privacy, but actively works to undermine it. Google considers pro-privacy browsers to be an existential threat, and that fundamentally means all non-chrome browsers.
I am delighted to hear that you agree with me, and will be dedicating your efforts to ensuring the Google/Chrome monoculture is broken up as the first priority.
Oh. So actually your anger is at the browser-engine monoculture of WebKit on iOS, which you feel stifles innovation, and your proposed solution is a browser-engine monoculture of Blink on every platform, which you feel will lead to a blossoming of innovation?
This does not make sense.
You should have been much more up-front and honest about this earlier, to say the least.
But, is the existence of multiple engines a good in and of itself? I am unconvinced.
You mean everyone should use the same browser, manufactured by a company who’s entire business model is predicated in users of that browser not having privacy?
Or you mean everyone must use IE, manufactured by a company who’s business model depends on every other OS being unable to exist?
Seriously we have seen the one browser world, and recognized it as so bad that people like Alex use it as pejorative phrase (albeit incorrectly).
No, I mean, is it one browser engine that people object to, or the consequences of that one browser engine? If it’s the latter, then there might be ways to get to a better world without multiple browser engines.
To be clear, I take no position here, because this has very little impact on my day to day life. And my professional career predates Fast Ethernet, so it’s not that I’m forgetting the Browser Wars of Olden Days or anything.
It is about single engine that is in almost unique control of corporation that does everything it can to reduce privacy of the users using that engine.
That is objectively false. I can say that with absolute confidence because it’s historical fact that “user choice” and lack of “vendor lock-in” variables didn’t ever meaningfully change on Windows in the 2000s. The same “user choice” and same “vendor lock-in” was present when the web became an MSIE monoculture and it was present when it was lost.
The problem was that the web was increasingly becoming “built for MSIE” rather than built for web standards. This happened because Microsoft gained market share by destroying the business model of its only significant competitor, by giving away Internet Explorer for free. This destroyed Netscape’s old business model. Microsoft continued to develop Internet Explorer until it was better than the abandoned remnants of Netscape Navigator 4. And then Microsoft let it stagnate.
It took a while before a different business model (open source plus search engine referral revenue) became sufficiently viable to make a browser which dethroned MSIE6.
You just refuted your own point. The problem back in 2000 wasn’t vendor lock-in — because there was no vendor lock-in. The problem was that the corporation with the most money (Microsoft) destroyed the business model of its only major competitor (Netscape). And this corporation with the most money also had the most influence on default choices, managing to convince everyone to use their browser.
For years there were no competitors geared up to compete. Open source eventually came to the rescue. Back in the early 2000s, the web was simple enough that small teams had some hope to implement a web browser competitive with the dominant player. Today? Approximately 100% of new alternative browsers are just Chrome under another name. I’d wager that it’s functionally impossible for anyone to catch up to Safari/WebKit, let alone Chrome.
Hi,
I understand your feelings but Lobste.rs prides itself on not being filled with vitriol or turning every technical disagreement into personal attacks. Please try to chill out a bit in future.
Thanks.
For the sake of a harmonious community, I have edited it. But I will still reiterate that this person doesn’t actually care about browser diversity. Getting more Chrome into more places is only important for Google sympathisers and lazy web developers who are too slovenly to test in more than one web browser.
All anti-monopoly laws end up being short term restrictions on user choice in an effort to get long term freedom of choice. Sometimes they work out; sometimes they don’t.
To be honest, I suspect a lot of antitrust can also backfire, or is for the benefit of not the consumer, but a more inept capitalist who wants a cut of the pie without having to spend any effort. IBM antitrust created the software industry with copyright on software, AT&T antitrust backfired creating several incompetent ILECs instead of one competent one (the original deal of just splitting Western Electric made far more sense), and Microsoft antitrust was a simultaneous slap on the wrist (pretty much no little guy benefited) and permanent psychic damage to Microsoft (major lack of focus after antitrust) - didn’t help it was really over the wrong thing (everyone shipped a browser, the real harm was the Windows monopoly, not bundling IE). Apple antitrust creating a Google monopoly instead would be icing on the cake.
There is an open question whether the prevailing regime of antitrust interpretation in the US is actually pro consumer, even as it holds consumer pricing to be the only meaningful standard to use. It’s a pig’s breakfast, IMO, and stems from a very wrongheaded and indeed highly ideological and intentional misreading of the relationships between market exchange and larger structures of social power, but this might not be the right place for that discussion.
The fact that you would consider that a sufficient reply speaks volumes. I’ll take that as an admission that you are unable to argue with the substance of my point.
Before around 2020, I never had to open more than one web browser to use the Internet. In the last couple of years, I’ve actually had to switch away from Firefox to use certain critical websites because they were broken. (Not because Firefox lacked any features, but because content permission errors were being correctly handled by Firefox and quietly ignored by other browsers.) This is the reality today: some web developers building interfaces for major financial institutions, not testing on anything other than Chrome and Safari. This is fucked up. This is scary. If you can’t understand this, you have thick partisan blinders on and I don’t know what to say to open your eyes.
I think there’s a really good argument for iOS’s webkit lock-in directly contributing to FF’s demise.
You might be worried about Google eating Apple’s lunch in that world, but Chrome can get away with being on iOS thanks to Apple’s policies meaning that Chrome can “just exist”, whereas FF is relegated to being an odd skin with weird perf issues.
That’s patently ridiculous. Firefox isn’t cratering in real desktop browser market share today because of some hypothetical future changes to iOS which haven’t happened and is literally made up.
I guess I remain the only one who actually wants native to not just stick around, but thrive. I don’t like the way the Web has evolved under Google’s stewardship, and I regularly find myself desperately trying to find native apps for services I rely on. I’m in the planning stages of starting a business around writing native apps for some of these services, and from my early studies I’m not alone in the desire to get the Web back to being an information platform instead of a software delivery platform.
Also: I was quite happy with Safari’s twice-yearly releases. I can live with releases eight times a year. But one of the reasons I switched from Firefox to Safari in 2021 was because of how often Firefox was releasing and how many changes I had to endure. I had serious upgrade burnout.
Lastly, I don’t want or need any of the features outlined in this article: Web Push is far too easy to abuse; custom elements are either useless or a great way to implement dark patterns; screen wake/lock APIs are going to enable even more privacy invasion; SIMD has, IMO, no place in the browser; etc, etc. Hopefully the Develop menu will allow some/most of those to be disabled.
There are dozens of us!
Wow, this sounds very nice. I very much belong to these people. Good luck with your endeavors! I’ve only witnessed abuse of the latest features, like some sketchy news sites wanting to deliver push notifications.
The problem with native apps is that they already have even more of the privileges that web apps are gaining: the ability to keep my phone awake and active, digging around my desktop’s personal information, and so on. I agree with wanting the web to be information-first, but I also reject installing a native app just to interact with a CRUD API.
So an unhealthy browser monoculture means what we have now. People building tiny apps that maybe talk to a crud api and instead ship an entire browser rendering engine. Then Google pushes what system level access a browser should have (File API, USB API, etc). So instead of 5 small compiled apps that maybe talk to a CRUD API (something that is for a browser only? What?), you have 5 google browsers on your machine slowing it down.
I reject the idea of installing 5 different chromium browsers to talk to 5 different CRUD APIs.
Wow! You heard “native app” and immediately thought of the smart phone. I heard “native app” and immediately thought of a home computer.
For clarity, I purposefully left that as “native app” to include both desktops and smartphones.
Moral of the story: never get better because people were ask why you didn’t get better before.
Won’t somebody think of the media and streaming businesses.
I do some webdev at work, but I guess I’m not in the target audience of this post, as I’m trying to support as many browsers as possible, including ones that have many more “missing features”, and I think the “web platform” has gone completely off the rails.
Speaking as a website hoster, AVIF saves me tens of dollars per month in bandwidth that doesn’t have to be spent. The AVIF versions of images are about 10% of what the source files are, sometimes less. Some of those furry stickers that the orange site hates get down to 10-20 kilobytes. AVIF is a phenomenal invention, but I thought it already worked on iOS? Most of my web traffic comes from iOS and iPadOS, this is where AVIF has saved me the most data.
I also want to use AV1 on my website because AV1 would let me serve higher quality video at a lower bitrate. I’m talking the same mpeg4 video could be 1/10 the size and bitrate without affecting the visual experience.
You don’t have to be a megacorp to see the advantages of these innovations.
Yes, as of 16.0. I didn’t even notice that bit in the article; that is a factual inaccuracy.
I can’t edit my comment now, but since I have gotten reports that it’s being lampooned: my CDN costs with AVIF are only $5 per month. AVIF saves me on the order of 3x my current monthly CDN spend. Here are the stats for some random hero image from my blog:
This adds up over time
How does that compare to VP9?
I need to do more detailed comparisons. I don’t know if VP9 works in iOS Safari when using HLS. Need to do more research.
Have you purchased your H.265 license?
You may be a small fry not worth suing for your use of
ffmpegwithout purchasing a patent license*, but anyone with a notable business is forced to pay fees to a bunch of patent holders just for the privilege of generating videos for Safari.*) that’s right, software patents were allowed cover abstract ideas and math, and allow extortion of users of every piece of software anybody has ever written that touches the idea, regardless of the software’s license.
I thought safari supported VP8 and VP9 at least.
Here is the thing though. The Shadow DOM is a shitty API. It’s absolute bollocks. If it were good, then the JS framework people would be using it. It’s not like they don’t have things they want. You can read whole reams of text from them if you’re interested. Instead, a handful of ideologically driven JS people are using Shadow DOM for Web Components which have not and will not catch on because they’re just SPAs with a web standards veneer. Declarative Shadow DOM is an attempt to stop the pop-in for WC, but really the whole thing is just a dead end. It’s like getting excited for a car with a Wankel engine when all the effort for the last few years has been moving to electric cars. The isolation that Shadow DOM provides is better provided as a feature of CSS, and Custom Elements are just reactivity plus MutationObserver. Build reactivity and morphDOM into the browser and watch as all the JS framework people jump up and down to add it.
Anyway, the moral is the Chrome team has lots of bad idea. Dart was a bad idea. Web Components were an interesting idea and sort of happened anyway, but the actual API is older than React and very bad and should be abandoned. I for one am glad that not all of Chrome’s ideas are instantly implemented. It’s good to have some modicum of friction before things get added to the browser. Unlike a normal GUI API like Win32 or AppKit, the browser is forever. It’s never going anywhere. Old features can’t be removed (although Chrome team did try to remove
alert!). Therefore, it’s not good to just add everything as quickly as possible. Some level of moderation is needed. Was Safari goldbricking for a long time? Yeah, probably. But there has to be something in between “Whatever Google farts out gets added to the browser tomorrow” and “Let’s wait five years for Apple to add a feature.”To be clear this “inglorious” history he’s talking about is because Alex is not a good engineer, and basically takes the stand in every standards body that anyone not worshipping his glorious and mostly half baked and poorly conceived APIs is an anti-open web enemy. Hence he regards any attempts to try and not create brand new APIs that are half baked, poorly conceived, filled with privacy problems, etc is a “stalling tactic”.
Apple engineers, MS (at the time) engineers, Mozilla engineers, and even other google engineers understood that creating a good specification and API takes effort, and put effort into doing just that.
But Alex doesn’t understand that - he’s an arrogant and opinionated asshole that has apparently never had to maintain an API, but has never had an issues insulting anyone in a standards committee who dared to disagree with him, or suggest that their were factors beyond his own tech demos that needed to be considered.
As for why he has made hating Apple (and shitting on those apple engineers just trying to avoid creating new shitty APIs that have to be maintained forever) his personality I don’t know.
Yeah, I just listened to the JS Party episode he was on talking about “The Market for Lemons” and it felt like a lot of hot air to me. It is clear from reading him that he doesn’t think Vue, Svelte, WC are crap. He just dislikes React and Angular. So, he’s not actually against SPAs, just bad SPA frameworks. Which is fine, whatever, but the conversation was so high level it’s hard to see that this is his actual position unless you read his blog thoroughly.
Similarly, he talked about how he would meet with PMs and ask to see their phones and be made that it was a new iPhone instead of an old Moto G4. I own a Moto G4. I bought it for work. I turn it on every month or two to look at our site when we launch new features. But I don’t carry it around and use it as my daily driver. Does that make me a bad person?
I also run a US-centric site, so I don’t care about how slow my site is for users outside of the US. I do care about how it is for rural users with bad cell connections, but that’s not necessarily the same set of issues, so it’s sort of weird to collapse them.
Anyway, I agree that Apple the company deliberately under-resourced the WebKit team for a while because they didn’t care about the web strategically, but I don’t think that’s the same as saying that e.g. the Web device APIs are a good idea (I really don’t want websites to start popping up a box asking for permission to use Bluetooth!!).
Really a lot of these APIs are tacked-on workarounds so the browser can be the ultimate run anything app. So that developers can only write Javascript. If developers weren’t so self stigmatizing about what they do and don’t know (ex. stigma: C++ can be harder than JS) then we’d probably have more native app developers.
Yeah, a lot of Google’s “standardizing” is mostly to give Chrome feature parity with an operating system. Which helps Google because they ship Chrome as, effectively, an operating system on Chromebooks, and encourage companies and schools to adopt “do and run everything in Chrome” workflows.
A cross-platform, multi-language GUI toolkit that wasn’t terrible would help, too.
I’m becoming convinced that cross-platform GUI is a folly in terms of quality of developer and user experience. The differences behind the scenes can be surmounted, but at a cost. I think it’s best to just support the platform you know best. well.
cross platform UI doesn’t work because different platforms have fundamentally different UI semantics, and so “cross platform” toolkits generally just become “a linux app on windows” or “a windows app on Mac”. E.g. everything using windows key chords for shortcuts instead of the correct Mac ones, using ctrl where command is correct, not using shared pasteboards. This is before we get to text entry where you get all sorts of incorrect handling of IMEs depending on the original OS for the framework (if they even handle IMEs at all, which many don’t).
That’s a real concern, but on the other hand, is Electron any better? Even paying the price of a full browser runtime per app, you don’t get native widgets.
Funny enough, you actually do; at least better than what Qt gives. On macOS at least, IIRC, the typical readline editing shortcuts that work in native text fields work in Electron apps, but get sketchy with Qt.
Fundamentally blink/chrome get their text entry logic from webkit, which does the correct thing if you’re targeting macOS (for obvious reasons). Things go wrong when people decide to handle text entry themselves because “it can’t be that hard”, yet it remains something devs (often webdevs) seem hell bent on doing :-/
No, Electron is just “making bad cross platform UI apps”, only this time by carrying a 400mb browser along for the ride.
The old phrase “what Intel giveth, Microsoft taketh away” was quaint by comparison.
I’ve been having wonderful experiences with Qt as of late, which has JS/Python interfaces and even some of their own ECMA-esque interfaces QML language.
I believe GTK also has cross platform bindings or at least interfaces with JS/Python languages.
I’m not trying to be facetious but what makes the web a terrible experience and it’s offering of the available toolkit, frameworks, libraries, etc. is the churn of the “it’s supported, no it isn’t, but here’s a new paradigm”. I think it’s a great place to start but I think more developers, especially new ones should try typed, compiled stacks and then rack the idea of a browser against what you’re actually trying to build.
GTK supports a lot of languages, but the cross-platform story is only so-so. Apparently it’s pretty bad on MacOS. Qt has better cross-platform support, but much worse language support; it’s apparently relatively difficult to generate bindings for new languages.
Qt is pretty bad on macOS as well. It implements its own controls, which behave in subtly different ways to the native ones that end up being really jarring.
I’d almost prefer if Qt just used a generic KDE skin on macOS. It would be less jarring if these non-native components didn’t pretend to be native.
I learned javascript so I could avoid google and apples native app stores, not vice versa.
Google’s and Apple’s software distrobution model is hardly the icing on the cake. Good for you though.
You’ll still end up with code that checks the platform, whether it’s Windows or Safari. Your write once efficiency is still a moving target.
Based on most PWAs I’ve seen, no they won’t, you just ship a website that believes it can do better than the browser and then break a bunch of basic functionality
This is completely unrelated, but there are in fact many people getting excited about the new Wankel engine coming in the Mazda MX-30 PHEV, and that car even happens to be partially electric.
My experience working with Alex is that he’s an asshole, who is unwilling to accept or to allow any opinion other than his own. He has a pathological and frankly unprofessional hatred of Apple, and always has - even pre-blink his behaviour towards the apple engineers he was ostensibly working with was one of dismissal and derogation. Post-fork he became even more shitty to be involved with in any standards body he was still involved with.
He was historically involved in many web standards, and proposed many different things, but treated any disagreement, or any raised issues, as being made up to undermine his perfect plans - you could not discuss any proposal with him, or work on any standard, as he seemed incapable of working in good faith.
He was easily one of, if not the most, awful people from google that I had to interact with, and for me if he was involved in anything I would simply avoid the entire topic - his relentless antagonism, and his unwillingness to even consider anyone else’s opinions meant that any attempted discussion was just going to be a waste of time.
It’s someone astounding that we’re listening/reading his opinions about standards developments given his general disdain for any standard isn’t “whatever I want to do right now is right and anyone who disagrees with me is anti the ‘open web’”.
You can see it even in this post: there are plenty of things that webkit has implemented that chrome hasn’t, but they aren’t what he wants therefore webkit is holding back everything, but chrome’s failure to implement features is not, because if Alex doesn’t need/want the feature it’s not a critical part of the open web. We don’t see him bemoaning chrome’s lack of basic user privacy protections, or even the most basic anti-tracking tech that Safari and Firefox have because to him user privacy is not critical to the web. Being able to spam notifications however is - because he has a use case for that, and potential for abuse doesn’t figure in anything he thinks about or has proposed (historically anyone bringing up the potential for his half assed feature proposals to be abused would be accused of being anti-open web, or the abuse and privacy implications would be dismissed as unimportant).
To be very clear, when he says
The “delaying tactics” he’s talking about are ensuring there aren’t new privacy holes being added, or ensuring that the APIs are reasonably complete and aren’t just yet another half assed web spec that will have to be maintained when a new spec that does the right thing is developed - basically the standard steps taken in any API development where you know that they will have long term support requirements. His entire mental model for web specification development is the boneheaded and delusional “well if we get it wrong we can just make another API that does it right, so creating a poorly thought out and half assed spec is fine and has no long or short term cost”. While I don’t think he specifically ever did it, I lump Alex’s approach to specifications in with the people who said jQuery is clearly amazing and should be standardised and built directly into browsers, and who post-jquery mania moved onto new libraries and said the same thing.
Comments like this are too hot for Hacker News, but I’m glad you’re able to make it here. Thoughful people will be able to read that comment and take it for what it is—hopefully it doesn’t get nerfed by a moderator. It’s an interesting perspective and, while I have no way of validating anything you’ve said, it’s a surprisingly good jigsaw puzzle fit for why Alex writes how he does.
To be fair, the one truly killer feature of jQuery did get standardised as document.querySelector().
As a moderator, I am fine with the top level comment here. Assessing people’s character is important in discussing their work, it’s part of the process. Turning it into personal back-and-forth is what we wish to avoid. I felt that olliej did an excellent job of saying important stuff without being incendiary (or “hot” as you suggest).
I’m going to refrain from speculating on whether indeed this kind of thing can’t be said on Hacker News, or why that would be. I do think that it is factually incorrect to flatten every nuance of discussion into how “hot” a remark is, and that thinking that way will be counterproductive.
I do think it is factually incorrect (and unkind) to imply that I was flatting the nuance of this discussion into how “hot” the remark was. My reply was simply to show gratitude to the author for taking the time to write this rather long post and to show gratitude to the site for respecting their audience in allowing it to remain.
All right. Please consider your gratitude to have been expressed.
I think that the core point you’re asserting–that the article fails to give the same benefit of a doubt to Safari as to Chrome for some of the same omissions, and so forth–is a valid and reasonable criticism that is even supported directly by the text.
I would caution that the large part of the rest of your post boils down to “this person is a tremendous asshole”, and whether or not that is true I don’t think we should be encouraging and normalizing that here on Lobsters.
In general, please avoid ad hominem attacks–especially when it’s easy to disagree using only the article itself.
This is really something that I am very glad I do not have to care about. Ugh.
I agree with this. I’m the rare nerd who actually appreciates the walled garden approach to curating a mobile applications environment, but that IMO has nothing to do with allowing competitors inside.
There is no earthly reason why Chrome and Edge and Brave and any others who can meet Apple’s security / app store admission requirements shouldn’t be allowed to ship on IOS.
The reason is very simple. Whenever the EU forces Apple to allow alternative browser engines on iOS (alternative browsers are already allowed, they just have to use the stock WebKit engine the system provides), there will be a period of about five microseconds between Chrome-with-Chrome’s-engine being approved for the app store, and every Google property flipping on the “Please use Chrome to continue” banner.
And that’s the end of “browser choice”. The web will become a Chrome monoculture and every other browser, except maybe Edge, will wither and die. And regulation will not stop this, because it will be fought and appealed and re-appealed for years on end, and no other browser will be able to sustain itself long enough to come back if the Chrome monoculture is ever forcibly broken up.
I’m actually less worried about Chrome web browsers on iOS and more worried about the flood of lazy developers switching from embedding WebKit to some kind of Electron-esque framework for iOS app development. At least if app developers use WebKit I don’t have to worry about simple apps draining my battery.
It just boggles my mind how the simplest of desktop apps, like Balena Etcher and 1Password (which should have tons of money to pay developers!) are now just copies of Chrome pretending to be native software. This is certifiably insane.
Yes, this. A 1000% this.
Part of the problem driving the monoculture is complexity.
The body of standards that comprise a modern browser are positively mind bogglingly complex.
I don’t know what we do about that as it seems like there’s no stopping people from treating the web as the universal platform byte code for applications.
And honestly, who can blame them? In a capitalist world, developing bespoke native applications is expensive and a whole lot of users simply don’t care and just want us to Make it Go :)
This is why EU regulators are also constantly fining Google for browser favoritism since forever ago.
I think society should really think about ways in which we can prevent bad things from happening beyond just happening to intersect with business needs of large corporations
It is possible to hate both the rent-seeking of Apple and Google’s special pleadings here, right? I use Apple hardware, and I like most of it, but the strategy tax that their services group imposes on the rest of the platform really makes it hard to be optimistic about their future direction.
It sure is! And I share your lack of optimism.
I think we have a problem across the board where we’re seeing the result of unrestrained Capitalism, but nobody wants to drop the government regulatory A-bomb to kill this flea.
I think part of the problem is that some of the APIs that evil, greedy Apple won’t add to their browser would kind of allow circumventing some of that garden. E.g. things like the Device API (so, Web Bluetooth or WebUSB, even if only for installed PWAs). I miss the Internet Explorer age as little as anyone else, but given the recent privacy history of Google and Microsoft and the inherent difficulties involved in impedance matching native OS permissions and browser-granted permissions, I’d… also be far more comfortable knowing there’s not even the technical possibility of a PWA getting Bluetooth access via the Web Bluetooth API. Which I don’t even want to know why is a thing in the first place.
I think that there is a symbiotic relationship between the web technology stack and the extractive and abusive business models that are enabled by it. I am fully on board with user freedom, but that’s entirely orthogonal to what’s being discussed here. Users are no freer in a world dominated by Google than they are in one dominated by Apple’s App Store.
I don’t want any of it, but until there’s some evidence to the contrary, I will prefer the native application world, and Apple’s imperfect implementation of it, to the modern web.
That’s a really interesting point and one I hadn’t honestly considered.
FWIW I’d love it if we could get past moralizing about megacorps. They’re neither good nor evil. They just are. Their motivations are pure profit seeking and we’d all have a better time of things if we could get our collective heads around that :)
Oh, yeah, I was just being sarcastic about “evil, greedy Apple”. The author of this piece tries to paint it like Apple is unwilling to do all that because they hate standards, competition and users. Which, I mean, they probably do, because all large companies do, although that’s kindda rich coming from someone at Microsoft, of all places.
But, realistically, this is a game in which Microsoft would have had zero stakes if they hadn’t placed all their bets on cloud offerings a la Office 365. They’re not doing this out of a love of standards, they’re doing it:
I would totally understand this and I can absolutely appreciate it as good strategy, but all that bullshit about the power of competition and the importance of not gatekeeping users is getting in the way of my appreciating it :-).
People can gnash their teeth all they want about how the browser should just be about static documents.
The fact is, it’s now also an app distribution platform. One that has a lot of advantages over the apple and google stores. Anything that makes it easier to write cross platform apps is a net win for me, and I - along with many others - will continue to push PWAs now that apple is coming to the party.
If you don’t like it - be the change you want to see in the world. I’d love to see more gemini capsules.