A message format that requires parser to understand both UTF8 and UTF16, cool!
Unsurprisingly, one of the most common data types is text strings, so most serializations need that anyways.
The rise and rise of JSON (2017)
101–107 of 107 posts
Re: The rise and rise of JSON (2017)
#102The 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…
XML has browser support too.
Re: The rise and rise of JSON (2017)
#103I 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…
You’re comparing SOAP, a message protocol, with JSON, a data format. SOAP is so much more, it specifies how objects are defined, how they should be serialized and delivered to a server (WSDL). Note that JSON doesn’t have anything like this that has seriously taken off. There’s a few attempts, but they aren’t in great use or have tooling support. So as a result everyone working with JSON implements their own de-/seria…
I did specifically say it wasn’t technically the languages fault, but you certainly have a point. I don’t think it’s completely unreasonable to bring in SOAP even though you’re talking about the language, because I’ve almost never worked with XML without also working with SOAP. But in not completely comparing it to JSON either, I mean, I love JSON for the efficiency of transferring it between systems, so I’m not completely comparing XML/SOAP to JSON the language either.
As far as lifecycle goes, it’s not actually the SOAP call but the way the two tech stacks parse the XML that’s the problem. You can also do rest calls with livecycle, and you’ll run into the same problems trying to pass XML created by any of the standard .net libraries to it.
I agree SOAP is terrible, but part of my point is that SOAP taints XML, because it’s a really common way to transfer XML.
I do use XML in other ways of course. We get quite a few datadumps in XML, that I turn to SQL through Microsoft SSIS, and even here it’s annoying. Not so much the language, but the way it breaks your SSIS service if it’s not delivered exactly as specified in its schema. Obviously that shouldn’t happen, but it does. Sometimes a supplier delivers half a file, and everything because SSIS didn’t get the XML specified in the schematic. (The fact that this breaks this is another wonderful story, where multiple datasets gets delivered within the same XML file.)
JSON and XML are languages, as you say, but their main usage (at least for me) is transferring data between systems and techs, and that is almost always easier, simpler and safer with JSON. Maybe it’s unfair to call JSON the better language because of that, but it’s certainly more useful to me.
Re: The rise and rise of JSON (2017)
#104I 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…
> 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.
Something similar happens me with Java. Our product have some legacy ancient code that serialize/deserialize XML to beans using a library (JOX) that works with pure reflection (pre Java annotations).
I try to replace it for something more modern like Jackson or JAXB, but I hit a wall when I found that the XML that reads/writes these library are very different from what Jackson or JAXB expect to find. So, or we translate all XMLs to the new format or I write some translator to transform the old XMLs to something more standard.
Re: The rise and rise of JSON (2017)
#105Earlier quoted context omitted.
Ah, Groovy. All the brevity of Java and all the type safety of JavaScript. I had no idea anyone still used it, let alone loved it!
That's an unfortunate stance on Groovy. Groovy code is often far more brief than Java's, and it has some beautifully expressive capability for making DSLs, both through its world-view on closures and its ability for the developer to walk and modify the AST at compile time (see, for example, the @Canonical attribute for how this can be useful) While I, too, wish it built on a statically typed base, Groovy offers ameni…
I use Groovy with Spock to write unit tests. Wonderful way to write tests.
Re: The rise and rise of JSON (2017)
#106Earlier quoted context omitted.
I have seen more than my fair share of build failures from missing or extra commas. Worse, they have odd behavior in some languages. That said, I cede that they are different. I just don't get the hate of parens.
My frontend builds fail because of trailing commas in the code (by design, so technically a non-issue). At the same time, my editors can balance parens but they can't really do anything but complain about trailing commas. It can't assume it's an issue and "fix" it because I just might not be done writing, yet. My editor can make more and safer assumptions about paren balancing, however, and so it does. I really have…
Yeah, I concur. I mean, instances have a "global stream" where all posts from all users are sent? What's the use for that?
It would be like Facebook or Twitter having a "front page" showing all posts from all their users. I don't want to read what something posted merely because they're subscribed to the same physical server. There should be some classification of affinity by common interests.
Re: The rise and rise of JSON (2017)
#107One aspect about JSON is the lack of comments. This makes it mostly unsuitable as a configuration language and in fact simple "JSON for humans" such as https://hjson.org/ and https://json5.org/ exist. In my opinion, this is a design flaw and if JSON would be a bit more human-oriented, it could be much more widespread in non-web contexts.
I actually like that JSON has no comments. With comments in a data transmission format you will end up with things like "conditional comments" in IE. I agree there are certainly many better configuration languages.
I agree, but you can do context switchs also without having comments. For instance, the JSON Schema defines (Source: https://json-schema.org/latest/json-schema-core.html#rfc.sec...)
{
'$comment': "string that can hold whatever you want"
}