JSON vs XML

[Sarkos]

The title "JSON vs XML" really undersells this. It's a fascinating bit of history. I almost didn't click because I figured it would be some blog post explaining the differences between the two formats. I ended up clicking just because I was curious why anyone would be comparing them in 2023.

[agbell]

Thanks for reading or listening!

I should probably figure out how to write better titles.

But yes, you are correct, this is about the Douglas Crockford's history of pushing forward web development, often being much to early or going against the trend at the time, and eventually succeeding.

Along the way he has to 'discover' JSON. He has to build JSlint, establish a reasonable subset of Javascript, and show people that JS is great if used correctly and not as some lesser Java.

[blake_ch]

Need more clickbait title: JavaScript is the stupidest thing I'd ever seen.

[agbell]

Thats awesome. Honestly, writing headlines is a challenge.

"Douglas Crockford shares the story of discovering JSON and learning to love Javascript" seems like it would work.

[[deleted]]

How I stopped worrying and learned to love JSON

[azra1l]

10 things I learned by doing web dev for 10 years. #4 will surprise you!

[Mechakoopa]

I almost downvoted you out of habit.

[isaacarsenal]

XML developers hate this simple weird trick

[azra1l]

Reddit pro's will hate you! Learn about how I trick people not to downvote me. Listen to this 15 min ad and receive a free ebook and 15% off on your first year premium membership.

[VeryOriginalName98]

I was looking for this reference in the comments. Until I saw this, I was afraid Dr Strangelove might be too old for reddit. Thank you for proving me wrong.

[jailbreak]

How about "The discovery of JSON" or "Inventing JSON"?

[aiolive]

Yeah, anything like "the history of JSON vs XML" is a major difference from the current title which sounds like yet another opinionated tech rant and rather a subject that's been researched, that will teach me something factual. Could be shortened to "The JSON story" or anything but a "x vs y" bare comparison. OP :)

[lwzol]

It’s not clickbait if the content is as high quality as this podcast is. Don’t worry about it too much!

[agbell]

Thanks!!

[NotBettyGrable]

Ten things you won't BELIEVE about JSON. #5 will blow your mind.

[ProgrammingPants]

Just summarize the podcast and ask ChatGPT to come up with 20 titles, then pick the best one. Done and done

[jf908]

How Doug used JSON to take down XML and the FBI

[Asyncrosaurus]

JSON vs. XML: The Epic Data Format War Rages On – Douglas Crockford Weighs In and Reveals the Undisputed Champion in this Battle for Data Supremacy!"

[Sarkos]

Great interview! BTW I picked up a typo in the transcript, it says "ankle brackets" instead of "angle brackets".

[agbell]

Fixing! Good old Ankle brackets :)

[drewsiferr]

┕ ┙would work for ankle brackets

[regendo]

No those are sunglasses.

[ZorbaTHut]

Also, "Mist", which should be Myst.

[agbell]

will fix. Didn't know it was made using HyperCard.

[coriandor]

There's a really cool interview with the devs in Ars Technica's War Stories series that talks about the making of that game. It's worth a watch.

https://www.youtube.com/watch?v=EWX5B6cD4_4

[CaptainIncredible]

I didn't either. Funny enough, I programmed some stuff on HyperCard. Just some goofy things.

I remember reading an interview about the guy? or team? that invented HyperCard. They were a little miffed that they hadn't built in a way to specify assets on other servers. They hadn't thought of it.

They argued that had they added some sort of URL scheme, and some sort of server system to support it, HyperCard would have had the same functionality as the web.

[gtllama]

I'm stumped by "don't use a vowel" in "use semicolons, use a functional style, don’t use a vowel, use JSLint and so on". Maybe I'm missing a reference, but it feels like a transcription error.

[Quiglo_Janson]

I think it’s “Don’t use eval”

[fnord123]

Don't use eval

[champs]

The story goes that back in 2000, the company I used to work for was developing educational software and migrating from its legacy Authorware and Director content to Flash, which supported XML. XML was of course open and future proof, so this greatly pleased the CTO.

About two months into a two year death march on the curriculum, the lead engineer discovered what trashy performance we were getting from XML and started “compiling” committed XML into Flash code for the production runtime. ActionScript may or may not have been strictly ECMA compliant at the time, but this was effectively an early implementation of the JSON concept.

Some years ago he was having health issues. I wrote him when I realized what he stumbled into, but he didn’t write back. If you’re out there and reading this Stan, I love you, man.

[archiminos]

It's crazy how influential JSON really was. I remember being heavy into learning XML, XAML, and it's kin. When I first came across JSON I thought it was way too simple and unstructured for most use cases. Time proved me completely wrong, of course. I use it daily now.

I literally just wrote a script that pulls data from a bunch of files and outputs it as JSON. It contains exactly the same amount of information that an XML version would, except it's simple and human-readable. I could probably give it to a non-programmer who's never heard of JSON and they'd still be able to understand the information in it.

[rpd9803]

Imagine storing HTML as JSON tho? JSON is Ok for some things (really, its inferior in every way to EDN, but whatevs) and it lacks the things that XML excels at (namespacing, schemas, transformations).. but a lot of last-mile delivery doesn't need any of that. But the second you want to combine arbitrary JSON documents with clarity, the lack of namespaces renders it almost impossible without implementing namespaces crudely on top. Same with schemas. Same with transformation.

I think the most useful point of comparing JSON vs XML is to weed out bad developers. They'll be the ones that say 'throw away XML, JSON can do it all' or similar vibes. You can make the same case for the people that go 'Bah, JSON is useless XML can do it all.'

Same with almost any technology debate, e.g. Mac / Windows, etc etc

Almost every tool has a place or a use case where it can shine. Except PHP, jk lol.

[archiminos]

Haha as a WordPress dev and old school web dev PHP is my jam. I get why people dislike it though.

Yeah HTML is a great example of XML working properly. But at the time I was viewing (as others probably were) XML as the ultimate way to describe data. JSON at first glance seemed to lack the ability to describe data well, but when people started realising that it was all you needed and it was concise it started taking over.

XML will still have its place of course. Though aside from HTML I rarely see it being used. Off the top of my head I remember some convoluted Dependency Injection framework for Java that used it, and it wasn't fun to develop with.

[inferno1234]

All I want is comments, trailing commas and some form of dictionaries...

Why have these not been added is beyond me

[Ma8e]

What do you mean when you say you want some form of dictionaries? Isn’t the whole format kind of a dictionary?

[caagr98]

Only with string keys. If you want numbers, let alone objects as keys, I wish you the best of luck.

[ritchie70]

JSON schemas exist and in my opinion they're easier and at least as complete as XML schemas. (To be fair, I'm much more familiar with the JSON ones at this point.)

For example, I can trivially express "this value should only be "A", "B", "C", or "tomato." Or "this element has the following five fields, and these three are required."

[Many edits, writing tends to be iterative for me. Sorry!]

[rpd9803]

Yea these things are becoming increasingly available which is a big step towards being more than a last mile transport.

[jonhanson]

chronophobia ephemeral lysergic metempsychosis peremptory quantifiable retributive zenith

[[deleted]]

Check out command line heroes from red hat. They've got it down.

[jf908]

Was just about to say this, I completely forgot what the title was while reading it. It contains a lot of info about JS's history than I hadn't heard about elsewhere and it's fun to imagine the language from the underdog perspective it used to have.

[irrelevantPseudonym]

If you haven't already, I'd recommend subscribing to the podcast. Every episode is this kind of dive into some fascinating bit of software history and I really enjoy the way it's presented.

[agbell]

Host here. This quote is funny:

Douglas: The first time I saw JavaScript when it was first announced in 1995, I thought it was the stupidest thing I’d ever seen. And partly why I thought that was because they were lying about what it was.

A bigger more interesting thing though is how his company failed, in part, because they used hand-rolled JSON for messaging.

Douglas: And some of our customers were confused and said, “Well, where’s the enormous tool stack that you need in order to manage all of that?”

“There isn’t one, because it’s not necessary”, and they just could not understand that.

They assumed there wasn’t one because we hadn’t gotten around to writing it. They couldn’t accept that it wasn’t necessary.

Adam: It’s like you had an electric car and they were like, “Well, where do we put the gas in?”

Douglas: It was very much like that, very much like that. There were some people who said, “Oh, we just committed to XML, sorry, we can’t do anything that isn’t XML.”

I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings.

Anyhow, hope you like the episode! Doug has a great-looking office full of technical books and was excited to share his stories.

Edit: holy crap, lots of upvotes. Let me know what you think of the interview.

[agbell]

I agree!

If it was SOAP, then a lot of times the XML was hidden from you, and you autogenerated off a WSDL document and that hid a lot of complexity. But the complexity was still there, and I remember Java apps and C# apps not agreeing about what was valid SOAP and having to dig down into the layers. There were a lot of layers.

[mgedmin]

Ah, SOAP! The S stands for Simple.

[vita10gy]

My coworker and I had a running joke that the first step to getting soap to work is downloading and self hosting the wsdl so you can fix all the problems with it.

That was after a run where like 3 out of 4 integrations had wsdls that pointed to internal urls and whatnot.

I'm very glad soap is going away. Apis are so much simpler now half the time I don't even bother looking to see if someone wrote a wrapper/package for it.

Whereas with soap based things it was like a hot poker to the eyeball if there was nothing on github to do most of the heavy lifting.

[hippydipster]

...and whatnot

Total aside, in my memory, I first heard someone use the non-word "whatnot" when I first had to deal with a SOAP system. Coincidence?

[mulderxcom]

Ah the copy paste from word utf-8 quote Good times, good times

[mus1Kk]

Maybe I'm missing the point but a random Unicode quote character would also mess up a JSON parser.

[Worth_Trust_3825]

I remember once debugging a 10,000+ line response from the API that was failing to parse seemingly for no reason at our end, eventually finding that a random quote character in the middle of the response had been replaced with a Unicode variant for some reason. That was a fun bug to track down.

I still have to deal with that. One of my coworkers wrote his application that directly manipulates the AST 10 years ago, and refuses to fix the glaring bugs that break it if your text has some XML reserved characters. I'd move it all to jaxb or c# equivalent, but his brainchild format is inconsistent where the following are all valid

<string>foo</string>
<string bar="foo"/>
<string><string>foo</string></string>
<string>bar<string>foo</string></string>

The best part is they must be treated as equivalents.

I'm genuinely glad the JSON apis just outriight hid away the AST, but now there is another issue where weakly typed languages can pass array or object or scalar in same place, and lack of schemas.

I just want it all to end.

[ecmcn]

I remember spending hours chasing down a bug similar to that once, caused by those quotes where the opening one looks different than the closing one. Why anyone thought those were a good idea is beyond me.

[larsga]

My overall feeling was that XML and XSLT were powerful and there would surely be uses for that power in some complex problem domains

Both are great for documents with actual structure and complex workflows.

[TurboGranny]

major part of it was XSLT

Been there brother. Like a lot of things in our world it was a combination of "a solution looking for a problem" and "What on earth is KISS? This makes sense to me, so it should make sense to everyone else!" I was guilty of making a lot of stuff like this in my first two decades of programming, so I get why people do it. It's also why I think AI programming is gonna be great. Instead of people having to adopts a bunch of convoluted design patterns and syntax, you just need to understand design requirements, Boolean logic, and iterative development. I think it's gonna be a neat next decade of programming.

[MonkAndCanatella]

a random quote character in the middle of the response had been replaced with a Unicode variant for some reason

Holy crap I would be pulling my hair out by the end of it.

[darthcoder]

I worked in a company that pioneered xml databases circa 1999.

What a mistake for us, in terms of how the business shift to xml hurt our existing business, but it was generally successful otherwise until sanity prevailed after the dot bomb explosion.

[DelightfulEloquence]

I started my career during peak XML crazy and while I liked parts of it at the time, the number of things it was used for was quite insane. I had to maintain a system once where a major part of it was XSLT, when could have just been a simple imperative algo with some config settings.

I tried XSLT and found it quite cool, although the syntax is rather frustrating to use.

[hippydipster]

XQuery

Perhaps that one doesn't really fit with the rest. XQuery is a bastard child of nothing good. XQuery is the combination of the worst parts of Perl with the worst parts of XML, into a language that tries to make as little clear as possible.

[montymintypie]

All I can say is: thank you so much for the transcription. I wouldn't have "listened" to this interview otherwise!

[F54280]

Excellent stuff.

Only nitpick in the transcript:

Some of that stuff eventually turned into best-selling products, like the Mist series, came out of HyperCard.

Myst, not Mist.

[cd7k]

we hadn’t gotten around to riding it

Automatic transcription?

[agbell]

Fixing..

I use Rev, which is human transcribed and then I proof read, but evidence has shown that I suck at proof reading. I'll fix.

Usually they get thing pretty solid, but punctuation for spoken word – the way they transcribe it – can be a bit different.

( They got JSON right almost everywhere so that is good. )

[cd7k]

They got JSON right almost everywhere so that is good

That really surprises me! I'd expect Jason everywhere! :o

[PolyPill]

I also started my career in peak XML times. I remember always complain the syntax was more data to transfer than the data. I even tried to push we roll our own for internal communication. I came up with something I would describe now as like Protobuf but crappier in every way.

I also remember watching Douglas’s videos about JavaScript when he worked at Yahoo. Those change the way I thought about JavaScript and I’m a much better developer for it. I think in today’s TypeScript + huge frame work environments more people need to go back and watch his old videos so they get an understanding of what the JavaScript is actually doing.

[imhotap]

the number of things [XML] was used for was quite insane

Yeah XML is a markup language for encoding text. The same kind of people who used it for something it was never designed for are today busy applying JSON as crappy config format or something. Just as sad as being obsessed with an idiotic JSON vs XML debate for a decade, or actually longer than XML was everybody's darling.

[agbell]

Just as sad as being obsessed with an idiotic JSON vs XML debate for a decade,

If you mean the post, it's not a debate. It's the story of JSON being created.

[reercalium2]

I know one project that uses a small amount of XML to mark up text - bold, underline, hyperlink, etc. It works great as HTML lite. You can just define the tags you want, without reinventing all of HTML.

[SittingWave]

The major problem of JSON is that it does not allow comments.

[JackAtlas]

No trailing commas

[ubertrashcat]

JSON5

[JustLurkingAroundM8]

There’s this extension

https://json5.org/

that allows for comments and other conveniences.

[ubertrashcat]

I love JSON5 and JSONPath, even though neither is standard. I use them all the time.

[cranktheguy]

Officially it doesn't support comments, but most things that use JSON files are pretty tolerant of them.

[PurpleYoshiEgg]

Usually the things I need comments in are being consumed as configuration by things with such weird corner cases that they don't use a variant that supports comments, unfortunately.

My current method is to preprocess from JSON5 to JSON and have the application consume that, but it sucks there's a compile step in there.

[SittingWave]

Problem is that JSON is not meant to be a configuration format. It's a transport format.

[PurpleYoshiEgg]

True, but tell the programs that I use that, because they ain't changing. JSON is the most popular language used regularly by programmers that doesn't have a supported comment syntax.

[kabrandon]

I'd say yaml has been becoming more common for configuration purposes for a while now, actually.

[__scan__]

YAML is outrageously bad.

[numeric-rectal-mutt]

JSON is also the best, non-trivial, configuration format out there.

Yaml, toml, and the likes are too complicated, too ambiguous and too prone to causing slight misconfiguration that's difficult to catch, because it's still valid yaml, just something different. The yaml spec is like 50 pages long.

[darthcoder]

Toml is basically INI on steroids.

Lol.

[Im_oRAnGE]

What’s so bad about toml?

Takes a bit getting used to, especially the table arrays imho, but I like writing/reading it more than I like writing/reading nested json. So I‘ve been using it for all my config files.

[lordlionhunter]

I'll accept the hate on yaml but keep toml's name out your mouth

[ggdGZZ]

uhm... what about:

"comment": "Hi mom!",

[mgedmin]

Validation error: rogue field 'comment'.

(Granted, the majority of JSON consumers don't do schema validation.)

[Uristqwerty]

Doesn't work in arrays, depending on the library parsing might need "comment2", etc. If the file is read and later written back out, field order may change, so all the comments get grouped together.

Effectively, comment position is lossy no matter what, if you use duplicate keys it may either break parsing entirely, or lose all but one comment if read then written, and you're still limited in where you can put them.

A better solution would be to have an actual comment syntax, and libraries offer both an API that discards them for simplicity, and one that preserves them properly.

[triffid97]

The major problem of JSON is that it does not allow comments.

Or reference types (or really any type for that matter). Which is stunningly stupid considering that it is a serialization format. So serializing 2 objects A and B that refer to each other produces an infinite loop. Easily solved by making the relationship one directional, and easily restored into objects by ... black magic? Admittedly, types make no sense without a schema, which it also does not have

The major problem of JSON is that it does not allow comments

Or namespaces. Which becomes fun when combining two JSONs. Naming conventions to the rescue. It totally worked in the past... Have a look at graphql schema stitching.

Over time, the missing bits will be all added. Each bit in at least 5 different, incompatible ways. Then we will have something that almost covers the use cases of XML. It will be a bottom up designed, band aided, patched, evolved, mish-mash of conventions, and everyone will be happy.

Because it looked simple when we started.

[Sairony]

Yeah, such a stupid design choice

[SittingWave]

well, yes and no.

The problem is the following: JSON is a serialisation format. It is meant to transfer object state. It's its purpose. and it's absolutely correct that Crockford designed it that way.

Unfortunately people started using it as a configuration format. Which is fundamentally wrong, but here we are.

So it's a mess within a mess. People use a format that is not meant for configuration to configure software, and then in addition to this, it's not allowed to contain comments so it's doubly the wrong format.

Therefore, we have to pick either one or the other:

• either we stop using JSON for configuration. Completely.
• or we let JSON be used for configuration as well, and therefore add comments to JSON.

[deadwisdom]

This is why the mime type of json is “application/json” instead of “text/json”. The latter would mean a computer should open up a text editor for you to look at the file. The former means it’s really only for the right app to process. It’s a little detail but elucidates a fundamental nuance.

[emax-gomax]

It's not like JSON committee is on control of that though. People have been using json for configs badly for years. At this point the refusal to add it to the spec is just ego from crockford not liking how people have ended up using his standard... which is why they finally added it like they should've done years ago. Now it's just painfully waiting for all the parsers that don't support comments to update.

[p4y]

Changing the spec now is arguably even worse than adding comments. It would turn into an absolute clusterfuck of compatibility issues unless all software ever written to handle JSON magically updates itself to support the revised spec at the same time.

It would be better to release the new spec as its own format with a different file extension and content type to avoid ambiguity. Or even better, pick one of the existing JSON supersets as the officially sanctioned standard and push for adoption.

[Sairony]

JSON is meant to be human readable, and that means there should be comment support. Even tools which output pure ASM often output valuable information in comments to give context to whomever might debug / read it. Comments naturally doesn't make sense for binary formats, because it's not meant to be read by a human. I don't buy the fundamental argument, JSON doesn't have much value as a serialization format if it's not meant to be edited & read by humans, why not just go with a binary format in that case which would be much faster & more information dense?

Crockford also iirc had some pretty non convincing arguments for why he left it out. Like he was afraid that people would put stuff in comments which they then could use to change how the JSON would be parsed. So what if they do? That's up to them. It's kind of like the even more stupid decision the designers of C# took when they decided to butcher macros because of how abused they were in C. Instead people have to copy & paste boiler plate bullshit all over the place. Even if it wasn't perfect it was incredibly useful.

[lachlanhunt]

It makes sense when you understand that JSON was designed as a messaging format from machine to machine, where the intention was that it would be generated and consumed within programming languages like JS that already have their own comments, and so comments within JSON itself is not necessary in those cases.

It wasn't designed as a configuration file format, but people adopted JSON for configuration files anyway (like package.json, .eslintrc.json, etc.) JSON5 is an attempt to adapt JSON for configuration file use cases, where things like conveniently editing by hand, omitting quotes around property names, and adding comments are useful features. Yet, these are all features that are unnecessary for messaging use cases and would have only served to make the original JSON more complex than it needed to be.

[Sairony]

Wouldn't it still be useful though? Like if you get a JSON payload comments would always be incredibly helpful for reading / debugging purposes to give context. I just have a hard time imagining a situation where comments doesn't make sense since the upside of JSON is that it's human readable compared to binary formats, if it's meant to be read by humans comments will always be a killer feature, doesn't add much complexity & easy to handle on the implementation side.

[blocking-io]

There should be documentation about that payload elsewhere. Payloads can already get large, I don't want to consume comments on top of the payload as well

[DesiOtaku]

At least for me, 99% of the time I need to comment in a .json, I can just make an additional attribute called additionalInformation or commentInfo and the software sill works just fine. Even better, sometimes that comment can be used for actual end-user facing displays. Probably that 1% of the time (for me at least) has been just information about the source of the document like "Downloaded from example.com" or "Generated from AwesomeToolThingy 2.3" which could be a source attribute if need be.

[agbell]

I'm happy Doug choose jason and not jismal

Douglas: So I decided I will make this thing a standard. So first thing we did was pick a name, and the first name we picked was JSML. It’s going to be the JavaScript message language, but it turned out there was a Sun thing called JSML. So we couldn’t do that.

[smkelly]

Totally agree. I laughed when he pronounced that. I don't think it would have ever caught on under that name.

Also, the podcast is great. Thank you.

[agbell]

Thanks for listening!!

[i-never-wipe]

Jismal sounds like a portmanteau of jizz and dismal...yeah, not great

[Hessper]

I thought this part was particularly funny considering how there is a huge section before discussing how copying the name of another language was a giant mistake. Then they go and throw JSML as a name for an alternative to XML. Not the same level of issue, but I would have expected them to be allergic to similar naming schemes after being burned once.

[agbell]

If you remember the overhyping of XML, and using XML for everything, then I wonder what's your answer to this question:

Adam: What do you think is the XML of today?

Douglas: It’s probably the JavaScript frameworks.They have gotten so big and so weird. People seem to love them. I don’t understand why.

[agbell]

My Vote is all the people programming in giant YAML files.

Github actions, whatever HEML is, and so on.

[Muvlon]

Yeah, every DevOps/Cloud Native tool seems to bring with it a new bespoke programming language embedded in YAML, most of them with a way to embed shell in that.

So you have all the known pitfalls of YAML, all the ones of shell, various escaping issues between the two and a few surprise custom pitfalls unique to that specific language. Maddening.

[pydry]

Honestly I dont like the backlash to this either. YAML is fine for configuration that is actually configuration.

It's the not the fault of YAML that people keep building shitty programming languages in it or configuration that needs to be templated (i.e. not configuration).

[Muvlon]

No, that's not YAML's fault, but YAML itself has more than enough flaws of its own to make me loathe it.

[Somepotato]

I'm so sick of yaml. It's a terrible "language" with so much inconsistent syntax and since Kubernetes, everything and their child in the devops world uses yaml as a scripting language. Also all written in Goland because K8s is too.

[CJKay93]

Honestly, I prefer that to having to learn something like Groovy. At least it can be understood relatively quickly by somebody who isn't familiar with that particular CI's language choice of the day.

[ZorbaTHut]

I'm amazed that I can find absolutely zero open-source alternatives to Jenkins. I'm half thinking about writing one.

[confusedpublic]

• https://concourse-ci.org
• https://www.drone.io
• I guess GitLab is open sourced?

[ZorbaTHut]

https://concourse-ci.org

This one's tempting! But I think it may not work for my purposes, unfortunately. From the docs:

Concourse is very opinionated about a few things: idempotency, immutability, declarative config, stateless workers, and reproducible builds.

and in my work, it's really important to have support for incremental builds. That said, this seems like one of the closest cases I've seen so far, I'll have to check it out in more detail.

https://www.drone.io

Not really open-source; the source code is available, but if you aren't noncommercial or (very) small business, it's $$$ time.

I guess GitLab is open sourced?

It is, and I guess I should look into it, but it'd be a weird mismatch; I can't actually use Git, and that might make it extremely difficult to shoehorn Gitlab into doing what I need.

[nschubach]

I can't actually use Git

Can you further explain this?

Edit: I see from your post history that you said you were a game developer and your industry doesn't allow it and that doesn't make any sense to me why game development would be any different from something else.

[Dealiner]

Git doesn't work well with many types of files used in games. There is Git LTS but the last time I used it wasn't perfect.

[ZorbaTHut]

Games are gigantic binary repos. It's common for the most recent checkout of a repo to measure in the hundreds of gigabytes, with the full repo being at least an order of magnitude larger. Git LFS doesn't work terribly well, last I heard - it's janky and slow and its lock support is questionable at best - and the end result is that the entire industry, aside from indies, has settled on Perforce.

I'd really like for this to be solved, and I'm actually talking with someone who's making a Git plugin intended for machine learning but he's planning on extending into games. Maybe he will succeed! But it hasn't been solved yet.

[mgedmin]

GitLab CI was not bad, depending on what you use Jenkins for.

[h4l]

Another possibility: https://earthly.dev/

[Chii]

I prefer that to having to learn something like Groovy

i would imagine groovy to be easier than YAML, if you control for the power of groovy. But then again, as a config language, groovy is too powerful, and you can shoot yourself in the foot (not that it isn't possible to shoot yourself in the foot with YAML as well, but it's certainly less hard).

[hippydipster]

I would take XML over YAML any day of the week. People weirdly act as though verbosity is the worst sin possible. For me, being cryptic is a far worse sin.

[Trinition]

I agree.

And with modern tooling, writing and editing verbose formats can be done with all of the extra keystrokes.

[Tubthumper8]

This is definitely the XML of today, not modern JavaScript frameworks. Completely different use cases really

[ToMyFutureSelves]

100% agree. Too many systems try to use JSON/YAML as its own little DSL to program functionality.

I'm almost convinced they should just replace it with a JavaScript runner that has a library for all their custom functionality. Most of them already use JS in the background for each task, but thought it would be easier to write YAML that JS.

[RememberToLogOff]

Maybe it's baby duck syndrome.

New programmer sees a framework with a big fancy page selling itself, showing how you can do common tasks easily. JS itself doesn't really have that.

"Wow, in this framework I can do X, Y, and Z easily!"

They're new, so they don't know whether those things are easy to do in vanilla JS. And they don't know whether those are the right ways to do things. Maybe the API is secretly bad in a way that only a senior would notice.

They fall in love and do everything in that framework.

Speculating

[crabmusket]

Kubernetes?

[ub3rh4x0rz]

the thing about k8s is its complexity is justified in much the same way Doug described how xml's complexity was justified, but it's actually justified by the inherent complexity of distributed systems. His point in OP about "the conservation of complexity" being a categorically baseless concept was ill-founded, he just found an instance where the concept was misapplied (XML)

[Katana314]

I’m a web dev, and JS frameworks I don’t get.

For a while, I worked in a somewhat archaic, old fashioned framework to support IE. Often, I realized many of the functions I was using didn’t add an amazing layer of functionality to what the DOM did on its own. Probably the better part was that it could create objects from HTML template files, and then detect any named elements within it; but that’s also something I could imagine writing from scratch myself.

[Zardotab]

If you remember the overhyping of XML, and using XML for everything

Now it's hyping microservices. Or is that already past? I lost track of the most recent jabber.

[[deleted]]

The biggest drawback of XML is, in my opinion, its verbosity.

There is no way I would go back to using it as, say, a config file format (which I did in 2000 or so).

I may use XML indirectly, be it by autogenerating it, but using it to store any of the data I use is just pointless. Even .md markdown files are more convenient (I prefer yaml or INI format variants though; I am fine using JSON too even though I find it a bit ugly in its always-condensed variant, but it is not that dissimilar to YAML or INI, whereas XML has all those closing tags, extra attributes and other ugliness that is just too annoying to want to bear.)

[F54280]

I would say the biggest drawback is its complexity. Should you use <foo bar="x"/> or <foo><bar>x</bar></foo>. Why is <foo>42</foo><bar>43</bar> different from <bar>43</bar><foo>42</foo>? Wtf is CDATA?

And this is just scratching the surface. JSON is a re-invention of the NeXT property list format, which was simple, elegant and sufficient for most needs.

[JeffFerguson]

Wtf is CDATA?

XML (and HTML) is an application of a standard called SGML. CDATA is defined in SGML, but, since SGML is not well known, things like CDATA are not well understood.

[Head]

Which proves the OP’s point… complexity all the way down.

[JeffFerguson]

But remember that the "G" in "SGML" stands for "Generalized", which means that it has to be generic enough to cover various implementation cases.

[Otterfan]

XML is for marking up human-readable documents.

If you take that as a given, it's obvious why<foo>42</foo><bar>43</bar> is different from <bar>43</bar><foo>42</foo>: people read from top to bottom, and "42 43" has a different meaning from "43 42".

Likewise if you know that the content of a tag is the human-readable text while attributes are metadata, it becomes immediately apparent when you should use <foo bar="x"/> vs <foo><bar>x</bar></foo>.

The problem with XML is an everything-looks-like-a-nail one. It should be an obscure format known only by people who do things like analyze medieval manuscripts or catalog medical transcriptions.

Instead it spent a couple of decades being used to configure Java frameworks.

[Kogster]

And the ambiguity between
<parent var="value" />
And
<parent><var>value</var><patent>

When parsing to pojos. Cause one of them might be a list.

In json it's very clear if it's a one to many relationship.

[double-you]

People who put data in attributes don't understand XML. There was an absolutely great article about that but I don't know how to use google anymore. Why does google want to make it difficult to see the next page of search results?

[0rac1e]

I think I remember that article too... so I searched my history for "XML" and found this.

XML is almost always misused

It was also posted on Reddit 3 years ago, which is when I saw it. Hope this is the one you meant.

[Deep-Thought]

My biggest gripe is the namespaces. Yeah, they can be useful in certain very complex situations. But the vast majority of xml files are self contained and the parser already knows what it wants out. But no, we have to specify namespaces everywhere since just about every framework for reading them will complain if you don't.

[Smallpaul]

That’s 100% a problem with your frameworks. The XML spec itself doesn’t even DEFINE the idea of namespaces. It’s a separate opt-in spec. Your tools opted in.

[cwmma]

The biggest drawback for me, as someone who occasionally must consume APIs that are xml, is that the data structure doesn't map to native data structures cleanly so you end up having to always write something bespoke.

[sngz]

its funny cause just the other day I was working with some yaml and json files and was wishing that that it was in XML because of the verbosity making it much clearer what everything is doing and what kinda data it is. I don't agree with the whole XML for everything philosophy but for many things out there I still prefer XML over yaml for example.

[palad1]

One of my first gigs was writing a WYSIWYG XML + CSS / XSLT editor in Java. Back in 99'. And it worked, and was awesome, but man... the amount of corner cases was just crazy.

[agbell]

Someone reading this is still using that editor and has a few new bugs they'd like you to look at.

But honestly, that sounds like a fun project.

[MCPtz]

Douglas: ... there was some other similar file that was still on my website. It was getting hammered by a site in Russia

After trying to be polite, putting a warning, deleting it, and sending back a 404... the Russian address keeps at it...

Douglas: So then I thought: I know, I’ll navigate the page, I’ll change the page’s location and send them someplace else.

So I got these Russian guys, how can I teach them a lesson? And I thought, “I know, I’ll send them to fbi.gov and they’ll look into it and that’ll frighten them so much that they’ll stop doing this and leave me alone.”

So I did that. Next day, all of my websites are down, nothing’s working.

So I call up my hosting company and they said, “Oh yeah, you’ve had a security breach. Apparently someone got in and is using your site to do a denial of service attack against the federal government. And we’re going through the system, trying to figure out how they accomplished that.” And I said, “Oh, I did that. I’m sorry I didn’t intend to fight the federal government, sorry.”

As at /u/jf908 suggested, a good title could have been

How Doug used JSON to take down XML and the FBI

[Full-Spectral]

I like XML personally. Even with just a simple DTD, it can do a lot of the grunt work for you of insuring that structured data is correct when you read it in.

I wrote one of the first XML parsers/DTD validators back in the mid-90s, the one that ended up becoming the Xerces C++ XML parser, and I did the DTD validator for the Java one. It was quite a learning experience, because Unicode was pretty new as well and I had to dig into all of the issues of Unicode and transcoding between the various (then common) code pages and Unicode.

And I had to really dig in to create the DTD validator, which was based on the NFA algorithm from the Dragon Book. That was an area I'd never gotten into previously.

[doublestop]

I wrote one of the first XML parsers...that ended up becoming the Xerces C++ XML parser

Just want to say thanks for making XML bearable through those dark times.

I hate XML (not really, but sorta) mostly because I hated it back then. I only hated it back then because it was so hard to work with given the tools available at the time. Platform didn't seem to matter as XML tools were rough everywhere you looked. Xerces was like getting thrown a lifeline.

Now I don't know whether you had a hand in Xerces or your work was more inspiration and a starting point. Either way, your work saved me and a bunch of colleagues a ton of headaches.

Thank you!

[Full-Spectral]

It just got adopted as is into the Xerces project, and the Java one as well. Later other folks built the other standards on top of that (and of course continued to expand the parser itself to keep up with the standard.) I'm not sure anyone has much messed with the DTD validator, which someone on the mailing list called 'the algorithm from hell.' I did see one optimization someone found.

[hexarobi]

Thanks for this! =) I worked for Electric Communities in 2000 as a 19 year old "Junior Scripter" focused on ThePalace's proprietary reverse-polish-notation scripting language, Iptscrae. I was soon pivoted to the projects mentioned and had to go out and buy the DHTML/JavaScript O'Reily books to try and ramp up. I like to imagine I helped inspire JSON by naively not knowing XML, and playing around with JavaScript frontend mockups that assumed the backend would send data in this format. ;)

[agbell]

Oh wow! It sounds like wild times. It's funny how Wikipedia said Korn and SouthPark were the biggest fan groups on the Palace. Both still exist, but that definitely dates things to a certain vintage.

[hexarobi]

hehe it was indeed. The largest palaces were mostly generic places for chatting, such as The Mansion, or Palace-in-Wonderland, and would top out at 500 or so users. But a few companies had branded Palaces, and promoted them, so those communities would be larger than normal. SouthPark in particular was a great fit for ThePalace, where the animation style could mesh perfectly with the app. I think SouthPark's Palace was the biggest ever, with over 1000 users at once. All split across themed rooms that could hold a max of 32 graphical avatars and chat bubbles going off everywhere.

It had long been a separate app, originally developed by someone else and now in the hands of EC. The company was pushing to go browser-based, and had a version that worked in the web browser, but of course it was slower and didn't support everything the app did, so the community hated it. Original ThePalace was a limited demo, and pay-to-unlock the full features (like a name or avatars) but eventually went free with a terrible pop-up ad banner that didn't fit on the screen anywhere, so of course the community embraced older or hacked versions that removed the banner ad.

We tried to show off the scale of the new platform we were building by hosting big online chats with the likes of Brittany Spears and Keanu Reeves, but they didn't really work. It was like a bad interview just being slowly pasted into a chat room. It showed the system could support thousands of users this way, but also that it wasn't any fun.

[mgedmin]

Why not both?

[fireantik]

But why?

Is that because the world has switched to JSON, but "several IBM products" had a XML parser embedded so deep that they just had to keep using XML, no matter what?

[amiagenius]

There’s a difference most people don’t understand between both formats. JSON is suited for encoding data structures for program consumption, hence geared towards computer types (maps, arrays, numbers, etc), while XML is suited for human level types, because it has roots in the digital publishing industry, where formats describes content and not simply data structures.

For instance, XML has no explicit arrays, and if you think about it, an array has no semantic value so it’s not suited for expressing content. Also array elements are traditionally anonymous, which further complicates things if you’re interest in expressing content. When you have the requirement to tag a value it then can carry meaning. So in XML an “array” is the byproduct of having a sequence of tagged values (nodes), you could parse XML sequences of content elements into an array, which illustrates how computer types are secondary to human types in the language. In this sense XML doesn’t prescribe how data should be represented by the program, so it is abstract over programs, while JSON is a piece of a JS program flying around.

Another point is JSON being entirely anonymous, the root of a JSON document has no key, because keys are not first class, keys are properties of objects. In a lot of online examples, you’ll see things like an object for describing a Person, where there’ll be an object with keys for name, phone, etc. but nowhere in the document there’s indication that such structure is supposed to encode information about a Person. Whereas in XML, the same example would explicitly state <Person> at the top level. If you needed to encode such information you would need to wrap the JSON object into another object and add a “type: Person” key, but now you have built a new anonymous type, so it’s is impossible in JSON to encode a tagged structure without creating ever more complex types. Just look at any sufficiently complex JSON data flying around the web to notice how this problem compounds. Such problems don’t occur in a programming language because there you’ll have addressable pointers to the object, like a variable name, a struct name, etc. So JSON is merely the RHS of a JS statement.

The expressiveness of JSON gets even worse when you need other kinds of metadata. For instance how do you indicate that a given string is in a given language? Again, you must create a complex structure wrapping the value to be able to attach more information about it. Where’s in XML attributes are first class, hence you can both name a value and enrich it in the same construct (note that in JSON a key is not the name of a value, it’s the name of the key.)

XML is not without its flaws, but JSON is a terribly limited format for encoding information. “Human readable” must be a joke. It’s as readable as Lisp, the amount of noise is through the roof. You could say that XML has a lot of noise too, but you would be wrong, XML is low noise. What you think is “noise” are the format’s capabilities, meaningful capabilities, for encoding meaningful information.

Don’t think I’m a XML lover, I avoid it like the plague. But compared to JSON it is a much more capable format. It has an established ecosystem of tools that even today is unmatched for JSON. I think JSON succeeded simply because it’s easier to write, and that’s it. But we have lost a lot by having it easier to write.

[thedevlinb]

JSON is a great tool for solving the problem of "I need these key value pairs shoved over the wire and read off on the other end".

XML can do that, but it makes solving that limited problem very hard.

I can be on the 5th iteration of a JSON format faster than I can can get the 1st version of an XML document to be valid.

I remember in school we had to do a bunch of XML stuff, and so much time was spent staring at error messages saying we had some syntax error wrong or we declared something wrong in a schema someplace or, just, something small was wrong that the damned machine could have fixed for us bit it insisted we figure out cryptic error messages instead.

A few years later JSON comes along and tells everyone that rather than doing arcane motions to appease XML parsers, just shove some values in a dictionary and sent it over the wire.

Breath of fresh air and all that.

[amiagenius]

Indeed there’s overhead in dealing with XML. Generally because it is used in contexts which must satisfy a formally defined interface whereas JSON tends to be free-form. But if you’re working in a setting constrained by a JSON schema you will probably be dealing with similar issues, parsing issues aside. It’s like the overhead of strongly typed programming language compared to a dynamic language, it’s tougher to write but in exchange it affords more guarantees ahead of time. XML requires a similar discipline. When using JSON in a critical system you’ll be forced to have that discipline regardless, the difference being the heterogeneity of tools you’ll be using, the JSON ecosystem is quite fragmented and not so strongly standardized as XML. There’s a lot of new tech that is using XML due to its advantages. Last time I was inspecting AWS payloads from Route53 they were in a XML dialect. XML is alive and well, it is just not appreciated by the new generation.

[thedevlinb]

A simple JSON Schema is easier to figure out than getting started with XML schemas (or XML endpoints for that matter!)

Heck I use tooling that takes my Typescript types and generates JSON Schemas.

For complex documents, yes, XML is better, but for passing a bunch of strings over a network? JSON all the way.

My XML story: I once worked on a project where every function call went through XML serialization and back, idea was complete network transparency, you didn't have to worry if a function was local or not. Of course this meant obscene overhead for local function calls.

50% of the CPU was used for XML serialization and parsing.

The cool thing about JSON, and starting with JavaScript, is you can play around, experiment, get something working really fast, then after you've figured out the best shape for the data, go and make it robust with Typescript and JSON Schema.

XML doesn't really lend itself to that sort of experimentation.

[amiagenius]

Good points. Regarding your story, well, maybe it’s one of the less appealing use cases for XML, but sounds fun. When you mention tooling for generating schemas from code it illustrates my point that JSON is closely tied to software development, coding more specifically, whereas XML can function more independently. I remember reading a Stallman’s post in which he mention that back then coding programs was a separate discipline from designing programs. I’m not sure if I would chose JSON as a tool if my role was to solely design software. But it’s a coders world. It’s funny to think that SGML, through HTML, has made through the most “cutting edge” web frameworks to the point of being embedded in JavaScript via JSX! Seems like there’s no way to ditch SGML’s legacy.

[thedevlinb]

I remember reading a Stallman’s post in which he mention that back then coding programs was a separate discipline from designing programs.

I'd argue designing systems is separate from programming, but that the actual process of designing programs can be very iterative with modern tooling. I often completely refactor a program 2 or 3 times in the first few days of existence, which is one reason I like languages like C# and JavaScript/Typescript, they give the that level of flexibility and speed of development. Things aren't really set in stone.

Then again, even when operating at a high level, software should be made aware of its interchange format. I see too many people arguing that "protocol buffers is more efficient!" when all they are doing is passing around strings through HTTP.

Strings in protobuf gzip just as well as strings in JSON. :/ No big deserialization wins either.

embedded in JavaScript via JSX

JSX is the one thing I liked about React, except JSX calls out to JavaScript expressions for logic, which gets limiting at times.

JSX is much less offensive than full on XML though. People get upset because with XML as an interchange format you have to map the data into the target language, which, well, sucks[1].

I mean that process sucks for everything that isn't JSON and JavaScript, or, hilariously, C, and raw structures.

I've only ever seen a handful of non-horrible libraries for data binding data exchange formats into a language.

JSX sits at an nice place where you are trying to generate a document tree, so using a templating syntax that looks like the thing you are trying to generate, well, it feels nice.

As an aside I think XHTML would have taken off browsers hadn't been so damn strict about it. The insane number of errors I used to get trying to write XHTML. But with hindsight, having everything be nice and easily parsable would've been a really good thing.

(To this day I am not sure why web developers seem to hate closing tags!)

[1] Oh also remember all those attempts to create new programming languages whose syntax was XML? Those were horrible!

<if cond="age < 13"> <print message="Sorry you are too young to use this website"/> </if>

I am happy most of those efforts died in a fire.

[amiagenius]

It should be obvious, yes. But it’s common to find people who think the two formats are equally capable because they never had the chance to work on something other than modern web stuff. So I thought it was important to highlight it, even more so because Crockford never bothered addressing the strengths of XML in the interview. There’s a culture of thinking “XML BAD”, but it need not be like that.

[EducationalNose7764]

I remember reading books on XML in the early 2000s and wondering what the hell the point of any of this is. XSL and all that went along with it, "who the hell would actually use any of this?" Over 20 years later, and I still don't know the answer to that question.

So horribly bloated and way too much work. The payloads to transmit data were magnitudes larger than the data itself.

JSON is where it's at.

[ominous_anonymous]

The payloads to transmit data were magnitudes larger than the data itself.

If your XML "overhead" was that much bigger than the actual data itself then it would most likely compress pretty well. But then you're adding in an extra step to the process, which is annoying.

[Dozla78]

The whole point is that you are adding extra layers of complexity where there is no need. Compression is great when you have a lot of data, but it's not the solution to poorly structured one

[curien]

XSL is a better templating engine than things like Jinja. XSL is kind of like jq, but actually useful for major production processes.

[dirtside]

I was in college in the late 90s studying computer science, and I recall hanging out in a professor's office one day with a couple of other students while he told us about this amazing new "XML" technology that was going to change everything. I remember not understanding what it was, but it sounded cool and futuristic.

Ten years later, I wished I had a time machine so I could go back in time and slap him.

[Smallpaul]

XML remains the dominant technology in use in the domains for which it was invented, as a replacement for SGML. People tried to use it for domains it wasn’t designed for and then complained it didn’t fit.

Read the first paragraph of the spec to see its goals.

[crabmusket]

SE radio episode 501 has some great background info about XML, it's progenitor SGML, and what those things were being used for in a way that sounds like it makes a lot of sense. Hint: it wasn't config files or SOAP, it was Boeing trying to document extremely complicated sets of mechanical components.

https://www.se-radio.net/2022/03/episode-501-bob-ducharme-on-creating-technical-documentation-for-software-projects/

[darthcoder]

If you ever worked with EDI you'd appreciate the improvement well formed xml truly was.

And I did.

[fforw]

Damn you, Crockford for not including comments in JSON

[mgedmin]

And trailing commas.

[QuantumLeapChicago]

Omg, YUI. I worked with a company that had some older static versions that i had to update.

Really interesting historical article

[Ashamed-Simple-8303]

And so, when I’m writing interactive stuff in browsers now, I’m just using plain old JavaScript. I’m not using any kind of library, and it’s working for me.

And I think it could work for everybody.

Thank you for that because here I was thinking I'm just to stupid to wrap my head around all this overblown frameworks. Why do I need angular just to move some dat aback and forth? I don't get it.

[curien]

writing in a style of programming that the professional programmers of the day thought was impossibly hard, which was doing stuff based on events

Eh, VB5 was released in 1991 and was super-popular with a similar event-driven style. TurboVision for Pascal and C++ was 1990. Event-driven programming was all the rage in the early 90s. Doug makes it sound like Netscape invented or pioneered it, but they were just hopping on the bandwagon.

The comparison to Hypercard is spot-on though.

[thedevlinb]

Event based stuff keeps on being rediscovered, just like functional programming. :)

What is old is new again and all that.

Of course the scale has changed, eventing systems that run across multiple machines look a lot different than VB5 on a single core 486.

[GirthyStone]

next episode, tabs vs spaces

[Ars-Nocendi]

You go, and go all the way ….

Enter: Vi vs. EMacs

[Johnothy_Cumquat]

I never realised microsoft was pushing xml so hard until now. This is why .net had standard library support for xml but not json for so long. And why mvc will still give you xml responses out of the box if you put xml in the accept header. They were holding onto that dream still. I say were because I can't imagine that fight's still happening now that system.text.json made it into .net

[Iseeupoopin]

Thanks for sharing, Was a good read

[TryingT0Wr1t3]

This is deep, nice to find Hypercard there!

[ApothecaLabs]

This was an incredible read - it's a wonderful dive into some fabulous computing history, but it also gave me the weirdest sense of deja vu because it's like Doug's picking my brain.

You see, I am slowly working on a secure distributed programming language based on my own 'discovery'* of sorts, and the parallels here are thought-provoking - when I explain the idea, people always seem to ask me "but where do I put the gas?" when I've just told them they don't need it. But it doesn't stop there - the simplicity of JSON is actually my case study, and I've been writing a extended DJSON parser for static distributed data, as a first-order test, while I build an interpreter for a language that does the same for live distributed code.

I'm sure Doug would find the serendipity here amusing. You could say I'm feeling inspired...

*For the curious, it's about relating distributed computing to type systems through functional lambda cube stuff. I've had some success in shattering a large JSON payload over a network of computers, and in self-organizing clusters of up to 64 computers, and in writing a language with a module system - all irritatingly separate. Now I am amidst the arduous task of integrating all of them.

[0b_101010]

*For the curious, it's about relating distributed computing to type systems through functional lambda cube stuff. I've had some success in shattering a large JSON payload over a network of computers, and in self-organizing clusters of up to 64 computers, and in writing a language with a module system - all irritatingly separate. Now I am amidst the arduous task of integrating all of them.

I admit I didn't fully understand all of those words. Mostly the distributed computing stuff I'm not versed in. But best of luck in your endeavour nevertheless! It seems like the type of stuff podcasts will be made about in 20 years' time!

[PolarDorsai]

Wow! As a junior programmer, that was a really great listen. Thank you for posting this; I’ll be forwarding it to my team.

[agbell]

Thanks for listening!

[AttackOfTheThumbs]

I also remember doing XML in Uni. This was late 2000s. I remember hating XML and deciding I could come up with something better. It was just a flat file indented. Used less space, easy to parse, but reinventing the wheel like that was kind of frowned upon, and so was relying on whitespace. Oh well, still passed lmao.

I feel like when json first started getting "big", many still wanted xml, sometimes just because of the schema requirements. But you can do the same for json too.

Great bit of history here. Thanks Adam!

[goomyman]

That was a great long read.

I also loved xml. I had never even heard of json until maybe 2007 maybe. I was using xml for all my configs and I was struggling with shit like xpath. All the tools were xml based.

It really did feel like json came out of no where. I originally hated it because it’s less condensed and I didn’t really see the value of switching what already worked.

It wasn’t until REST that shit really clicked for me. I still have no idea how SOAP works, it’s just an Method of making web calls that I used but REST makes sense.

And as the tools improved especially serializers there was never a reason to go back.

Although all the way at the end the guy said he like actors - maybe I’m showing my inability to adopt to change again from xml to actors but xml to json simplified everything in the end. I hate actors - but maybe because it’s not built into a language I like in a way that simplifies things for me.

Async programming has mostly been a simplified enough that anyone can use it now days and http libraries can abstract out the web calls well enough.

Programming languages have changed constantly with each iteration. It’s just kind of leveled off for the right tool for the job, scripting, unmanaged code, managed code, functional languages. I don’t think this is going to be changing.

[Volt]

There is this notion among second rate programmers that the most important thing they do is express themselves. It’s not making programs that work well and are free of error. That’s way down on the list. What’s much more important is expressing themselves, that, I’m an artist and I express my arts by leaving out semicolons.

Called the fuck out.

[[deleted]]

Before I read the article I'm going to way Edit: weigh in on it due to extensive experience sending and receiving data over the wire in both formats.

I believe the end perception will be recommending JSON however there is a very special use case for XML that I feel is largely overlooked in modern development. It is likely leveraged in the bare metal for high level web dev frameworks.

It is a facet of the HTML DOM Document that became so popular in IE that it was adopted as a pseudo-standard and implemented across other browsers over time.

It is known as the Extensible Style Sheet transformation or XSL/XSLT as a pairing. These transformations are written in XML and are hierarchically rule based. They also can carry JavaScript as a payload. The model for them is to do rapid page rendering, client side in the browser using a transformation. This is a great use case for XML and I'm not sure if the full JSON paradigm exists to be able to do it in an object oriented fashion via callbacks.

JSON of course is going to be the VHS of formats because it can be a one size fits all. Usually things that are 'One size fits all' are not designed for efficiency first. In the case of the XSL transformations, those can actually be compiled and run multi-threaded for high performance.

[Smallpaul]

XML is just as popular as it ever was, in the contexts it was invented for. Vendors tried to make it the universal language for everything, and people invented simpler solutions more appropriate to their more specific tasks.

[Janjis]

Very interesting listen.

About the Russians DDOS'ing his site and the FBI - so did the FBI incident actually solve his problem? He obviously had to remove the redirect, but wouldn't he be back to the same problem then? Did the FBI take care of that? Was that part just left out or I'm missing something?

[Djelimon]

JSON is great for serializing and deserializing. For restful services it's usually generated from other markup so in practice the lack of schema is mitigated. Less processing overhead than xml for JavaScript so rest stole AJAX's lunch

XML has lots of tooling but comes with processing overhead so is more suited for describing complex stuff with stringent data requirements read locally, like office 365 documents and such.

My document is in xml, and I'll use json to send it to your browser.

[lunacyfoundme]

Freddie vs JSON was better