Do you hate XML? (2010)

Join the discussion

• Hacker News
• XML is ok, the problem IMO is that the way some people use(d) it is utterly unhinged.

  So a return value that could have easily been two lined of text is now a nested demon of XML. The complexity isn't what that application does, the complexity is in how it returns the values.

  Another good one is to use XML when something else would have made things simpler, e.g. for a config file where you could easily have used a .ini or a .toml file.

  Or you have an application that tries to so generic that the definition for a simple use case is a whopping 5MB XML file. Cool. When I feel writing a config for your application is harder than programming the whole thing yourself you have really made it. /s

  by atoav
• Every time XML comes up, I feel obligated to share my opinion (I too wrote XML a the turn of the millennium and have seen it become and still witness on occasion it being excommunicated).

  XML is verbose and therefore uglier than it ought to be. I think most of the haters hate it for that alone -- there's not much else to hate because you don't have to deal with the rest, it's not really imposed on you unless you really have to deal with someone else's XML application.

  What do I mean? Well, the brackets thing and the necessity to repeat name of every element twice, in correct (LIFO, last in first out) order, isn't great, admittedly.

  What XML has that the dev-bro alternatives that have flooded the void XML left since, haven't gotten and thus see being reinvented, are: namespaces, attributes and interop using the former two. Sure you can write JSON and YAML (the latter deservingly being incredibly hard to parse correctly -- they tried to design a better XML but failed IMO) -- but these suck as meta-languages because there's not much "meta" there. JSON, for example, allows you create properties and has a few types (kind of more than XML, really) but it leaves semantics up to you and namespaces are up to you to re-invent, poorly. If you think I am stretching the argument, see if you can represent an HTML document (no, not Markdown) with a JSON file.

  YAML is a similar story, albeit with a few cool things like aliases. I think it's a better attempt to give the world a better XML, but the jury is still out on that one.

  The killer thing with XML, for better and for worse, was plethora of tools to work with it. I wrote a fair share of XSLT documents to transform data, back when there was momentum in XHTML, for example. XSLT barely supports JSON and it's not pretty. XPath cannot natively understand YAML -- unless you convert it to XML which I guess re-animates XML as some sort of Frankenstein's monster. And even if it were a [pretty] monster, dealing with intermediate representation for the kind of purpose, is a can of worms all of its own.

  Ironically nobody seems to hate HTML 5, seemingly. Or React basically turned it into a greasy cogwheel nobody needs to look at. Because if you look at it, it's in my opinion an abomination even compared to XML (unpopular opinion) -- the parser is quirky and behaviour is defined by the standard per element type (i.e. some elements need a closing tag and some do not, and what happens if you forget a closing tag is element-specific; care to remember the set of rules to ensure your document renders to your liking?). It has no namespaces but it has "custom elements" which require a dash in the name as poor' man's namespaces and you can't omit one, and now we have a Web of `x-spinner` and `x-carousel` because it turns out everyone rightfully wanted default namespace but didn't get one. Anyway, it's all plumbing, right -- the idea of _writing_ HTML has largely come and gone us by. And I am digressing.

  by hackrmn
• > Well, the brackets thing and the necessity to repeat name of every element twice,

  As a document format, it's supposed to be hand-written by humans. If you have paragraphs between the opening tag and closing tag, it makes sense to let the reader know what they're seeing the closing of.

  After deciding you do want to repeat the element name, the angle brackets make more sense. Otherwise, you can have a syntax like LaTeX's.

  by jolmg
• What do you think of CSTML? It's my attempt to heal the rift between XML and HTML5, as well as solving all the problems that made XML feel onerous to use... https://docs.bablr.org/guides/cstml

  It's simple to parse like JSON, it has namespaces like XML (but better), and it doesn't require you to repeat the name of every element twice.

  by conartist6
• I don't like HTML5 and to this day I don't understand what was actually gained by dropping XHTML.
  by int_19h
• The one good feature of HTML 5 was the introduction of boolean attributes. It's a feature XML could and should adopt.

  The whole handling of custom elements was fumbled beyond belief. The HTML spec is a disaster particularly it's parsing rules the complexity of which is used as excuse by HTML spec authors not to improve the language.

  XHTML was a better path.

  I think the reason we don't see too many people complaining about HTML 5 is because not many web programmers use it directly, most are using JSX.

  by notnullorvoid
• I don't hate it but I definitely don't like it.

  I write a lot of html already I don't need xml too in my life.

  by hoppp
• i dont hate it, the declaration kind of annoys me from time to time digging into attributes can be annoying its obviously not the best form of structured data.

  json is just easier for my brain at this point if it needs to go over http, but ive seen some pretty... poorly designed json structures.

  csv is always a good time. love when i can just plop important data into a table and query away

  by trueno
• Aside I love how about me is just another tag and clicking lists 3 blog posts.

  On XML I don't hate. I hate wrapping my head around XSLT but that is more about my head. AI may make XSLTing more bearable as it happens? I did work with someone passionate about XSLT. Aaaand now I am doxxed.

  I also thing in practice schemaless i.e. JSON or "the schema is look at the code or some logs lol" won because fuck let's face it that is more fun.

  by hahahaa
• It will be back like vinyl.
  by jjgreen
• XML should've been banned in the Geneva Convention.
  by frollogaston
• > developers must become domain experts [my emphasis] in a rich and complex space that is essentially unrelated to the application itself.

  XML is a markup language, but most people that used it just needed a standard structured data format. In comes JSON which is more easily compatible with the object systems of various languages and in particular is compatible with Javascript syntax, and XML loses most of the people that used it.

  As a markup language though, it seems pretty good. It's just that the amount of people that actually need an extensible markup language is much smaller.

  I do hate the strictness of it. The header

    <?xml version="1.0" encoding="UTF-8"?>
  

  should be unnecessary. For a markup language, an already-made plain-text document should already count as XML. The tags should be something you can just sprinkle as you'd like to add contextual metadata.
  by jolmg
• Honestly I miss it. As overengineered as it was, at least we had proper tooling for it, and while there were dialects in the associated tech (e.g. XML Schema vs RELAX NG vs Schematron) it was minor compared to the wild west that JSON is to this day.
  by int_19h
• Not at all, actually it is much better than JSON or YAML, which its advocates eventually had to come up with all the tooling that XML already had in place.

  Schemas, comments, transformation tooling, IDE integration,....

  by pjmlp
• JSON is okay most of the time, but I loath YAML.

  How many Kubernetes administration headaches trace back to the need for automated systems to surgically edit YAML? It’s absurd and YAML may be the worst choice for this use case.

  by Shakahs
• XML is just so much hassle to parse securely, and it is extremely difficult to get right.
  by pelcg
• Last year we chose XML as the basis for our document language.

  It's been a good choice for designing a new language, but we've been really surprised by the poor quality of the available parsers. We figured it would be a solved problem, but we'll be writing our own at some point.

  by davidpapermill
• Libxml2 segv when the input is large and the transform complicated was something of a surprise to me. Parsing xml is easy enough but I think implementing xslt is going to be a nuisance.
  by JonChesterfield
• I completely agree that it is the best choice for a document language.

  To the point that I have to ask: what other alternatives are there?

  by zvr
• I dislike it because it failed in such a fundamental way as a way to represent a document; you cannot, in general, reliably determine what characters the bytes in an XML file represent - the best a general XML processor can do is guess.
  by derriz
• By default XML is either UTF-8 or 16, any other encoding has to be identified either through metadata or an explicit declaration in the document itself.

  If you are guessing it is because someone failed to properly store or transmit the document.

  by josefx
• I’ve hated XML since 2004. The worst part about it is the tags vs attributes fights. They both do the same thing and the only difference is preference. Having two ways of doing the same thing invite and incite religious positions and cause unnecessary fighting. There should be one, opinionated way of doing things so you avoid confusion.
  by reenorap
• yeah it's not a good design to have tags have two sets of children: a Set of key-value children and then a List of tree object children.
  by rf15
• > The worst part about it is the tags vs attributes fights. They both do the same thing and the only difference is preference.

  They're not the same thing. If you look at it as the extensible markup language for documents that it is, "tags" (i.e. inner content) would be visible and "attributes" would not. If your XML document was processed by an application to convert to another type of document (PDF, etc.), and it didn't recognize a particular tag, it would be sensible for attributes to disappear, but inner content ("tags") to remain.

  It's only seems like a preference thing if you look at XML as a structured data format like JSON is.

  by jolmg
• XML is unfairly maligned. Yes, people bought into it too much 26 years ago, but then you would too if you had to maintain someone else's massive packed struct dumped into a file and documented in a poorly-maintained word document --- or worse, a brace of dumb IETF RFCs that contradict eachother.

  I am glad that younger generations are looking at it with fresh eyes. XML is a useful format; it has its place in your toolbox. Ignore the haters.

  by mickeyp
• Younger gen here, I hate XML, and I'm probably the only one who understands it among those I work with, since at some point I was a team's expert on XMPP. I understood the whole purpose of XML deeply at some point and still wanted to remove it with bleach. Did eventually get to replace it with JSON.

  Anyone else encountering something that uses XML, they'll sort it into the realm of boomer stuff that you sic Claude on and not care about how it works, like Haskell or Angular.

  by frollogaston
• XML wasn’t the best alternative then either. S-expressions have been around since the 50s and are better than either XML or JSON.
  by hajile
• At least XML is hated for the wrong reasons (e.g. verbosity, esthetics) most of the time. There was for sure an era where it was overused (see Apache Cocoon from 2006 https://en.wikipedia.org/wiki/Apache_Cocoon). But XML is still a pretty good format to exchange (and store) data and make sure the data conforms to a certain schema. JSON Schema in comparison is not nearly as powerful.
  by cryptos
• 1. What, in your view, are the right reasons to hate XML?

  2. To me, verbosity and aesthetics seem like perfectly valid reasons to hate XML. Once you learn S expressions, XML looks disgusting. They implemented half of Common Lisp in a markup language.

  by AnimalMuppet
• My reasons to hate XML:

  - element vs attribute ambiguity

  - model of the document does not fit nicely to programming model of structs, dicts and arrays

  - too many complexities (entities, cdata, parser directives)

  - cardinality unknown without schema (is that a single value, or an array that just happens to have one element)

  - order of elements may or may not be significant depending on schema

  - not really extensible if the original schema does not explicitly allow for extensibility

  - some types of valid XML documents are not representable by a schema (e.g. any number of different elements in any order)

  - verbosity

  - namespace identifiers being URIs that may or may not be resolvable

  What I want for general data exchange is JSON with comments and sane namespaces.

  Edit: line wraps

  by janci