The rise and rise of JSON (2017)
twobithistory.org
The rise and rise of JSON (2017)
1–10 of 107 posts
Re: The rise and rise of JSON (2017)
#2I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible.
We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break when they aren’t. So in order to make the two techs talk with each other through SOAP, we had to write a custom library to translate the .Net xml before we send it. And that’s just one in a long line of similar stories.
Hell, SOAP calls en general take longer time to get running than any JSON rest service call I’ve ever set up. Even when the XML interprets the same on both ends, though I’m not sure why that is exactly.
So it’s fair to say that I love JSON. The article outlines it as being easier to read, and there is certainly that, but for me it’s the efficiency.
Working with JSON never takes longer than it should.
Re: The rise and rise of JSON (2017)
#3I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…
> Working with JSON never takes longer than it should.
This is the key point right here.
JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything.
I always use json string payloads on HTTP aswell. It vastly simplifies rest service development.
Another thing I love about json is using it with cassandra. So easy to store big maps that hold the state of different things.
Dont even get me started on avro/kafka/etc....
Re: The rise and rise of JSON (2017)
#4I write a lot of smaller service agents, connecting legacy systems or feeding them with data in the public sector of Denmark. Most of those are done with XML and it’s often quite terrible. We write a lot of C# but one of our tools is an old adobe lifecycle server, and .Net XML isn’t the same as Adobe XML. I mean, technically it’s just XML, but the two techs expect your XML elements to be build a certain way and break…
> Working with JSON never takes longer than it should. This is the key point right here. JSON is a big reason I love groovy so much. No matter what json you have in groovy, you are a couple lines of code and a couple closures away from doing anything. I always use json string payloads on HTTP aswell. It vastly simplifies rest service development. Another thing I love about json is using it with cassandra. So easy to…
You would have loved s-expressions in a typical lisp setup, then. :)
And you have also obviously never fallen victim to slightly off spec JSON parsers and folks that took advantage of them. Trailing commas? Definitely useful. Until they break a system. (Oddly, I have been stricken lately by how much people hate the extra parens of lisp, but nobody bats an eye at the pointless commas of every other language...)
Re: The rise and rise of JSON (2017)
#5Of course, JSON has its own share of issues too, largely as a result of it trying to be as simple as possible. Many JSON parsers support nonstandard features such as comments and trailing commas, and in the process, create mutually incompatible "dialects". XML might be verbose and complicated, but I think JSON unfortunately is a bit too far in the other direction.
Re: The rise and rise of JSON (2017)
#6The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away.
Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant to look through. By that point a pretty printer is needed, and you might as well have picked any format that has a pretty printer.
Can you add new fields easily? Yeah, but try changing a field name, or its type, or remove a field. This is guaranteed to break some client or server somewhere eventually. I've seen code that uses at least 5 permutations of "Zipcode", "zipcode", "zip_code", etc. I also wouldn't dare try to change it for fear of accidentally breaking our payments processing system.
JSON trades ease of starting up, for suffering when the code base gets big. It's an incredibly alluring trap, as TFA's graph shows.
Re: The rise and rise of JSON (2017)
#7This article had a footnote linking to a snide Douglas Crockford retort to a blog post that was dismissive of JSON. The other discussion comments on that page are a fascinating history of the arguments for and against, through the lens of 2006.
https://scripting.wordpress.com/2006/12/20/scripting-news-fo...
Re: The rise and rise of JSON (2017)
#8The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away. Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant…
Why are you using wireshark to inspect json payloads?
Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
Re: The rise and rise of JSON (2017)
#9The success of JSON is due to one thing: Browser support. As soon as it's use on a server, or a mobile device, or practically anywhere else almost all the benefits of JSON go away. Can you inspect the payload easily? Well, yeah, if you unwrap the bytes into a string or open up Wireshark. But on any moderately optimized system, the JSON is going to be gzip encoded and whitespace compressed, making in quite unpleasant…
Why are you using wireshark to inspect json payloads? Your other complaints stem from poor system design and lack of shared data contracts. They could be complaints about any data format.
I would argue that the fact that json doesn't have schema support built in makes it more difficult to handle those issues though.
Re: The rise and rise of JSON (2017)
#10JSON is one of the best things to ever come out of the CS disciplines.
It is one of the most perfect technologies I deal with.