JSON vs. XML
corecursive.com
JSON vs. XML
1–10 of 252 posts
Re: JSON vs. XML
#2What a pointless debate. I've worked with XML manuscript archives and I can be certain that if I'd had to do it in JSON I'd have killed myself.
Re: JSON vs. XML
#3This 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.
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.”
Anyhow, hope you like the episode!
Re: JSON vs. XML
#4What a pointless debate. I've worked with XML manuscript archives and I can be certain that if I'd had to do it in JSON I'd have killed myself.
This is about JSON being created or discovered and Doug struggling to convince people it was relevant when everyone was so bought in on XML.
Are you saying you think JSON shouldn't exist and everyone should use XML for everything?
Tooling around XML was certainly more established, but man there was a lot of complexity built up around it.
Re: JSON vs. XML
#5This 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, w…
I really respect that you provide transcripts. It's terribly important for accessibility and for getting what people have said into the various search engines.
I was sad to hear that Crockford is not aiming to be the author of "the next language" anymore, but I wonder how sincere that really is. His thoughts on actor-based languages are interesting.
Re: JSON vs. XML
#6Honestly, I would relegate XML to application configuration. Trying to communicate with it with something like HTTP requests/responses is absurd.
Re: JSON vs. XML
#7What a pointless debate. I've worked with XML manuscript archives and I can be certain that if I'd had to do it in JSON I'd have killed myself.
This is about JSON being created or discovered and Doug struggling to convince people it was relevant when everyone was so bought in on XML. Are you saying you think JSON shouldn't exist and everyone should use XML for everything? Tooling around XML was certainly more established, but man there was a lot of complexity built up around it.
The Complexity of XML reminds me of something from Adam Bosworth's ISCOC04 Talk [0]. To me, the big takeaway is that HTML succeeded because of it's limitations, not despite of them. JSON seems very simple compared to XML. XML seems to be very powerful, but also very complex - it's like, if all you need to do is pick your kids up from Soccer Practice, you don't need the powerfullness (complexity) of the Space Shuttle in your vehicle.
In 1996 I was at some of the initial XML meetings.
The participants� anger at HTML for �corrupting�
content with layout was intense. Some of the initial
backers of XML were frustrated SGML folks who wanted
a better cleaner world in which data was pristinely
separated from presentation. In short, they disliked
one of the great success stories of software history,
one that succeeded because of its limitations, not
despite them. I very much doubt that an HTML that had
initially shipped as a clean layered set of content
XML, Layout rules – XSLT, and Formatting- CSS) would
have had anything like the explosive uptake.
Re: JSON vs. XML
#8What a pointless debate. I've worked with XML manuscript archives and I can be certain that if I'd had to do it in JSON I'd have killed myself.
This is about JSON being created or discovered and Doug struggling to convince people it was relevant when everyone was so bought in on XML. Are you saying you think JSON shouldn't exist and everyone should use XML for everything? Tooling around XML was certainly more established, but man there was a lot of complexity built up around it.
No. JSON is great as Javascript's serialization format, but it's not as readable and robust as XML, period.
I use both extensively, and for bigger objects and definitions, XML is a very clear winner.
I'm a big believer in horses for courses type of approach, and my personal gripe is the push to replace one thing with another. These data types can coexist, and can be used where they shine. XML can be read and written stupidly fast, so it's way better as a on disk file format if people gonna touch that file.
YAML and JSON are not the best fit for configuration files. JSON is good as an on-disk serialization format if humans not gonna touch that. XML is the best format for carrying complex and big data around. TOML is the best format for human readable, human editable config files.
Re: JSON vs. XML
#9This 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, w…
I remember a meeting where a consultant from an MCP excitedly told our mutual client that the XP in the upcoming version of Windows stood for 'XML Protocol.'
More innocent times.
Re: JSON vs. XML
#10Honestly, I would relegate XML to application configuration. Trying to communicate with it with something like HTTP requests/responses is absurd.
When you can get the data as XML, verify via its schema externally and then transform it via XSLT, it's not.
Also, it's way better in transferring/storing big, complex intricate data like 3D objects.