Hacker News Reader

Comment by cheald | Hacker News Reader

"Packed structs, the fat-free alternative to S-Expressions".

JSON's a nearly-perfect balance between human-readability, ease of generation/parsing, and data size. I'm not going to say that it can't get better, but I feel pretty okay saying that I don't feel a burning need to replace it.

View on HN

JSON can be more compact if it simply used collapsible spaces to delimit elements within an array and key-value pairs within a dictionary. For example:

    [1,[2,3],4,{"a":5,"b":6}] // 25 characters

can be rewritten as:

    [1[2 3]4{"a":5 "b":6}]    // 22 characters

Also, currently, JSON requires all string literals to be quoted. If we relax that constraint and only quote string literals that contain escape characters, we can achieve even more space savings. The above example can be rewritten as:

    [1[2 3]4{a:5 b:6}]        // 18 characters

And, in my opinion, the formatted version (with uncollapsed spaces) is just as readable as the original JSON expression:

    [1 [2 3] 4 {a:5 b:6}]     // 21 characters

I guess maintaining compatibility with JavaScript is more important than minor space optimizations. Also, if you really care about such things, you shouldn't use JSON in the first place (see Protocol Buffers etc.)

I not advocating for changing the JSON spec. I'm saying, as a human-readable data format, it could be more compact. Perhaps this observation can be useful to those who are designing a new language.

If this format is intended to be primarily human-readable, why should compactness be so crucial? Looking at your example, I personally think that commas increase readability by visually separating individual elements (at the expense of space they take).

This HN post is a discussion about data expressions leaner than JSON. I believe the points I've made contributes to it and I've never said such compactness is more preferable. It's merely an observation.

Another issue is serializing binaries. Sometime you just have to pass a binary through. I wish there was a rational way to do that with JSON without having to through base64.

For small one-off test cases like these, this looks like a major improvement (28%) but in practice, the network overhead will dwarf the transmission time for 25 bytes and so a reduction to 18 bytes will be neglible. Hell, the HTTP headers alone will be much larger.

If the data set is fairly large, then the markup will contribute much less to the overall size, so the improvement will probably be more like 5-10%. After HTTP compression, the difference might be negligible.

Testing should definitely be done to see if the space saving is worth the additional parsing overhead (relaxing constraints makes the language more complicated).

Same applies to the original post, especially since the examples seem even more contrived. E.g., the author goes from <p></p> in (X)HTML to delimit a paragraph to {"format":"Paragraph","content":[]} in JSON, when one could just as easily contrive <format type="paragraph"></format> in XML versus {"p":[]} to make JSON look better.

These are all the sorts of optimisations that are only really relevant for saving bytes over the wire. Since JSON is usually used over HTTP anyway Gzip/deflate will get 90% of the reduction anyway.

And MongoDB's BSON does reasonably well at serialising data in a binary format when the receiver doesn't have prior knowledge of the structure.

Reply on news.ycombinator.com