Hacker News new | past | comments | ask | show | jobs | submit login

Why is concatenated json a thing?

In what sense is: {0}{1} better than [{0},{1}]? Presumably, if a few bytes are a major concern, you aren't using JSON anyway.

If you have a file or network stream with millions of separate JSON items, then you might want to parse and process each item separately as it is received, and the surrounding structure just gets in the way. That being said, it's properly better to explicitly acknowledge that you're using something-like-json-but-not-really-json like http://jsonlines.org does instead of simply concatenating json objects.

With the application understanding that the top level object is an array of independently parsable json objects, it should still be possible to stream the format I suggested, assuming you use a streaming / sax parser.

Streaming parsers are very inconvenient to work with.

The delimiters don't get in the way, they protect you from MITM and other attacks. It's a security feature, not a bug.

A non-online/non-streaming parser can parse [0][1] in an online/streaming way by first parsing one text ([0]) then the next ([1]), whereas it has to parse all of [[0],[1]] to produce a result. Similarly on the encoding side.

Concatenated JSON is ambiguous, so you need to put some whitespace between any JSON texts where both aren't arrays or objects.

This is a widely used technique.

As another commenter said: streaming.

To elaborate:

{0}{1} is better than [{0},{1}] because, when streamed, {0} is still valid, while [{0}, is not.

When I was writing something (partly) as a learning exercise the easiest way to handle errors was to have an error handler on the server-side JSON encode any errors. The client-side JS would then split the string it got back on newlines and then parse each part. Each chunk of JSON had a field to say if it were an error message and if so the error would be logged to the browser console. I don't recommend, by any means, that people do this generally.

Streaming is the prime use case.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact