The rise and rise of JSON (2017) • Hacker News Board

Re: The rise and rise of JSON (2017)

#11

Post by joesb » Fri, Aug 24, 2018, 6:57 AM UTC

denormalfloat wrote: post #6

The 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…

Changing fieldName is not easy in any data format.

Schema has nothing to do with it. If your schema change, you are still going to to break existing client somewhere. It's not like schema can magically tell which field is renamed.

Schema also doesn't help different permutation of how a field is spelled. Because, in web world, nobody is going to use your schema. So you just end up with 5 schemas, each with different way to write "zipCode".

And if everyone can agree to use your schema, then they can agree to write "zipCode" the same way.

Re: The rise and rise of JSON (2017)

#12

Post by humbleMouse » Fri, Aug 24, 2018, 6:57 AM UTC

foota wrote: post #9

humbleMouse wrote: post #8

Earlier quoted context omitted.

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.

Avro json schemas and jackson json annotation for POJOS makes json object schemas easy to implement. Versioned object repos make great shared schemas and are easier to manage than xsds. (imo)

Re: The rise and rise of JSON (2017)

#13

Post by blauditore » Fri, Aug 24, 2018, 6:58 AM UTC

It's funny how people often compare JSON and XML, but don't mention one huge difference: XML is "more powerful" because it supports attributes on nodes, while JSON doesn't. So if you want to encode data structure with metadata on nodes (like objects with a type), you'll have to introduce a non-standard workaround.

Of course that's often not an issue, but I've run into it in the past. :)

Re: The rise and rise of JSON (2017)

#14

Post by pingec » Fri, Aug 24, 2018, 6:59 AM UTC

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME.

I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be such a pain to maintain, would be nice to have a tool that could translate xml schema to json schema and back.

Re: The rise and rise of JSON (2017)

#15

Post by ToFab123 » Fri, Aug 24, 2018, 7:03 AM UTC

So, when do we get a typescript for JSON? You mean a schema like XML has?

It looks like typesafe programming languages are on the rise, yet, when it comes to the format used for data exchange we go from typesafe to unstructured. I find that odd.

Re: The rise and rise of JSON (2017)

#16

Post by hguhghuff » Fri, Aug 24, 2018, 7:04 AM UTC

It’s a great thing that JSON adequate.

It’s a great pity that JSON isn't much better.

It would be great if JSON had comments, more thorough typing and determinism so that data structures could be compared. Apart from that it’s streets ahead of XML.

Re: The rise and rise of JSON (2017)

#17

Post by bouke » Fri, Aug 24, 2018, 7:05 AM UTC

sidstling wrote: post #2

I 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-/serializer, resulting in all sorts of errors.

SOAP on the other hand takes care of this and even has a formalized date type and various number types.

Your complaint is about two vendors creating incompatible inplementations/extensions. I’ve run into this as well and causes a lot of issues with compliant implementations that cannot work together. I think this has been a big reason why eventually SOAP will die.

Re: The rise and rise of JSON (2017)

#18

Post by lwansbrough » Fri, Aug 24, 2018, 7:07 AM UTC

pingec wrote: post #14

I use XSD a lot for XML validation in .net world and better intellisense when writing XML by hand. I was exploring the json world but I could not find a json schema technology that would be as expressive and the tooling around it is much inferior IME. I feel like the technology around schemas (json, xml or anything else) is underrated and not developed enough. And if I wanted to support both json and xml it would be…

I’ll pass on any serialization format that is itself vulnerable to RCE.

Re: The rise and rise of JSON (2017)

#19

Post by function_seven » Fri, Aug 24, 2018, 7:08 AM UTC

saagarjha wrote: post #5

Of 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.

If a JSON parser ignores the JSON spec, is it the spec that went too far in the other direction? Or is that parser just badly-written? (Or misguidedly lenient?)

You could say the same for an XML parser that allows a naked '&' between tags, or continues parsing a document that omits a closing tag somewhere.

Your complaint is probably still valid, but I'd say it's better directed at the culture than the specs.

Re: The rise and rise of JSON (2017)

#20

Post by joatmon-snoo » Fri, Aug 24, 2018, 7:13 AM UTC

Schwolop wrote: post #7

This 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...

Whoa, thanks for linking that. It's really interesting seeing all this talk about sandbox escapes.

This is a particularly interesting quote:

> One huge practical advantage to JSON over XML in the web browser is that you can load JavaScript from any site, while you’re restricted in which sites you can load XML from. I have no idea why browsers insist on limiting where you can load non-executable XML from, when they don’t bother to limit where you can load executable JavaScript from, but there you go: that’s how it is, and there’s nothing anybody can do about it. JSON nicely works around that limitation, instead of holding its breath and waiting until the world comes around to being fair. Surely you can appreciate that practical advantage.