Hacker News Reader

Comment by joshlk | Hacker News Reader

Side question: when did XML start to loose favour to JSON? Did this happen because of something in particular or was it a gradual transition?

View on HN

JSON can be translated into a structure of arrays, maps and primitive types. It can be traversed with functional programming.

That matches 100% the skillset/mindset of developpers.

Whereas XML has too many quirks and tricks, that it requires a dedicated API [aka DOM API] that you must learn and master.

XPath is the tool of choice for XML traversal. VERY versatile and super readable, but it cannot beat the ultimate flexibility of the functional programming.

JSON is basically a subset of JavaScript. Parsing XML sucks, everyone rolled their own RSS and it was basically a nightmare having to deal with invalid XML. JSON has always been really strict and simple. If JavaScript in a browser couldn't parse it it just didn't work. libxml was also a nightmare, XSLT pages looked terrible and honestly there where just a lot of bad XML ideas out there despite gems like SVG. SOAP was horrible, and still is for people having to interface with a SOAP API like Netsuite.

But what was really the end of XML was the end of XHMTL and the HTML5 working group that said they weren't going to do XML HTML and it was funded by Google's large sums of money and involved talented people work at a hot new browser called Firefox and the web dev community went their way and everyone followed.

Funnily I use Javascript in Chrome to deal with XML data. And the support of X[HT]ML is still top-notch.

I don't know exactly when, but I think it had a lot to do with the fact that in 2004, Python, Ruby, and yes JavaScript were all fairly niche.

(This might be hard to believe for some, but it's true. GMail had just come out, and it was one of the first web APPS in JavaScript, certainly the first really good one. Paul Graham wrote "the Python paradox" https://paulgraham.com/pypar.html , and Ruby on Rails didn't exist yet.)

JSON maps well to core data structures of Python, Ruby, and (obviously) JavaScript, but XML doesn't.

XML seemed to be associated with Java. There was a lot more ceremony around the APIs. You didn't just manipulate data; you had to create classes and call methods.

So basically neither JSON nor XML are really convenient in Java. But JSON is very convenient in the dynamic languages. You don't need extra abstractions / layers / code generators -- it's just "there".

I could be wrong, but I recall that during the early AJAX days, there was a bit of a XML v JSON war that ended up with JSON winning. Some stated cases for JSON was that it was less verbose and therefore cheaper to send over the wire, among other stated advantages.

I'm sure there were plenty of other sources of fatigue like XHTML Schemas etc...

We’d all been burned on enterprisey balls of mud like XMLRPC and then SOAP. When JSON-over-HTTP came along, it was a breath of fresh air. Look, it’s readable! It’s easy to parse! It’s trivial to generate! It only had like 5% of XML’s features, but that was the point. Mere humans could read it and there was no temptation to stick something in an attribute instead of a value.

Seriously, it was revelatory.

Edit: Also, lots of common computer interactions — I’d go so far as to say most of them — are only passing around a few values in a simple data structure. JSON’s good for that. I wouldn’t want to necessarily use JSON to represent an office document, but that’s not what I want to use it for. “Hey API server, give me information about song 1234.” “OK, that’s ’Hotel California’ by The Eagles.” You can definitely describe both question and answer with XML, complete with schemas and all, but does that get you anything over {“name”:”Hotel California”,…}? Not really.

Consider how much you can accomplish with POSIX, and it doesn’t even have named arguments. There are times when XML’s complexity is a benefit (I guess; I’ve never seen one but I don’t doubt they exist). Most of the time, it’s just overhead for the sake of overhead.

I think the reason that JSON won was that at least on the client-side, it was much easier to turn the response data into a Javascript object to interact with then XML.

You may enjoy this podcast episode, which tells the story of the inventor of JSON: https://corecursive.com/json-vs-xml-douglas-crockford/

+1 to this podcast, it sheds a ton of light on exactly how we ended up with JSON taking the wheel. Listened to it on a flight from Stockholm back to Helsinki and arrived a marginally better programmer as a result of it.

When I was writing an xbrl-to-json library I suddenly realized that they are not perfectly transferable.

XML comes from spreadsheets, and so it was the first mover. Whereas json came from key-value pairs. I think key-value pairs are much easier to picture in your mind, and for the vast majority of work people are doing, it's just simpler.

I think XML is wildly complicated for simply APIs.

XML comes from spreadsheets?

<narrator>It doesn’t.</narrator>

<utterance sc:utterance-speaker="narrator"> It doesn't. </utterance>

Pedantic remark: HTML 4.0 is an SGML profile, but HTML 5 isn’t anymore.

I'm sorry, I meant XBRL: https://en.wikipedia.org/wiki/XBRL

My experience is a bit different. I use Chameleon+xmldict to generate dozen of different JSON formats, my input being a XML template plus Chameleon templating instructions. And I have found that JSON can be 100% percent expressed from XML.

JSON -> XBRL, but not all XBRL -> JSON

I had nightmare debugging sessions with Xml and xslt. Xml is big and ugly. Json was so much lighter and easier and so it won.

several things helped to damage XML as the format of choice.

1. mismanagement by w3c of associated standards:

The awful bloated XML Schema spec that can't even validate many types of common XML design patterns, obviously as shown by Schematron it would be better if they had leveraged XPath in making the validation format they pushed on everyone and made people think wow, XML is this big complicated bloated beast, we need something else.

The awful bloated SOAP spec which Don Box once said if only XML schema had existed we wouldn't have had to make SOAP - let me tell you that was the best darn laugh I had in that year! Which of course with the whole Rest movement - very loosely based on a member of the W3C's PhD dissertation - and W3C committed to SOAP that everyone resented it made everyone resent the W3C and XML in turn.

The tying of second versions of successful standards in to the questionable XML Schema spec made members of communities using these successful technologies - XSL-T, XPath - feel that maybe they weren't enjoying the new versions of the tech so much, there was some drop-off and complaints.

The creation of XHTML as an XML dialect did not suit very many people.

2. Continued increase of the Web as platform of choice.

The successful XML technologies were not well suited to making web sites that were not document based. If your site was say a thin navigation structure to allow you to get around a bunch of documents a top level programming language to handle serving documents, transforming documents to XHTML with XSLT, and then a thin layer of JavaScript on top was quite a decent solution.

But XSLT is not really suitable to making all sorts of sites with lots of different data sources being pulled in to build a frontend. So when you have a lot of languages in use what do you do? You drop the language that is least suited to most of your tasks and use some of the other languages to take care of the dropped functionality, thus easing cognitive load.

I'm serious about this, I was very good with XSLT and associated technologies and built many high quality document based websites for large organization, but the XML stack of technologies is sub-par for building most modern websites that often contain multiple app-like functionalities on every page.

I suppose that the programmers and technologists at the W3C did not realize this because they did not build websites, they were more Enterprise applications, data pipelines and many coming from the publishing world.

3. JSON was being pushed by Douglas Crockford. As the E programming language was shutting down https://www.crockford.com/ec/etut.html he started to focus more of his time on JavaScript and arguing for JSON which essentially he identified as existing as a potential data interchange format. As REST started to take away from SOAP and JSON got pushed by someone who did understand web programming the increasing web focused software development environment moved away from SOAP and XML which were seen as being essentially the same to REST and JSON (or really REST-like and JSON-like) because these were seen as being simpler and quicker to iterate with - which is essentially correct.

On the Web, especially web frontend simple wins because frontend development is in many ways more complicated than other forms of development - why so? Because a frontend developer potentially has to handle very many more types of complexity than are generally handled in other programming disciplines - this often leads Frontend developers to cut corners that other disciplines wouldn't so as to cut cognitive load but here I'm definitely getting off the subject - at any rate for the expanding web market XML and its related technologies were a bundle of complexity that could be replaced with a simpler stack, even if it meant that some of the things that stack was good at might be made slightly harder it seemed and probably nearly always was still a significant win.

Reply on news.ycombinator.com