Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

JSON is great and all, but we really, really need to agree on a binary format that can support a few more data type including binary and dates.

I get that JSON being text is easy to debug, but text is just a binary format that has viewers built into everything (utf8) if we agreed on a a more structured hierarchal binary format there would be a viewer for it everywhere.

Taking it further a text file should just be one of these fictional hierarchal binary format files with a single string node for the text, maybe with some agreed metadata nodes as well, same with most other file formats.



My current hypothesis is that it really depends on the viewer and other parts of its toolset. A format like this is easily defined (and there are already dozens that would qualify), but right now, text is in many cases a lot more convenient to use.

So to convince more people to use such a format, we'd need viewers and editors that allow you to exploit the structure of the format, that are easy, intuitively and convenient to use and that are readily available on whatever system you're working on.

Text is also more robust than binary formats: Even if your json/yaml/xml/whatever file got corrupted, you can still open it in a text editor, make sense of it and fix it manually if necessary. An equivalent binary format would need to have the same property.


I agree with all you have said, but I stick to my point, text is a just a binary format we have agreed upon to decode individual characters then secondary decoders are built upon that. Since we have agreed on this binary format for characters there is a viewer for this format built into almost everything, hence its convenience.

If we agreed upon a binary format that encodes hierarchal nodes/key/values with various data types (raw binary, strings, numbers, dates) then hopefully there would be a similar viewer everywhere and no need for most secondary decoders (json on top of text).

It should also be faster and more compact if sending binary or numbers or dates.

Properly designed it should still be able to handle corruption, but that just has a lot to with the decoder and how it handles the corruption.




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

Search: