←back to thread

392 points _kush | 1 comments | | HN request time: 0s | source
Show context
CiaranMcNulty ◴[] No.44394259[source]
It's sad how the bloat of '00s enterprise XML made the tech seem outdated and drove everyone to 'cleaner' JSON, because things like XSLT and XPath were very mature and solved a lot of the problems we still struggle with in other formats.

I'm probably guilty of some of the bad practice: I have fond memories of (ab)using XSLT includes back in the day with PHP stream wrappers to have stuff like `<xsl:include href="mycorp://invoice/1234">`

This may be out-of-date bias but I'm still a little uneasy letting the browser do the locally, just because it used to be a minefield of incompatibility

replies(8): >>44394503 #>>44394794 #>>44395004 #>>44395249 #>>44395303 #>>44396380 #>>44398418 #>>44399777 #
maxloh ◴[] No.44394794[source]
However, XML is actually a worse format to transfer over the internet. It's bloated and consumes more bandwidth.
replies(3): >>44395007 #>>44395081 #>>44396647 #
1. JimDabell ◴[] No.44395081[source]
XML is a great format for what it’s intended for.

XML is a markup language system. You typically have a document, and various parts of it can be marked up with metadata, to an arbitrary degree.

JSON is a data format. You typically have a fixed schema and things are located within it at known positions.

Both of these have use-cases where they are better than the other. For something like a web page, you want a markup language that you progressively render by stepping through the byte stream. For something like a config file, you want a data format where you can look up specific keys.

Generally speaking, if you’re thinking about parsing something by streaming its contents and reacting to what you see, that’s the kind of application where XML fits. But if you’re thinking about parsing something by loading it into memory and looking up keys, then that’s the kind of application where JSON fits.