Google is managing to achieve what Microsoft couldn’t: killing the open web. The efforts of tech giants to gain control of and enclose the commons for extractive purposes have been clear to anyone who has been following the history of the Internet for at least the last decade, and the adopted strategies are varied in technique as they are in success, from Embrace, Extend, Extinguish (EEE) to monopolization and lock-in.
What I want to talk about in this article is the war Google has been waging on XML for over a decade, why it matters that they’ve finally encroached themselves enough to get what they want, and what we can do to fight this.
↫ Oblomov (I can’t discern the author’s preferred name)
Google’s quest to destroy the open web – or at the very least, aggressively contain it – is not new, and we’re all aware of it. Since Google makes most of its money from online advertising, what the company really wants is a sanitised, corporate web that is deeply centralised around as few big players as possible. The smaller the number of players that have an actual influence on web, the better – it’s much easier for Google to find common ground with other megacorps like Apple or Microsoft than with smaller players, open source projects, and individuals who actually care about the openness of the web.
One of Google’s primary points of attack is XML and everything related to it, like RSS, XMLT, and so on. If you use RSS, you’re not loading web pages and thus not seeing Google’s ads. If you use XSLT to transform an RSS feed into a browsable website, you’re again not seeing any ads. Effectively, anything that we can use to avoid online advertising is a direct threat to Google’s bottom line, and thus you can be certain Google will try to remove, break, or otherwise cripple it in some way.
The most recent example is yet another attempt by Google to kill XSLT. XSLT, or Extensible Stylesheet Language Transformations, is a language which allows you to transform any XML document – like an RSS feed – into other formats, like HTML, plaintext, and tons more. Google has been trying to kill XSLT for over a decade, but it’s such an unpopular move that they had to back down the first time they proposed its removal.
They’re proposing it again, and the feedback has been just as negative.
And we finally get to these days. Just as RSS feeds are making a comeback and users are starting to grow skeptic of the corporate silos, Google makes another run to kill XSLT, this time using the WHATWG as a sock puppet. Particularly of note, the corresponding Chromium issue was created before the WHATWG Github issue. It is thus to no one’s surprise that the overwhelmingly negative reactions to the issue, the detailed explanations about why XSLT is important, how instead of removing it browsers should move to more recent versions of the standard, and even the indications of existing better and more secure libraries to base such new implementations on, every counterpoint to the removal have gone completely ignored.
[…]In the end, the WHATWG was forced to close down comments to the Github issue to stop the flood of negative feedback, so that the Googler could move on to the next step: commencing the process of formalizing the dismissal of XSLT.
↫ Oblomov (I can’t discern the author’s preferred name)
At this point in time, there’s really no more web standards as we idealise them in our head. It’s effectively just Google, and perhaps Apple, deciding what is a web “standard” and what isn’t, their decisions guided not by what’s best for a healthy and thriving open web, but by what’s best for their respective bottom lines. The reason the web looks and feels like ass now is not because we wanted it to be so, but because Google and the other technology giants made it so. Everyone is just playing by their rules because otherwise, you won’t show up in Google Search or your site won’t work properly in mobile Safari.
This very detailed article and the recent renewed interest in XSLT – thanks for letting everyone know, Google! – has me wondering if OSNews should use XSLT to create a pretty version of our RSS feed that will render nicely even in browsers without any RSS support. It doesn’t seem too difficult, so I’ll see if I can find someone to figure this out (I lack the skills, obviously). We’ve already removed our ads, and I think our RSS feed is full-article already anyway, so why not have a minimal version of OSNews you could browse to in your browser that’s based on our RSS feed and XSLT?
Sorry, but this is contrived nonsense. Or with the more technical term: B.S.
I was at Google during many of these developments, some of them extremely close. So, I know the actual backstory.
AMP for example was done by our sister team sitting on the other side of our floor. I think people are rewriting history, but it was a real welcome change, especially liked by the publishing community:
https://blog.velocity23.com/blog/what-does-amp-mean-why-matters
My colleagues were flying off almost every week to major publisher headquarters to make sure the new technology was meeting their demands. Most seem to have forgotten, but it was the time mobile web finally took hold (surpassed desktop for more than 50% share), and also was in a terrible state.
Most news sites took 30+ seconds to loads, pages reshaped themselves whiles scrolling, intrusive multiple full page ads were common, and overall usability was at the bottom.
This led to proliferation of closed news mediums, like Facebook News, which was devoid of ads, and was a closed paid system. Downside? Cannot be accessed outside of Facebook.
And this was not the only example. The open web was going down, while walled gardens were being put up.
So, Google did two things:
1 – Ran an ultimatum: if your page does not render quickly and correctly on mobile, it will receive a massive penalty in Search and News ranking.
2 – Here is an open source javascript / http5 library called “amp”. If you use it, you will automatically handle all those requirements.
And it quickly worked. Many of our partners in publishing quickly adopted it (sorry, I’m not sure I can list names here) and the mobile web became fast and usable.
But 10 years after the fact people rewrite the facts as if this was exact opposite of what happened. No, please do not spread misinformation.
For instance from back then:
https://medium.com/tow-center/the-end-of-the-news-as-we-know-it-how-facebook-swallowed-journalism-60344fa50962
You can easily fine many more examples understanding the value of amp from that time.
@sukru
I do not remember AMP as fondly as you do and many of us were in no rush to adopt it. In fact, I would completely agree that AMP was an attempt by Google to break the open web (not that this was the primary goal).
Large publishers used AMP not just for the technology or even the speed but simply because Google ranked your pages higher if you did and featured them more prominently. So, while I have no doubt Google engineers were jet set and very busy, I am not sure that is a real endorsement. It also does nothing to address whether Google is killing the open web or not.
AMP does not do much to prove the author’s point though and perhaps serves as evidence of the opposite. AMP, while it still exists, has not mattered in 10 years. A tiny fraction of the web uses AMP. The metrics that Google uses to prioritize sites today work perfectly well with open technologies and standards. If AMP is the metric, Google is dramatically more pro open web than in the past. Is one of the largest players in the space just too incompetent to execute their evil plans?
Where I completely agree with you is that what Google has done, persistently, is to push for a faster web. This is what Chrome has represented from the beginning, especially for Javascript. And using a Google CDN to serve up JQuery was a big speed boost for the web as well. Faster protocols, WASM, it all continues the trend. And the move from NatveClient to WASM is another move towards the open web and away from the author’s claims. And Javascript, after all, is part of the open web as well (including the open sharing of Javascript source code).
And Google did push mobile very hard in search results which was a very good thing for the open web as well. But it was a very challenging time in web development. We went from every web browser being 800 – 1000 pixels wide to some screens being very much larger and some being very much smaller. Responsive Design was essential. But the tools and technologies did not make it easy. CSS was feature poor and inconsistently standardized. Javascript was slow. AMP was not the only way to make a good experience. But you are not wrong that the world was crying out for a way to make things easier.
Google’s focus on both mobile and speed have been fantastic tailwinds for the open web. Too bad we have wasted it on massive Javascript SPA frameworks and 42 trackers per page from the ads.
LeFantome,
Amp was an entirely optional technology that aimed to help web developers. It had zero effect on ranking.
Or more specifically there was no:
if (AMP) then (rank higher)
But is was more like
if (Slow) then (rank lower)
(To extremely simplify). Web developers were free to implement their own solutions as long as it rendered fast and correctly on mobile. (Basic HTML5 would for example be perfectly fine)
And publishers were not pushed either. They were co-developers of the technology from day one. Programs like Digital News Initiative and direct collaborations made sure the design was up to their needs. And that is why it was quickly (and voluntarily) adapted by a large number of them.
https://en.wikipedia.org/wiki/Accelerated_Mobile_Pages#Announcement_and_launch
I agree some third party websites might have felt it was pushed on them. But the reality is their previous sites were broken, and they were “punished” for not correctly working on mobile before.
I agree. But a slow web leads to a “closed” web as people move away from open web pages to apps. So that is the whole point.
It has served its purpose. In fact, I think some of the features have been retired as no longer necessary.
@sukru
If AMP did not get preferential treatment, why did Google have to explicitly have to stop doing it in 2021? The following contains quotes about it from Google themselves.
https://plausible.io/blog/google-amp
But note these quote from that article as well:
“So many websites, particularly news publishers, felt like hostages and were forced to use AMP with the only motivation being the promise of more search traffic.”
“Google has been pushing sites to use AMP for years and continues to recommend it as ‘the majority of the AMP pages achieve great page experiences’. But for websites that are optimized for speed, their AMP pages are often slower than the regular pages.”
The popularity of AMP dropped-off significantly after the 2021 change. Not a coincidence.
LeFantome,
If you look at the quotes, it was not a ranking feature, but a rendering one.
AMP allowed Google to quickly render previews (and others like Twitter, Bing, and so on did the same). The “AMP Viewer” allows the page to be hosted in an specialized iframe:
https://developers.google.com/search/docs/crawling-indexing/amp/about-amp
When Google had a better sandbox, it no longer needed AMP for previews / embedded views.
That is different than ranking, for example used in News where articles have “Title + Abstract + Link” which does not require rendering their HTML.
Yes, and every time you deploy an HTTPS server certificate signed by a central root CA, you are adding to the problem.
I made the most anti-Google web of mine, a conversion of my blog (in spanish) in full TXT 90’s style: https://txt.fabio.com.ar/
All the images are dithered 2 colors, Text is all monospace and it has ZERO javascript, well just the small js Cloudflare adds, but zero from me, not even CSS files at all.
I think we can play without google and we must, my next project is a small search engine for blogs, the only problem is get all those RSS without being blocked by Cloudflare and protections like that
@Fabio
Your blog looks awesome by the way.
thanks!
This article does not do much to back-up its title. If you just want to say that Google is evil, few will rush to their defense but, if you are going to make a claim, your facts have to support it.
First, Firefox killed Internet Explorer. The war was not completely won when Chrome appeared but Firefox was the browser to beat. And Chrome and Firefox worked hand-in-hand for years to usher in the open web. Chrome won because of the Google focus on speed. Firefox joined that fight too late. And developers standardized on Chrome’s web tools. No arm twisting or shenanigans required.
And XML is a strange hill to die on. The decline of XML has everything to do with the rise of JSON and that has been driven mostly be individual developer preference become industry trend. And JSON was part of the Javascript language before Douglas Crawford extracted it to send messages. JSON is arguably more a native part of the “open web” than XML is. The Fetch API is demonstrably better than XMLHttpRequest. You can use the Fetch API to retrieve XML if you want. So what are they talking about?
And while you may prefer JPEGXL over AVIF, it is easy to argue that AVIF is the better choice for the web on purely technical grounds. And as AVIF is royalty free and Open Source, it is just as qualified to be part of the “open web”. Choosing AVIF over JPEGXL may be a bit Not Invented Here but it is not “killing” the open anything.
Reading just the headline, I was half convinced. But after reading the article, I am not convinced at all.
LeFantome,
As an heavy user of Xml in the past this brings some bittersweet memories. The entire complexity with explicit schema definitions, separate files for styles (XSLT), and the overall fragility of the system made it difficult to use outside of automated tools. And for automated tools there was as you said JSON (or more efficient representations like ProtoBuf).
As soon as XMLHTTP became JSON+HTTP and SOAP was replaced in web services, Xml adoption naturally dropped. In fact I don’t remember using any Xml file in years.
True. The current version does not bring the same enthusiasm of the past.
Yet, I would argue ignoring or even bad mouthing all the good that was done before is counter-productive and to be frank, dishonest.
I would argue Internet Explorer killed Internet Explorer. Being the dominant player they became big, stale, and extremely bloated. At the end of their reign (IE 7?) almost nobody would willingly choose it over any other browser.
@sukru
> I would argue Internet Explorer killed Internet Explorer
Completely agree. My point is that Firefox had already exploded in popularity and knocked Internet Explorer off the throne before Chrome even appeared.
Firefox had taken IE from close to 90% down to under 50% before Chrome even arrived. If Chrome had not appeared, Firefox would probably have achieved IE-like dominance. But the introduction of Chrome stopped Firefox market share growth in its tracks. As Chrome market share grew, i
LeFantome,
Yes. Firefox was dominant. Even third party ones like Opera was in the scene.
However Firefox was also a slow complicated behemoth to develop for. And people were moving in the KHTML direction. (The open source HTML component from KDE).
The first was Safari. Apple released its renderer, WebKit as open source. Google first used and contributed to it, but later forked it as Blink, which was the source of Chrome/Chromium.
But the main difference Chrome brought on was the much optimized V8 engine. It came out of necessity (all Google apps were basically JavaScript based and ran like molasses on other engines). And it started a revolution in programming (entire Node.JS ecosystem became possible thanks to V8)
The rest is history.
sukru,
Every time this subject comes up you seem to omit an important fact that google paid OEMs and software publishers to bundle chrome. Never underestimate the power of bundling. Microsoft/Google/Apple all have a huge advantage because of it. (Microsoft got neutered after loosing the DOJ antitrust case, but by then they had already crushed netscape). It’s one of the most effective ways to get to and stay at the top with typical consumers. Google paying to bundle chrome gave them a rapid boost in market share.
I do agree chrome improved javascript, but in other areas chrome had a reputation for being sluggish and bloated.
https://www.reddit.com/r/chrome/comments/1s3lcz/over_the_past_2_years_chrome_seems_to_have/
I do find chrome runs faster for me today, although it’s often cited as using considerably more memory. This doesn’t impact me because I routinely over-provision my computer memory. But if someone were hitting swap, FF might beat out chrome. There are so many different factors and optimizations it’s hard to conclusively say one is always best.
https://softhandtech.com/does-firefox-use-less-memory-than-chrome/
It could be neat to compare historical versions, although I don’t know if there’s any point in retroactively testing ancient versions beyond the curiosity factor.
@Alfman
> Never underestimate the power of bundling
Very much so. And Google used all their properties to an every opportunity to suggest to every user that they should switch to Chrome. The fact that Google designed Chrome to be modular and easily embedded made a massive difference as well though, starting with Chrome Frame. It is no accident that so many “3rd party” browsers were Chromium based even before Firefox dropped off a cliff. Same with V8 for embedded projects and–crucially–Node.js.
https://en.wikipedia.org/wiki/Google_Chrome_Frame
> often cited as using considerably more memory.
Very much so. As somebody that wants to use 10 year old hardware and still have 100 tabs open in a browser (for some reason), Firefox is massively more usable on lower end, memory constrained systems.
But @sukru is absolutely right in his main point that Google won with a focus on speed. They relentlessly drove the performance of Javascript in particular. The fact that we now how bloated SPA properties and electron apps is only possible because of how much performance Google has wrung out of web browsers. Is any of that a good thing? We all have our opinions.
Alfman,
That is true, but don’t overestimate it either.
After all OEMs bundled Windows with all kinds of crap, and they rarely held on. Even Windows itself bundled Internet Explorer, but that too had to die off. Or Firefox tried bundling Yahoo! as their main search engine, … and… anyway you get the idea.
The only way the bundled thing stays on is if it is actually at least good enough. Nobody would stick with (a random browser) it it was bad.
That being said…
The fall of Firefox was like the fall of Internet Explorer. It lost its soul.
Specifically, it lost what made it unique: XUL
It was a slow process, but I vaguely remember it. First they abruptly changed their UI to be “just another Chrome clone”. They “simplified” the menus, removed the search bar, and merged it into the URL bar, moved things around and lost their unique style.
Then they dropped the well established XUL system for something that is similar to (and compatible with) Chrome plugins.
I think this was around 2014, and that is when I dropped Firefox as well. (Today, I switched back… to a point as Chrome is currently the one full of crap).
Why did it happen?
To be fair, it was due to practical reasons as developing XUL, a whole platform by itself was a burden.
But then they were also running like a headless chicken trying many random ideas like a Mozilla Phone, a Macromedia Flash clone, asm.js, a calendar application, a messaging platform, a vpn, and many others. Almost all failed, and they all lost Mozilla valuable time and resources.
(Some of them were related though, like asm.js is actually quite important)
Anyway… I’m not sure how they would sufficiently fund themselves by focusing on the browser only, though. We had discussed this before, a massive project like a web browser (much larger than Linux kernel) is not a small endeavor.
LeFantome,
It is a trade-off between speed and memory usage.
I’m not privy too all implementation details, but as far as I know Chrome keeps (used to keep?) pre-rendered versions of your history.
So, not only switching between tabs is fast, but also moving back in history is almost instantaneous.
(I think they do some garbage collection now).
This and similar tricks help make the entire user interface extremely fast and responsive.
And, yes, the JavaScript engine itself is real fast:
https://benjdd.com/languages/
It is ~50% speed of native C, which is impressive. Nothing else in the interpreted land comes close.
sukru,
Challenges can give it a go independently without bundling, but the bundled products typically win. IE was winning up until the DOJ antitrust lawsuit ripped away microsoft’s monopoly power and forced the market open for competitors. Had this not happened, browsers would look very different, and probably the entire web too.
I have my own criticisms for FF as well, but I don’t think it would have realistically made much difference long term. Their biggest hurdle was always going to be sharing a market with much more powerful corporations, practically a death sentence.
Well, I think that mozilla correctly identified that FF was not going to be able able to thrive as an independent browser on competitor platforms; Firefox couldn’t compete with chrome on android nor safari on iphone. So in this sense firefox phone wasn’t random at all, but rather a logical way to create a platform where the FF browser could have home field advantage. Obviously mozilla failed, along with everyone else who tried competing with the apple/google mobile duopoly. Nobody else had the apps. While I do think it made sense for mozilla to try to diversity, it didn’t work. Even with the benefit of hindsight it’s hard to see a winning path for mozilla given who they were up against.
https://www.cnet.com/tech/mobile/why-the-death-of-the-firefox-phone-matters/
Yea, it’s not easy and even more difficult when you have to compete with free competitors.
sukru,
Just for kicks I threw the source into openai’s gpt-oss-20b running locally. It replaced the loop with an analytical solution of it’s own creation that runs in constant time, much faster than the original C! I checked for correctness and it passed first time. Beyond supplying the code, I didn’t need to interact with the LLM to refine the output.
This wasn’t a complex problem, but I am impressed that it just worked without any real effort on my part suggesting that this could be automated. It opens up new possibilities software optimization! I don’t necessarily trust a general purpose LLM to get things right all the time, but a special purpose LLM that can only make mathematically verifiable changes could be a real game changer here! Such a tool might be applied to arbitrary code bases and make high level code optimizations that compilers have never been able to do before using traditional methods.
Alfman,
Yes, they have made a lot of progress….
ChatGPT 5 realized this was a benchmark code, and then provided two versions, the first one was a direct solution.
And the second one just optimized the loop to remove division / remainder operations, but kept the overall structure to still be functional as a benchmark.
I’m going to say, I’m impressed. For small mechanical tasks, they are extremely helpful.
sukru,
So am I. I could see compilers in the medium term having an option to enable AI optimization. Obviously it would make a lot more sense to have a dedicated optimizing LLM rather than a generic one. Generic models like “ChatGPT” waste a lot of neurons on unrelated tasks like english language and human literature/knowledge/history/etc that serves no purpose in a specialized domain like software optimization. Getting rid of that would free up a lot more neurons to become much more specialized at software optimization. However the fact that I can use a generic downloadable model today is pretty impressive. I don’t suppose you care about this as much, but having the AI run locally is very important to me; I don’t want my build process to be dependent on someone else’s hardware.
At a previous workplace I had to deal with many XML APIs from different vendors. I learned to hate it with a passion and tried to convice my employer to use JSON internally instead.
I was later pleasantly surprised to find out my feelings were shared:
https://harmful.cat-v.org/software/xml/
I’ve used RSS and it was useful, and it’s a damn shame it died out. Indeed it’s Google’s fault, who opted against supporting it in the browser.
But I worked extensively with XML and XSLT and, by all means, kill it with fire.
XML, XSD, and XSLT rate among the most difficult programming languages I know, featuring the worst human readability and the most difficult maintenance. I once toyed with writing a version of XSLT that didn’t suck quite so horrendously, but who would use it? Why bother if we’re still stuck with XML?
I’d be willing to give JSON, etc, a try based on reading it and seeing it used by others. Unfortunately, there doesn’t seem to be a way to “try”, it has to be all out or not at all, and it would take Google to make that happen. If they decide to, it won’t be fun for a while but it could ultimately be the biggest (useful, non-buzzword) web upgrade in decades.
pauls101,
I agree with you on XSLT: awkward and difficult! XML itself isn’t so bad. It’s quite readable when “beautified” and there are lots of decent APIs for it. It’s extremely verbose though, which turns people off the format for data exchange.
There’s not much too it. Most json code assumes the input matches the expected type without running it through any kind of format verification, which could be a con.
What application are you thinking of converting to JSON? Often times small developers face a similar dilemma; regardless of their qualifications to build out new infrastructure/standards/formats/protocols/etc, being a small player means their work is unlikely to be used by many. Meanwhile the same person doing the same job at google/redhat/ms/apple/etc could have their work used by millions/billions.
It’s unfortunate how quickly Google-ers at the WhatWG group are locking down on public comment. They really seem bent on moving forward with their own agenda. The reasons for deprecating XSLT support seem to mainly consist of “it’s difficult to support” and “not a lot of sites use it”, despite public comment showing that there are large orgs that will be affected. The language isn’t making headlines as far as I can tell, so why pick on it now? Someone creatively thought of some busy work to sharpen Google’s competitive edge and “deliver shareholder value.”
This is a great time to make XSLT better. Does it has memory safety issues? Fix them. It has security issues? Audit and fix. Rust could be a good language to make a fresh implementation.
I don’t see this attempt to deprecate XSLT as a public service, doing good for everyone, since Google is a shareholder-owned corporation that has proved their extreme self-interest and willingness to destroy numerous useful technologies to serve their own goals.
FWIW, XML is still used heavily in library/information science (LIS). I’m studying for a master’s degree in LIS. One of my professors, a cataloger, was surprised when I told her that XML has become passé on the Web, and is considered hard to read, presumably by humans. I find it much easier to read than JSON. I’m taking a metadata class in this coming semester, and the text that is our primary book uses XML very heavily.
Angel Blue01,
I would not say XML is any easier or harder to read than JSON (after using a tool/editor to “beautify” it).
XML could be better than JSON for metadata because you can usually add new attributes to existing nodes without breaking the document format, most programs accessing an XML DOM will ignore them. JSON’s benefit for programmers is the simplicity in mapping directly to programming language structures. Many programming languages can read/write JSON into native structure out of the box, it’s a freebie.
But it could mean that updating the program can require updating the format and visa versa. So unlike XML where you may naturally be able to add more metadata attributes and elements, JSON doesn’t support attributes on nodes and even JSON associative array ids might already have significance in the program such that you can’t add new keys without causing side effects.
XML is still commonly used. Plenty of APIs use XML for exchanging data (like product information) between servers, etc. But XML is considered less cool these days. Some software devs probably complain about it because they never learned how to program with a DOM or SAX parser, haha.
https://en.wikipedia.org/wiki/Simple_API_for_XML