It's strictly worse, actually.
ndjson specifies sane newline handling, since it works with terminators.
jsonlines works with separators and thus fails to detect truncated values. As a result, it can silently produce incorrect numeric values.
ndjson specifies sane newline handling, since it works with terminators.
jsonlines works with separators and thus fails to detect truncated values. As a result, it can silently produce incorrect numeric values.
On the other hand, requiring line terminators in the standard would inevitably lead to incompatibility issues. Most software would accept unterminated files, because text libraries do; and so some files will not be terminated. Some applications do not line-terminate files even on Linux (hello VSCode), and it would be even more problematic on Windows
And if you have to parse values to detect end of record anyway, there’s no point in having jsonl standard at all, since you can just try to parse until the matching brace and repeat on success.
i.e. a documemt without a newline at the end is valid jsonl, but invalid ndjson
You can detect and error out if you see an unterminated record at end of transmission. With separators, the producer might not put a separator after the last record, because there's nothing to separate it from there.
There's no justification for not using terminators, it's just a bad spec. Unsurprising story: the variant with better marketing has less technical chops.