19 ms·

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of w

It's easy to just mark XML off as one of the many fads in tech given how many there are. But I think it's much more worthwile to dive into the particulars of why it failed. While they're all fads, some of them share commonalities that, in hindsight, I think we can say were major catylsts to their downfall. With XML, it failed because something like JSON was much simpler. Time and time again I see people saying that json+comments would be the ideal format. Time and time again we see that people prefer simple solutions that they can get jump into easily. Maybe certain problems don't require solutions with those traits, but anything with sharing data among a diverse group of consumers does. The XML ecosystem with things like XSLT, Xquery,etc, were elegant, but also overengineered and clunky. I would even say that markup itself with closing tags were more annoying than just closing brackets. Software is still so young... I think it's good that we tried and learned something from it in the short term. Maybe one day we'll get a proper standard with all the right data types that becomes the defacto solution that people learn it even if it's more complicated.

seanp2k2 3y ago
Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" and easier to work with using normal text-based tools / curl / etc. The internet felt like magic growing up once I learned about SMTP and HTTP using telnet and played with quite a few serial terminal devices. Now with many APIs behind OAuth or worse, it's getting much less trivial to hack around with in simple ways.
- deaddodo 3y ago
  > Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" This is like comparing a Mustang engine to a racetrack. They're not even equivalent technologies. GRPC and GraphQL would equate to SOAP, REST or some other interface protocol. JSON equates to protobuf, XML or another transport format. Of those three options, I have no idea how JSON would be considered the "closest to the wire". Protobuf is definitely the lowest level, while XML and JSON are about equivalent in abstraction.
eduction 3y ago
>but I think it's much more worthwile to dive into the particulars of why it failed If you’re going to deep dive, define your terms: what did it fail at? At being the future? Kind of a straw man, even if some people did argue that. As a document interchange format? Between RSS — including podcasts! — Microsoft Office, and LibreOffice it seems to have done reasonably well. As a data interchange format? Undoubtedly JSON is now preferred for this, but keep in mind that for several crucial years, as the “X” in “AJAX,” it paved the way for modern web apps via Google Maps, Gmail, and before that Outlook for the Web (literally the original AJAX app). I think it’s not really interesting to examine how and where JSON displaced XML given this is not hard to grasp and well covered. Much more interesting to extract lessons that also work on JSON and predict what might displace it and where and how. For example it’s interesting that JSON is simpler than XML. Might it have discarded something valuable? The “X” is for extensibility - if we could extend JSON, which we can’t, how would we? First class date times might nice, mmm? Or to be able to add arbitrary other self describing data types? UUIDs? What is XML still ideal for? Etc
- Kwpolska 3y ago
  The X in AJAX is there because the devs had to put it in MSXML, because they couldn't add it to IE itself due to a code freeze, and because XML sounded cool back then. https://web.archive.org/web/20170424220609/http://www.alexhopmann.com/xmlhttp.htm https://web.archive.org/web/20170424220609/http://www.alexho... While there probably were some pages using XML in AJAX, many were just sending HTML fragments.
  - wizofaus 3y ago
    > This was the good-old-days when critical features were crammed in just days before a release Fascinating article, but really? I would have thought "cramming in" critical features days before release was more common these days, esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.
    - chrisan 3y ago
      > esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis. What does releasing regularly have to do with cramming stuff in? We release when stuff is ready. That could be multiple times a day or once a week. I think of people with set release dates as the most likely candidates of "cramming stuff in" because they fear they will miss the release and it might be a month (or worse) before the next release
quickthrower2 3y ago
XML can be simpler. In C# you could generate an XSD from a good XML example, then fix it up and generated typed, nested C# code. You now have a builder and validator for the stuff you send across the wire. You can sort of do the same with JSON though to be fair, in theory, and there are probably tools, but it wouldn't be as tight and then the "XSD" part I am not sure if there is a single spec to go with. Overall though, I prefer JSONland!
- magicalhippo 3y ago
  We use XSDs to generate JSON Schemas. The schema converter also generates code to convert JSON files to XML, so we can use our existing XML infra while we migrate. As you say both can be used to validate input and to generate typed code. However I find the XSD design tools better, so I expect we'll be doing the XSD first approach even after all our integrations are JSON native unless something radical changes there.
pwdisswordfishc 3y ago
And specifically XHTML failed for two reasons: (0) Internet Explorer did not support it, and (1) there was no good migration path out of tooling that generated HTML by unrigorous string concatenation. So instead WHATWG created HTML5, which bastardized well-designed (if clunky to use) XML features like namespaces, paving the way for vulnerabilities like CVE-2020-26870.
wvenable 3y ago
> With XML, it failed because something like JSON was much simpler. I remember when XML was pretty new and I used this new-fangled technology called XML-RPC. XML-RPC was amazing and I was using it to connect desktop applications to web applications. If you go look it up, you'll notice that bears a striking resemblance to JSON. But what technology actually took off for RPC in XML? SOAP. And SOAP is a nightmare of complexity and hardly works right the first time between heterogeneous systems. It's funny how much people want to add complexity to the JSON ecosystems with the same over-engineering that killed XML in the same space. Luckily the design of JSON is such that it resists that kind of complexity and also because XML exists it takes a bit of that load.
- Marazan 3y ago
  Adobe Flex front end connected via xml-rpc to a python backend was my favourite way of whipping up personal desktop utils back in the day.
tannhaeuser 3y ago
> With XML, it failed because something like JSON was much simpler. No. XML was introduced as a simplified SGML subset/profile to become the base for new markup vocabularies on the web; both SVG and MathML were specified using XML (and later integrated into HTML 5). The intent was also to replace HTML by XHTML. The idea to introduce service payloads as custom, non-UI XML and then transform those payloads into XHTML was induced by XML, but distinct from it. However, W3C went crazy with SOAP and XML (and RDF), attempting to establish entirely new and unproven paradigms such as XForms with XHTML2 rather than merely simplifying syntax, which was bound to fail, and laid ground for browser vendors to evolve HTML outside W3C. Then XML heads somehow felt insulted, refused to change course or learn new things. Most even didn't realize XML is just an SGML subset, and that everything that was possible using XML is by definition also possible using SGML (plus handling HTML and markdown and a couple other things making SGML more complex compared to XML). To this day, we're hearing XML heads dogmatically advertising their overly strict and verbose red-headed stepchild of a markup language, and wondering why nobody wanted to bow to XML. The article is about this kind of people who want to use their tool under all circumstances, project requirements be damned.
defanor 3y ago
To offer a different perspective: I find XML simpler in that it tends to correspond more closely to most arbitrary data models. From ADTs to C structures, there are product types and sum types to encode, along with more or less arbitrary basic types, which have text representation. With XML you get a straightforward way to encode all those, while in JSON there is no single agreed upon method to encode sum types, but you get something like string-indexed arrays (or hash tables) instead, which are normally implemented on top, using simpler types (and are not restricted to strings). And a few arbitrary built-in types, but you have to use strings for others anyway. And no built-in extensibility, so ad hoc hacks are used when it is needed. It would be particularly awkward to use for documents, too. I preferred JSON initially myself, since it seemed a little less verbose, I did not care about extensibility, did not consider its usage for documents, validation, did not care about using it for different data models, and it just seemed simple (FSVO) and straightforward. But then more of XML made sense. It is not perfect for everything, either, but the decisions behind it seem more justified to me than those behind JSON (though JSON still fits JS, at least).
bawolff 3y ago
> The XML ecosystem with things like XSLT, Xquery,etc, were elegant, but also overengineered and clunk Hell those were the better XML standards. Just consider SOAP, SAML (XMLSignature is insane), etc XML just another example that unnecessary complexity is the worst sin in software development
- 77pt77 3y ago
  SOAP still has a special place in my heart where only hate exists.
IshKebab 3y ago
I disagree. XML isn't that complex. I think it failed because: * It's overly verbose. All those closing tags, ugh. * The data model is not actually what people want most of the time. People are transferring objects, not documents. The fact that XML doesn't have a proper way to represent maps, and you have the redundancy of attributes, inline text, etc... There's a huge mismatch between the data model of XML and the data model that people usually want. * SAX is obviously a shit way to do parsing. There were DOM parsers and pull parsers but for some reason SAX was stupidly common despite being stupidly awkward.
- Marazan 3y ago
  SAX parsers are quick and easy which probably explains their prevalence.
yread 3y ago
I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!
- vbezhenar 3y ago
  JSON has schemas. Namespaces are simple, just add something like "namespace": "mynamespace" if you really need it. Comments are not really needed for machine readable formats and many JSON parsers allow comments if you need it for configs, so that's hardly an issue. Well defined dates are strings in ISO8601 format. It's not standardized with JSON, but not an issue I encounter on practice.
  - flagrant_taco 3y ago
    JSON itself doesn't have support for scheme of comments as far as I'm aware. Both are supported by individual rolls building on top of JSON rather than those features being part of the JSON spec. Whether that stiffener matters to someone is up them, but that difference is what many comments on this thread are pointing out with regards to us having spent a decade rebuild many features of XML back into JSON.
    - vbezhenar 3y ago
      XML does not have support for schemas either. XML Schemas is a separate spec (and actually not the only one, there were few competing ones). I'd use JSON schema over XML schema any day. And I read and wrote many XML schemas and still do sometimes. JSON schema actually built by sane people. If that required a decade, so be it.
      - flagrant_taco 3y ago
        Oh that's interesting, I always thought schema names pacing was a part of the XML spec, learned something new!
vbezhenar 3y ago
IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures. That's a fundamental issue and replacing XML was not that hard. My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures. Dethroning SQL much harder, though. It'll take decades. We introduced fundamental roadblocks into IT and river of time will either break those roadblocks or smooth them into shapes hardly recognizable (SQL + JSON, for example).
- mythhabit 3y ago
  SQL is a pretty decent language. Sure it could be improved and made more intuitive and maybe even simpler. Relational data maps directly to objects if you have halfway decent tooling. SQL is almost 50 years old now - it'll be here for a long time because it is actually useful paradigm that has not been outdone by other paradigms (so far).
- nordsieck 3y ago
  > My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures. I'm deeply skeptical. The relational data model is fundamentally about correctly representing relationships between data. Whereas data structures are about efficiently using computer hardware to perform computation on that data. I don't see either going away, because they're driven by fundamental needs.
- shadofx 3y ago
  To dethrone SQL, you won't cut it with just average techbro hype. You need the top award of SIGMOD renamed in honor of your paradigm's inventor levels of hype.
- titzer 3y ago
  > My prediction is that SQL will fail too...And the reason is the same: tabular data does not map well to our data structures. The whole point of SQL is that relations and relational data are not data structures. They are higher level concepts and data structures are implementation details. The reason it has survived 4+ decades is because it isn't intrinsically tied to those implementation details and instead can be reimplemented over and over and over. > There are infinite attempts to dethrone it. Viewed another way, there are infinite attempts to reinvent it, all of which keep failing, because they aren't as good.

seanp2k2 3y ago

Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" and easier to work with using normal text-based tools / curl / etc. The internet felt like magic growing up once I learned about SMTP and HTTP using telnet and played with quite a few serial terminal devices. Now with many APIs behind OAuth or worse, it's getting much less trivial to hack around with in simple ways.

deaddodo 3y ago
> Stuff like GRPC / GQL feels cool, but JSON still feels "closer to the wire" This is like comparing a Mustang engine to a racetrack. They're not even equivalent technologies. GRPC and GraphQL would equate to SOAP, REST or some other interface protocol. JSON equates to protobuf, XML or another transport format. Of those three options, I have no idea how JSON would be considered the "closest to the wire". Protobuf is definitely the lowest level, while XML and JSON are about equivalent in abstraction.

eduction 3y ago

>but I think it's much more worthwile to dive into the particulars of why it failed If you’re going to deep dive, define your terms: what did it fail at? At being the future? Kind of a straw man, even if some people did argue that. As a document interchange format? Between RSS — including podcasts! — Microsoft Office, and LibreOffice it seems to have done reasonably well. As a data interchange format? Undoubtedly JSON is now preferred for this, but keep in mind that for several crucial years, as the “X” in “AJAX,” it paved the way for modern web apps via Google Maps, Gmail, and before that Outlook for the Web (literally the original AJAX app). I think it’s not really interesting to examine how and where JSON displaced XML given this is not hard to grasp and well covered. Much more interesting to extract lessons that also work on JSON and predict what might displace it and where and how. For example it’s interesting that JSON is simpler than XML. Might it have discarded something valuable? The “X” is for extensibility - if we could extend JSON, which we can’t, how would we? First class date times might nice, mmm? Or to be able to add arbitrary other self describing data types? UUIDs? What is XML still ideal for? Etc

Kwpolska 3y ago
The X in AJAX is there because the devs had to put it in MSXML, because they couldn't add it to IE itself due to a code freeze, and because XML sounded cool back then. https://web.archive.org/web/20170424220609/http://www.alexhopmann.com/xmlhttp.htm https://web.archive.org/web/20170424220609/http://www.alexho... While there probably were some pages using XML in AJAX, many were just sending HTML fragments.
- wizofaus 3y ago
  > This was the good-old-days when critical features were crammed in just days before a release Fascinating article, but really? I would have thought "cramming in" critical features days before release was more common these days, esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis.
  - chrisan 3y ago
    > esp. if you're releasing/deploying to production on a daily (or even multiple-times-a-day) basis. What does releasing regularly have to do with cramming stuff in? We release when stuff is ready. That could be multiple times a day or once a week. I think of people with set release dates as the most likely candidates of "cramming stuff in" because they fear they will miss the release and it might be a month (or worse) before the next release

quickthrower2 3y ago

XML can be simpler. In C# you could generate an XSD from a good XML example, then fix it up and generated typed, nested C# code. You now have a builder and validator for the stuff you send across the wire. You can sort of do the same with JSON though to be fair, in theory, and there are probably tools, but it wouldn't be as tight and then the "XSD" part I am not sure if there is a single spec to go with. Overall though, I prefer JSONland!

magicalhippo 3y ago
We use XSDs to generate JSON Schemas. The schema converter also generates code to convert JSON files to XML, so we can use our existing XML infra while we migrate. As you say both can be used to validate input and to generate typed code. However I find the XSD design tools better, so I expect we'll be doing the XSD first approach even after all our integrations are JSON native unless something radical changes there.

pwdisswordfishc 3y ago

And specifically XHTML failed for two reasons: (0) Internet Explorer did not support it, and (1) there was no good migration path out of tooling that generated HTML by unrigorous string concatenation. So instead WHATWG created HTML5, which bastardized well-designed (if clunky to use) XML features like namespaces, paving the way for vulnerabilities like CVE-2020-26870.

wvenable 3y ago

> With XML, it failed because something like JSON was much simpler. I remember when XML was pretty new and I used this new-fangled technology called XML-RPC. XML-RPC was amazing and I was using it to connect desktop applications to web applications. If you go look it up, you'll notice that bears a striking resemblance to JSON. But what technology actually took off for RPC in XML? SOAP. And SOAP is a nightmare of complexity and hardly works right the first time between heterogeneous systems. It's funny how much people want to add complexity to the JSON ecosystems with the same over-engineering that killed XML in the same space. Luckily the design of JSON is such that it resists that kind of complexity and also because XML exists it takes a bit of that load.

Marazan 3y ago
Adobe Flex front end connected via xml-rpc to a python backend was my favourite way of whipping up personal desktop utils back in the day.

tannhaeuser 3y ago

> With XML, it failed because something like JSON was much simpler. No. XML was introduced as a simplified SGML subset/profile to become the base for new markup vocabularies on the web; both SVG and MathML were specified using XML (and later integrated into HTML 5). The intent was also to replace HTML by XHTML. The idea to introduce service payloads as custom, non-UI XML and then transform those payloads into XHTML was induced by XML, but distinct from it. However, W3C went crazy with SOAP and XML (and RDF), attempting to establish entirely new and unproven paradigms such as XForms with XHTML2 rather than merely simplifying syntax, which was bound to fail, and laid ground for browser vendors to evolve HTML outside W3C. Then XML heads somehow felt insulted, refused to change course or learn new things. Most even didn't realize XML is just an SGML subset, and that everything that was possible using XML is by definition also possible using SGML (plus handling HTML and markdown and a couple other things making SGML more complex compared to XML). To this day, we're hearing XML heads dogmatically advertising their overly strict and verbose red-headed stepchild of a markup language, and wondering why nobody wanted to bow to XML. The article is about this kind of people who want to use their tool under all circumstances, project requirements be damned.

defanor 3y ago

To offer a different perspective: I find XML simpler in that it tends to correspond more closely to most arbitrary data models. From ADTs to C structures, there are product types and sum types to encode, along with more or less arbitrary basic types, which have text representation. With XML you get a straightforward way to encode all those, while in JSON there is no single agreed upon method to encode sum types, but you get something like string-indexed arrays (or hash tables) instead, which are normally implemented on top, using simpler types (and are not restricted to strings). And a few arbitrary built-in types, but you have to use strings for others anyway. And no built-in extensibility, so ad hoc hacks are used when it is needed. It would be particularly awkward to use for documents, too. I preferred JSON initially myself, since it seemed a little less verbose, I did not care about extensibility, did not consider its usage for documents, validation, did not care about using it for different data models, and it just seemed simple (FSVO) and straightforward. But then more of XML made sense. It is not perfect for everything, either, but the decisions behind it seem more justified to me than those behind JSON (though JSON still fits JS, at least).

bawolff 3y ago

> The XML ecosystem with things like XSLT, Xquery,etc, were elegant, but also overengineered and clunk Hell those were the better XML standards. Just consider SOAP, SAML (XMLSignature is insane), etc XML just another example that unnecessary complexity is the worst sin in software development

77pt77 3y ago
SOAP still has a special place in my heart where only hate exists.

IshKebab 3y ago

I disagree. XML isn't that complex. I think it failed because: * It's overly verbose. All those closing tags, ugh. * The data model is not actually what people want most of the time. People are transferring objects, not documents. The fact that XML doesn't have a proper way to represent maps, and you have the redundancy of attributes, inline text, etc... There's a huge mismatch between the data model of XML and the data model that people usually want. * SAX is obviously a shit way to do parsing. There were DOM parsers and pull parsers but for some reason SAX was stupidly common despite being stupidly awkward.

Marazan 3y ago
SAX parsers are quick and easy which probably explains their prevalence.

yread 3y ago

I still can't believe that we (as a profession) kinda traded away schemas, namespaces, comments, sanity and well defined dates basically because some kids were too cool to write out closing tags. My early 20s teammate now closes blocks with } //for in his JS. That's even worse than XML!

vbezhenar 3y ago
JSON has schemas. Namespaces are simple, just add something like "namespace": "mynamespace" if you really need it. Comments are not really needed for machine readable formats and many JSON parsers allow comments if you need it for configs, so that's hardly an issue. Well defined dates are strings in ISO8601 format. It's not standardized with JSON, but not an issue I encounter on practice.
- flagrant_taco 3y ago
  JSON itself doesn't have support for scheme of comments as far as I'm aware. Both are supported by individual rolls building on top of JSON rather than those features being part of the JSON spec. Whether that stiffener matters to someone is up them, but that difference is what many comments on this thread are pointing out with regards to us having spent a decade rebuild many features of XML back into JSON.
  - vbezhenar 3y ago
    XML does not have support for schemas either. XML Schemas is a separate spec (and actually not the only one, there were few competing ones). I'd use JSON schema over XML schema any day. And I read and wrote many XML schemas and still do sometimes. JSON schema actually built by sane people. If that required a decade, so be it.
    - flagrant_taco 3y ago
      Oh that's interesting, I always thought schema names pacing was a part of the XML spec, learned something new!

vbezhenar 3y ago

IMO XML failed because of mismatch between programming language structures and storage format. JSON is perfect because it maps 1:1 to arrays and objects. XML does not. There were whole ORM projects to map XML to data structures. That's a fundamental issue and replacing XML was not that hard. My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures. Dethroning SQL much harder, though. It'll take decades. We introduced fundamental roadblocks into IT and river of time will either break those roadblocks or smooth them into shapes hardly recognizable (SQL + JSON, for example).

mythhabit 3y ago
SQL is a pretty decent language. Sure it could be improved and made more intuitive and maybe even simpler. Relational data maps directly to objects if you have halfway decent tooling. SQL is almost 50 years old now - it'll be here for a long time because it is actually useful paradigm that has not been outdone by other paradigms (so far).
nordsieck 3y ago
> My prediction is that SQL will fail too. There are infinite attempts to dethrone it. And the reason is the same: tabular data does not map well to our data structures. I'm deeply skeptical. The relational data model is fundamentally about correctly representing relationships between data. Whereas data structures are about efficiently using computer hardware to perform computation on that data. I don't see either going away, because they're driven by fundamental needs.
shadofx 3y ago
To dethrone SQL, you won't cut it with just average techbro hype. You need the top award of SIGMOD renamed in honor of your paradigm's inventor levels of hype.
titzer 3y ago
> My prediction is that SQL will fail too...And the reason is the same: tabular data does not map well to our data structures. The whole point of SQL is that relations and relational data are not data structures. They are higher level concepts and data structures are implementation details. The reason it has survived 4+ decades is because it isn't intrinsically tied to those implementation details and instead can be reimplemented over and over and over. > There are infinite attempts to dethrone it. Viewed another way, there are infinite attempts to reinvent it, all of which keep failing, because they aren't as good.