Google is killing the open web

Ok, but were they open web standards? That's the topic at hand here. Regardless, that just shows Google doesn't care.

Do people buy chat apps? Web browsers? Web servers? Web content? Clients or servers for other open standards?

No, which means you’ll never see them get the level of polish or investment that closed stuff gets. Because when it’s closed you can make people pay or monetize it with advertising.

I’m not cheering for this. Don’t shoot the messenger. I’m pointing out why things are this way.

A major problem is that while free software efforts can build working software, it often takes orders of magnitude more work to make software mere mortals can use. That kind of UI/UX polish is also the work programmers hate doing, so you have to pay them to do it. Therefore closed stuff always wins on UI/UX. That means it always takes the network effect. UX polish is the moat that free has never been able to cross.

They prefer it but they don’t pay for it.

There are a lot of comments focusing more on the specifics of XML and XSLT because that's what much of the article laboriously drones on about, despite its general title.

Yes, RSS.

Tons of APIs and applications work with XML. XSLT less so; that's more of a backend language.

Immaterial. If the answer is either 'yes' or 'no', it makes no actual difference: gopher still exists, is still a thing, is still successful. It feels like you're just trying to move the goal-posts and redefine what 'lose' means and trying to lure the poster into a "gotcha".

Looking at the list, what actually jumps out at me is there is probably a gap in the world of standards for a JSON-based replacement to RSS. Looking it up someone came up with the idea of https://www.jsonfeed.org/ and hopefully it gains traction.

In hindsight, it is hard to imagine a JSON-based RSS-style standard struggling to catch. The first project every aspiring JS developer would be doing is how to add a feed to their website.

EAD does indeed look like a good example of why we shouldn't use XML.

I have a hilarious example of this. I was hired to consult at a large company that had "configurators" which were applications that decided all sorts of things for if you were building a new factory and needed to use this company's stuff for your factory, so for example one configurator would be a search for replacement part in your area - so if you are building a factory in Asia but you want to use a particular part but that part is has export restrictions for it from the U.S where it is manufactured you would use this tool to pick out the appropriate replacement part made somewhere in Asia.

They had like 50 different configurators built at different times using different tech etc. (my memory is a bit fuzzy here as to how many they had etc. but it was a lot) So of course they wanted to make a solution for putting their codebase together and also make it easy to make new configurators.

So they built a React application to take a configurator input format that would tell you how to build this application and what components to render and blah blah blah etc.

Cool. But the configurator format was in JSON so they needed to make an editor for their configurator format.

They didn't have a schema or anything like this they made up the format as they went along, and they designed the application as they went along by themselves, so application designed by programmers with all the wonder that description entails.

That application at the end was just a glorified tree editor that looked like crap and of course had all sorts of functionality behavior and design mixed in with its need to check constraints for outputting a particular JSON structure at a particular point. Also programmed in React.

There was about 10 programmers, including several consultants who had worked on this for over a year when I came along, and they were also shitting bricks because they had only managed to port over 3 configurators, and every time they ported a new one they needed to add in new functionality to the editor and the configurator compiler, and there was talk of redesigning the whole configurator editor cause it sucked to use.

Obviously the editor part should have been done in XML. Then people could have edited the XML by learning to use XML spy, they could have described their language in XML schema real easy, and so forth.

But no they built everything in React.

The crowning hilarity - this application at most would ever be used by about 20 people in the world and probably not more than 10 people at all.

I felt obligated by professional pride (and also by the fact that I could see no way could this project keep being funded indefinitely so it was to my benefit to make things work) to explain how XML would be a great improvement over this state of affairs but they wouldn't hear of it.

After about 3 months on it was announced the project would be shut down in the next year. All that work wasted on an editor that could probably have been done by one expert in a month's time.

> Calling XML human readable is a stretch.

That’s always been the main flaw of XML.

There are very few use case where you wouldn’t be better served by an equivalent more efficient binary format.

You will need a tool to debug xml anyway as soon as it gets a bit complex.

By efficiency, I mean it's text and compresses well. If we mean speed, there are extremely fast XML parsers around see this page [0] for state of the art.

For hands-on experience, I used rapidxml for parsing said 3D object files. A 116K XML file is parsed instantly (the rapidxml library's aim is to have speed parity with strlen() on the same file, and they deliver).

Converting the same XML to my own memory model took less than 1ms including creation of classes and interlinking them.

This was on 2010s era hardware (a 3rd generation i7 3770K to be precise).

Verifying the same file against an XSLT would add some milliseconds, not more. Considering the core of the problem might took hours on end torturing memory and CPU, a single 20ms overhead is basically free.

I believe JSON and XML's readability is directly correlated with how the file is designed and written (incl. terminology and how it's formatted), but to be frank, I have seen both good and bad examples on both.

If you can mentally parse HTML, you can mentally parse XML. I tend to learn to parse any markup and programming language mentally so I can simulate them in my mind, but I might be an outlier.

If you're designing a file format based on either for computers only, approaching Perl level regular expressions is not hard.

Oops, forgot the link:

[0]: https://pugixml.org/benchmark.html

RSS says hi!

This is why you can have attributes in a tag. You can make an XML file self explanatory.

Consider the following example:

    <MyRoot>
      <AnElement type="list" items="1">
        <Item>Hello, World!</Item>
      </AnElement>
    <MyRoot>

Most parsers have type aware parsing, so that if somebody tucks string to a place where you expect integer, you can get an error or nil or "0" depending on your choice.

The same reason they use Node.js for their web server: They don't want to learn another language, and for their specific use case quality probably doesn't matter too much.

"Choice" is a big word here. It would imply "we've weighted the alternatives, the pros and cons, we've tested and measured different strategies and implementations and we came out with this conclusion: [...]." You know, like science and engineering.

While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."

Most of the issues of using client-side XSLT is that browsers haven't updated their implementations since v1 nor their tooling to improve debugging. Both of these issues are resolved improving the implementations and tooling, as pointed out by several commenters on the GH issue.

There is a donate button in the top right of https://ladybird.org/

> Why side with the megacorps

Reflexively siding with the tech majors is about as dogmatic as reflexively siding against them.

XSLT is a terrible tool for that job. RDF combined with something like SPARQL is much closer to that, and makes for one of the greatest knowledge processing tools nobody ever uses.

XSLT is designed to work on XML while HTML documents are almost always SGML-based. The semantics don't work the same and applying XML engines on HTML often breaks things in weird and unexpected ways. basic HTML parsing rules like "a <head> tag doesn't need to be closed and can simply be auto-closed by a <body>" will seriously confuse XML engines. To effectively use XSLT to extract information from the web, you'd first need to turn HTML into XML.

> XSLT would allow anybody with a minimum of effort to extract semantic information from the web.

XSLT has been around for decades so why are you speaking in hypotheticals, as if it’s an up-and-coming technology that hasn’t been given a fair chance yet? If it hasn’t achieved that by now, it never will.

I feel like this is overly conspiratorial. Likely they want to remove it because it's a pain to support, and used by an ever shrinking proportion of the internet. I don't even necessarily think removing support is a terrible thing, if you want to turn XML into HTML or whatever with XSLT you're still very welcome to do so, you just might have to do it server side rather than expecting every web browser to it for you.

> a minimum of effort

That is not a combination of words that should be mentioned in the same sentence as the word XML or, even worse, XSLT.

XML has its value in enterprise and reliable application development because the tooling is very old, very mature and very reliable. But it's not something taught in university any more, it's certainly not taught in "coding bootcamps", simply because it's orders of magnitude more complex than JSON to wrap your head around.

Of course, JSON has jsonschema, but in practice most real-world usages of JSON just don't give a flying fuck.