See also jsoncrack [1] which visualises JSON as n-ary tree data-structures.
This project takes a different approach, in that it handles the displaying of JSON node leaf data in a more human way. E.g for hex colours showing a colour picker or a date picker for dates.
What sets this tool apart however is the static analysis of the JSON data, which in doing so can uncover divergences or outliers in the data. E.g a single null value somewhere, or supposedly data which deviates from the majority data-type (i.e a number where every other value is a string).
I think there's value proposition in just edge case detection. Datasets can be massive, with something like JSON there exists no formal type verification. Although to be honest, I don't see a valid reason to use JSON as a backend given graph based databases with type-safe schemas exist.
'pletnes provided some use case classes. JSON is an ubiquitous data interchange format, so document sizes vary with data. I'll chime in with a real example I look at daily: the compilation database of a C++ project I work on, i.e. the compile_commands.json file. This file is fed to a language server (clangd) so it can correctly process the source code, and provide IDE features to text editors. The JSON file itself, as created by CMake, is some 2+ megabytes in size. Once run through `compdb` utility, which adds missing entries for header files, it grows to 25 megabytes.
I'm converting proprietary AutoCAD DWG files to some JSON format (libredwg) I invented.
600K bytes is a very small file, with just a couple of objects.
My Spotify playlists export is a 7.5MB (minified) JSON and I don't even have many of them. Cleaned up of redundant entries and formatted it comes out at over 128K lines.
This project takes a different approach, in that it handles the displaying of JSON node leaf data in a more human way. E.g for hex colours showing a colour picker or a date picker for dates.
What sets this tool apart however is the static analysis of the JSON data, which in doing so can uncover divergences or outliers in the data. E.g a single null value somewhere, or supposedly data which deviates from the majority data-type (i.e a number where every other value is a string).
I think there's value proposition in just edge case detection. Datasets can be massive, with something like JSON there exists no formal type verification. Although to be honest, I don't see a valid reason to use JSON as a backend given graph based databases with type-safe schemas exist.
1: https://news.ycombinator.com/item?id=32626873