On a lark, I made up a new JavaScript notation for representing tabular data: JACODA, or JAvascript COmpact DAta notation.
The idea is that many JSON datasets are really just CSV files, except that the header row/field labels are included with every single record. That just feels inefficient, doesn’t it? Why not just include a header row, like a spreadsheet or CSV file?
Example JSON data:
[
["letter","number","color"],
["alpha","one","red"],
["beta","two","green"],
["gamma","three","blue"]
];Example JACODA data:
[
{"letter":"alpha","number":"one","color":"red"},
{"letter":"beta","number":"two","color":"green"},
{"letter":"gamma","number":"three","color":"blue"}
];It’s debatable which is more human-readable. For a short data set (few columns, few rows), the JACODA data looks easy to read. But once you have more data than what fits on your screen without scrolling, JSON offers a lot of advantages. And, of course, JSON is more flexible in terms of the data it can represent.
It’s difficult to see any great differences with such small sample data, though. I looked for existing data I could use for some tests. I grabbed a JSON file of American films scraped from Wikipedia, found via the awesome-json-datasets repository. There were 36,273 titles.
Some of the data was questionable, but I don’t have the time or inclination to fix the shortcomings of a free dataset:
{
"title": "Boarding School Girls' Pajama Parade",
"year": 1900,
"cast": [],
"genres": [],
"href": null
},I used jq to remove everything but the title and year:
jq movies.json '.[] | {title:.title, year:.year}'I had to do a little fiddling to make it work as a JSON/Javascript include, but the file is approximately 1.8 MB.
I also converted that same file to JACODA. That file was approximately 1.2 MB. The conversion cuts the file size by about one-third. Less than I expected, but that’s because movie titles can be quite long. I’ve seen other JSON data where the size-on-disk of JACODA data would be half the size of JSON.
I ran some local tests, loading into a web browser (using a local web server, and local web browser).
movies.jacoda.js: 318.70 kB transferred (1.24 MB size)movies.json.js: 340.55 kB transferred (1.86 MB size)
The JACODA data is only about 6% smaller than the JSON data, in terms of bytes transferred. That’s because the web server compresses the data before transmission using gzip.
Size-on-disk and bytes transferred (and therefore load times) aren’t the only important benchmarks. The amount of time it takes to render something on a page is also important. I wanted to test the processing/rendering time for putting the data on the screen. I created a page to test this: Testing JACODA versus JSON – rendering speed. It takes the difference of Date.now() before and after rendering the data to compute times. These times could vary, not just due to what else is running on the machine, but also due to the quality (or lack thereof) of my JavaScript. These are rough benchmarks, but I ran them over 100 iterations and found almost no differences:
- JACODA: 109.15 ms (mean)
- JSON: 110.99 ms (mean)
The test data had tens of thousands of rows, but was otherwise short (just two columns). If your dataset is larger (millions of rows, or more columns), those small differences might start to add up. But based on my tests, the only significant advantage to JACODA over JSON is size-on-disk. It’s not completely irrelevant for the size of the data transfer, but not enough that the end user would likely notice or care, and certainly not enough to support an entirely new data notation format.