"TL;DR: The UK’s Competition and Markets Authority (CMA) has officially designated Apple as having Strategic Market Status (SMS). After four years investigating Apple’s restrictions on browser engines and web apps, the CMA now has statutory authority to enforce remedies proposed in its Market Investigation Reference completed this year.
The most important outcomes being:
- Apple can be compelled to allow third-party browsers on iOS to use their own engines.
- Apple can be compelled to provide equivalent access to functionality for browsers using their own browser engines.
- Apple can be compelled to let third-party browsers install and manage web apps using their own engines.
- Apple can be compelled to remove barriers to web app adoption, such as implementing a web app equivalent to smart banners or install prompts in iOS Safari."
That's the inspiring thing about the EU and UK regulatory frameworks: the penalties can be more than a slap on the wrist. Apple is playing a dangerous game by continuing to flout EU law and pursue a maximalist, scorched-earth strategy. Reputation matters, and they are not making friends by re-upping false arguments at every turn.
I think thats unlikely since they can extract revenue any time they want by other mechanisms. The desire here is to control the surface of enagement in their jurisdiction not revenue. Very little income is acquired for the state through court action, Taxation cases aside.
Not sure what you mean by “responsibilities are a function of scale”. “With great power comes great responsibility”?
Like I said, it is a good article, about an important topic, but you already knew that. I mostly agree with you - not that my opinion is particularly important. It prompted me to comment for only the second time.
It will seem odd to most, but my big concerns about Chrome relate to Android and ChromeOS. In neither environment did Chrome win share competitively. I think this has made them weaker and less useful, and that was mirrored in the tremendous difficulty we had in getting expansions of web capabilities done within the Chrome team, nevermind what I am documenting in this most recent post.
Sadly, the CrOS problem will be partially resolved when Google trashes it with Android rebasing in upcoming releases. On the Android side, Google is still withholding WebAPK support from competitors (suppressing PWAs on Android) and has failed to follow Apple's lead on hotseat browser replacement when choice screens are shown in the EU.
But neither of the bad effects are nearly as structural or impactful as Apple's out-and-out suppression of the web on mobile, because wealthy people carry iPhones and they have all the power:
Original author of the article here; I went out on a limb to document a bit of this in a footnote to a post a few years ago. Saying that it is unusual to call this behaviour out is a drastic understatement:
TL;DR is that the premise of the argument is false, or at least almost entirely so, and deprives Apple of agency, when in fact it has all the power in the equation.
That article also does not appear to have anything to say about the validity of "standards" that are nothing more than Google's feature creep for web browsers. At some point, you need to actually defend the idea that a web browser should be able to enumerate what Bluetooth and USB devices you have connected. Dancing around such issues is what's making your "Assault on Standards" claim sound so hollow. You need to justify how your position doesn't simply boil down to "Apple should follow Google's lead".
That's simply a misunderstanding of how features come to the web. There is no immaculate conception for web APIs. No magical room in which they are dreamt up, or spring fully-formed from the head of Zeus.
Instead, they come from open, honest, iterative design (when done well), and shipping ahead of others is risky, but that's why we designed the Blink Launch Process to demand so much pre-work (specs, tests, origin trials, good faith attempts to include other vendors in design, etc.) in order to launch that way.
You're still dodging the issue. Your article title accusing Apple of an "assault on standards" is implicitly treating Google's proposals as a fait accompli that Apple is resisting, which is not at all what the situation is for many of the Chrome features you are trying not to be specific about.
You say that shipping ahead of others is risky, but can't seem to acknowledge when the negative outcome comes to pass and other browser vendors aren't interested in adopting questionable feature proposals.
I'm simply pointing out that Apple declined to try to constructively solve the problems developers expressed, demurred from engaging in design work in many areas, and did not ship alternatives instead (as it could have, and did in the past when Safari/WebKit were not on a starvation budget).
The downsides to this are not lost on me. Why do you think I'm making an issue of it publicly now? We tried literally everything else. This is last resort stuff. The goal is always more collaboration, and through it, better, better-funded, and more capable browsers. Apple is the unique obstacle to all of that today.
Please consider the possibility that some proposed features should not exist. The objections to many of Chrome's features are fundamental, not aesthetic, or complaints about nuances of how it's implemented. Many people outside Google simply do not want the browser to be a full-fledged OS, especially if that means weakening privacy or security controls of the host OS.
Sometimes, the right response to a feature proposal is simply "no". But you're seemingly unwilling to accept that as a valid answer. The alternative you're not seeing is that of not having the dubious features in the browser.
I'd much rather have to switch to Brave or Vivaldi for a video phone call, or keyboard configuration, or NFC, than install half a dozen of outdated third-party XXX-only apps with full permissions and questionable security practices or distribution methods.
The better question to ask here, is, why would you NOT want to have a CHOICE to have these things in a secure browser by SEVERAL distinct major vendors like Google, Microsoft, Brave and Vivaldi, and Yandex, and Opera, and others?
Again, I don't even use Chrome. I replace it even on Android. So, I am not concerned with Google taking me over, because they clearly aren't.
But how am I more secure when I have to install lots of dodgy apps to get the most basic things like video conferencing working?
Alas, I think you and I are probably too far apart on the premises we accept to have a useful discussion, but I appreciate learning about your perspective and I appreciate your reply.
TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
I am sorry but i don't think that will work. Speaking as someone who tried to implement a fairly complicated ui in plain JavaScript and jQuery, i ended up shooting myself in the foot while writing code that updated the state of the application correctly.
React actually made this a non issue. There are use cases where vanilla html/css/js is just not the best tool.
honestly man, while I kind of agree that your writing style is a bit hard to parse as a logical argument, as a 'feeling?' it feels exactly the way I've been feeling for at least the past five years.
Great. Use Next.js and write SSR code, using JS and CSS modules, which outputs HTML and CSS, and use optional client side hydration for client facing functionality. SPAs are fundamentally bad for most websites, but don't confuse them for all JS frameworks. Once you need to do something as simple as turn some data into HTML (like loop over it, filter it), the premise of your article doesn't work.
Having done a lot of both, I prefer HTML and CSS for documents and statically typed, React-like component-based reactive libraries for apps. Building an app with just a smattering of JS goes well until it doesn’t, and requires a lot more discipline due to the stringly-typed nature of it.
Do you have any examples of well trafficked sites with good UIs doing things well? It would seem that there might be outliers you might be able to point to
Most are from a world that is better, but which the complexity merchants have convinced (thanks to asymmetric information) all but their closest competitors to replace with unwieldy tech.
The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration.
Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money.
The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.
This is looking at the "fully loaded" time. I can tell you this, you can make the fastest retail website ever seen with 100 score on lighthouse and it's going to get absolutely murdered when you try to deploy it.
The business will want pixels. Data analytics. AB Tests. Social buttons. These will be attached to million dollar campaigns. You do not get to say no. There goes your "fully loaded" time. Every client side event is now wrapped in nasty JS beacon reporting, probably a few of them.
The home page team wants recommendations that can't be cached. It's determined to fetch this on the client to enable a faster TTFB. All those products need to fetch images, too. The time to interactive bumps up a bit.
After a while, it turns out even the CMS static content wasn't safe. The CMS team wants interactive elements. You hack a little more JS. The time to interactive bumps up a bit.
The checkout team has a more dynamic approach because of the user expectations. They use some packages they want preloaded because the metrics tell them that getting to checkout faster means more conversion. More unused JS to load on the homepage in case of clicking "add to cart." You might argue about it, the button could take you to the cart page and the server could perform the add to cart. Maybe you win and implement it. This version fails the AB test.
After a while of this, the team chafes at plain css. Just 10% of it is still used on the homepage and people are afraid to delete things because it's so hard to know what the effect is across the site. The common css continues to bloat for forever. Some day, years from now, it's such an unrecognizable mess that the decision is made to delete and start over.
The JS isn't aging well either. Just writing script tags led to poor reusability and breaking the browser cache too often. Pretty early on somebody added rollup and a major project is done to clean up script tags. Progressively enhancing the "legacy framework" html worked well in the beginning but now you're staring at a mile long bug backlog of reports like "when in this state, click this thing and then click the other thing and it's not showing expected x."
Worse, you can't hire any frontenders. Gone are the days when frontend would also know whatever "legacy" backend framework you have. They don't want to work in PHP or Java or whatever, they want to specialize in the frontend. Most of your frontend team joins, complains loudly and leaves inside a year.
I've lived this nightmare a few times. I have cleaned up after this nightmare a few times.
React is ~40kb of well-earned patterns and a sane way to handle complexity over years of development. You still have to engineer well, but after having seen really smart people fail with seemingly smart frameworks, I appreciate the React way.
This sums it up exactly. The problem is with the decision makers who are almost never the dev team. Even when it is the dev team’s fault, that is often also the fault of management who cheaped out and hired a junior team rather than paying for experienced devs to do the spearheading.
The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.
But let's say you are!
In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.
Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:
YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.
Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.
Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.
In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:
I feel that there is a bit of miscommunication here. You focus your efforts on arguing against React. I do not disagree. I would love nothing better than to throw away React and embrace Lit or native web components for the heavily interactive sites with deep sessions. However, components is just a part of the story. There is also state management, client-side caching, server-side rendering with subsequent hydration, bundling and code splitting, etc. to think of — on which we are hearing little to no guidance from mature developers such as yourself, and, in absence of such guidance, have to fall prey to the twitter thinkfluencers from the js industrial complex that you denounce, but who promise some concrete solutions.
I completely agree react/angular/vue have a place and there are instances where they are essential, but too many programmers are reaching for them as the "only" way to build a web app.
And old, boring framework like rails or django can absolutely provide an adequate ux, especially for smaller projects.
There is still a need for straighforward crud apps modifying business data for internal users, and rewriting these apps in a js framework will introduce a lot of complexity that is simply not needed.
> Do you realise that you are talking of a really small minority of what these tools are used for?
I absolutely do realise that; but the author seems to ignore them altogether (which is a bit odd, given his normally commendable spirit of inclusion). Contrast this with Jason Miller's (another Googler, author of Preact) guide to different architecture decisions based on different product requirements [0]:
Can be, but having actually looked at (and worked on!) the YT frontend code base, you should use Angular/React. YT FE seems simple but there is a lot of stuff happening behind the scenes.
But how much of the "stuff" is actually necessary? I think part of the point is that the FE complexity is not inherent to the problem being solved, but a side-effect of having too many engineers and PMs with not enough to do, so new problems need to be invented, thus creating the complexity that then requires something like Angular/React.
While Youtube works okayish, most major FE heavy sites suck. Facebook, Linkedin and almost everything that Google produces (Gmail, Google Cloud console, Firebase console) are some of the slowest, buggiest websites created and would be improved by using less React/Angular.
Sure, Figma and Photoshop are a different breed, but the vast majority of CRUD apps should not be SPAs.
> But how much of the "stuff" is actually necessary?
That's up to the business (product owners) to decide, isn't it? Not up to developers. Take a look at a video page on youtube, and catalog how much interactivity is happening there — the player, which can switch between videos, which need to stay in sync with the description and the comments section; and both need to stay in sync with the suggested videos list on the right. The user can react to a video; or share it; or write a comment; or respond to another commenter. Both the suggested videos list on the right and the comments section need to load new items as the user scrolls down... Plus, if the video happens to be streamed, there is an interactive chat section on the right; and presumably some way to reward the streamer with donations.
All that even before one turns their attention to the youtube studio screen, where the user can upload and edit their videos.
Product requirements is not something that developers have control over. All they can do is adapt their code, say "yes sir", or "I don't know how to do this".
Something I've tried to highlight in other posts, and perhaps skimped on in the verbiage around the lists, was that results for users are the result of culture, not technology. I've worked with teams that absolutely killed it using slow-as-molasses tools (React, Angular...even Ember), and I've seen teams screw things up with "fast" tools.
But the outliers are just that. In the main, what I observe as most determinative of good outcomes is the marriage of stack complexity with management (which can be at the TL level, not necessarily PMs or EMs) that has the capacity to wrestle with the dimensions of complexity a stack presents.
This writeup (linked from the original article) might be helpful in outlining the way culture is co-variate with good outcomes and _tends_ to select for more appropriate tooling:
The most important outcomes being:
- Apple can be compelled to allow third-party browsers on iOS to use their own engines.
- Apple can be compelled to provide equivalent access to functionality for browsers using their own browser engines.
- Apple can be compelled to let third-party browsers install and manage web apps using their own engines.
- Apple can be compelled to remove barriers to web app adoption, such as implementing a web app equivalent to smart banners or install prompts in iOS Safari."