The dominance of Chromium, and Google's dominance over the project, started being a more widely discussed issue. Not without reasons: Google increasingly prioritizes their own interests over the users'.
Take a look at the Web Topics API, rolled out to some portion of stable users since Chromium 115, as a very good example (bold mine).
Topics is a proposal in the Privacy Sandbox designed to preserve privacy while showing relevant content and ads. The browser will infer a handful of recognizable, interest-based categories based on recent browsing history to help sites serve relevant ads. With Topics, the specific sites you’ve visited are no longer shared across the web, like they might have been with third-party cookies.
This entire proposal assumes that
either the web browser is not a tool acting on behalf of a user, or that being shown (relevant) ads is the user's interest when browsing the web.The former sounds like Google, whose browser had an almost 65% share of web traffic in 2022, according to StatCounter, is not afraid of acting against their own users. This goes against principles shown in IETF's standards specifications, fundamental for the web, where a more broad term for a web browser is "user agent". (IETF's RFC 8890 is a good read.) The latter sounds weirdly unlikely, but convenient to Google, as a company in the advertising industry.
To be clear, Google Play Services on Android have for a long time had Advertising IDs, effectively making the same assumptions for an operating system. Even worse, since this provides a unique identifier for a particular user.
Why limit to a pre-defined set of interests now, instead of an ID? I can only imagine GDPR having something to do here. Maybe this way there's no user identifier, or database holding it, thus no responsible data controller? Maybe if this data is only provided to an advertising network when loading ads, without any other identifiers, it can suddenly just be processed within the legal basis of legitimate interest (instead of user consent), by removing the part where a user is identified by some party? snorts drugs.
This is just the tip of the iceberg. Web standards ultimately die or thrive by Google's decision. If Google doesn't like, say, an image format, it won't get support in Chromium. Almost 65% of web users in 2022 have used Google Chrome. But it doesn't even stop here. Microsoft Edge, another 4% share, is also based on Chromium. Almost 3% to Samsung Internet, based on Chromium. Opera - 2%. UC Browser, Android WebView - almost 1% each.
Summed up, that's 75,6% of the market share.
This is not a theoretical issue or even example - it was the fate of JPEG XL. (Surely nothing to do with Google being a major contributor to AV1, and AVIF, the biggest competition of JXL.)
The web is, by now, Chromium-shaped.
In some ways, the web seems to be healing.
Servo, a Rust-based web engine, got moved from the hands of Mozilla, who got bored with it, into Linux Foundation Europe, where its development got revived.
Ladybird, the engine developed as a part of SerenityOS, gained some traction too, including a 100,000 USD sponsorship from... Shopify. I can only speculate that Chromium dropping support for JPEG XL contributed to this. Shopify has, in fact, praised JXL months before in the Chromium bugtracker:
We are eager for this feature to I2S [intent to ship - annot. lnl]. [...] A few general observations we have found through our implementation (again from a commerce focus):
- Encoding jxl, when bucketed by megapixal size of images, is significantly faster to encode compared to AVIF.
- Commerce is very colour sensitive and we have found jxl produces much higher fidelity and colour accurate images.
- Quality/bytewise: jxl produces higher quality images when normalizing for target filesizes and produces smaller files when normalizing for experience quality.
And I do wish all the best to Servo and Ladybird. But this is just the engines.
Engineers keep building all these open browser engines. And what for? Oh, right, for all the closed projects to work in them.
In its early days, the web was markup. The browser was to meant to display text with some basic formatting and hyperlinks. At some point in the later evolution, JavaScript was created, allowing websites to dynamically change their content on the device. What happened in the meantime? A mess.
Websites got replaced with web apps. We call news sites "sites" out of habit, but when we open them, they don't just display a page with an article. We get greeted with banners asking to consent to ad profiling. The browser is fetching 9 MBs of unreadable, pre-processed JavaScript for an app (that's with uBlock Origin on, without the blocked 13 script requests). I see a view inside the app, that happens to be showing an article (together with an autoplaying video, and trying to display ads). All this code with functions rendering a new article is ready, if I want to read another article, so it only loads data instead of a page. Except the whole page rendered would be less data, really. (Yes, this is a real, major news publisher.)
Web apps became just apps. Web is the most obvious target for most new apps, with the popularity of web technologies. Uncomparable to any native platforms.
Web app technologies became incoherent, prioritizing developer experience over user, and not making the former great either. Web browsers introduced cascade stylesheets a lot of time ago, to allow separating the styling from the content and stop repeating it all the time. Moders developers went back, using the class field to define styles for each item separately again. I'm not kidding. The CSS1 specification from 2008:
<P STYLE="color: green">While the paragraph is green.a 'STYLE' attribute on an element inside 'BODY' [...] mixes style with content and loses the corresponding advantages of traditional style sheets.
To increase the granularity of control over elements, a new attribute has been added to HTML: 'CLASS'. All elements inside the 'BODY' element can be classed, and the class can be addressed in the style sheet [...]. One can address all elements of the same class [...] in the selector:
.pastoral { color: green } /* all elements with CLASS pastoral */
A lot of modern web now works on styles with content again, where the styles are contained in the "class" attribute. Yes, I am subposting Tailwind CSS right now. This is real HTML on a real website (added whitespace for convenience):
<blockquote class="
typography__blockquote
mt-6
font-serif
font-bold
text-[1.8125rem]
leading-[2.75rem]
text-gray-900
before:inline-block
before:mr-3
before:h-[0.8125rem]
before:w-24
before:bg-red-700
dark:text-gray-50
dark:before:bg-red-400
print:dark:text-black
before:print:dark:bg-black
">
Q: "how long before someone invents the css of tailwind where you can put all the classes in a separate file next to element selectors? would make it way easier to have consistent use of classes across a document without repeating yourself all the time /s"
A: This has already happened! A monster straight up from Tailwind's documentation:
@tailwind base;
@tailwind components;
@tailwind utilities;
@layer components {
.btn-primary {
@apply py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75;
}
}
Native apps are like the web apps. Modern applications - no matter what platform you are running them on - shape their behavior strictly following the possibilities on the web. Any new voice or video chat is WebRTC, any instant 2-way communication with a server is WebSockets, any server requests are HTTP requests, any server response with data is JSON.
Web apps are the "native" apps. 300 MB binaries, containing a full browser implementation with little change to supported Web APIs, even though most are not getting used by the app, are shipped together with web apps that have bindings to smaller pieces of native code, to be run locally, instead of actual platform native apps.
Nobody actually knows what's needed for screen share to work on Wayland. Apps don't even try to fight for users by improving a horrible user experience like this.
I think what's most important about this evolution is that, instead of apps, everything becomes a service. The category that saw the highest increase in switching to web apps was communication - this always was a service by its nature, but we've also seen a switch away from vendor-independent, standardized protocols like IMAP and SMTP, into proprietary webmails, provided by vendors as part of the service.
But even things that could perfectly be a normal app, become web apps. Document editors are a good example. Microsoft Word has long been a native application - you could just open it on your Windows machine and operate on doc files. They've been earning on the sales of Microsoft Office - software for you to run on your machine. What were the issues? The format got reverse engineered, first by Apple, as Office for Mac started being incompatible with documents produced on the Windows equivalent, to create compatible apps. Oh no, not a competitor in my network effect! Also piracy. Oh, and you have to innovate in some ways, so new versions get bought. Yeah, can't keep up like that, can we?
Office 365 is great! Just not for you. It's a monthly or yearly rent, paid upfront! A document editor very often is a tool to perform work, that is, it's a necessity for you to earn money, so you can pay rent and live. How far can the prices go? Well... how much of your salary do you spend on rent?
The web keeps evolving. What's in the queue? Web apps going "lower level", using WebAssembly, WebGPU, WebHID, and zero WebHTML. The vision comes from Hixie, the tech lead of Flutter, formerly - specification editor in WHATWG.
All this vision has to do with the web as it was invented, is that it runs on web browsers. In pretty much any other ways, it's not much different than any native app. In fact, you literally can run the same Flutter apps using GLFW or Skia.
The consequences of the first browser war are still haunting us all.