Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pretty JSON Revolution

ohler.com

Post reply on HN
Print view View original

121–130 of 159 posts

Re: The Pretty JSON Revolution

#121

Post by kgilpin »

peterohler wrote: post #23
foobarian wrote: post #15

Earlier quoted context omitted.

jq is a very nice tool for JSON wrangling available to install on most distros. It also provides key sorting, which is great for diff-ing JSON.

jq is a nice tool. oj is similar in many ways but different in others. jq has it's own proprietary query language while oj uses JSON path. The output options are also different with some overlap. Maybe jq will get a pretty output option after reading the article. :-)

I found JSON path to be so, so weak and limiting. Missing powerful axis traversals like xpath has, and also has very confusing semantics (the filter condition also changes the output???).

I hoped to find jq as a gem/module/library but I was disappointed. After days of searching and trying different things, I honestly could not find any powerful library or API for traversing and searching JSON.

Re: The Pretty JSON Revolution

#122

Post by jandrese »

Macha wrote: post #3

If you're on a mac or Linux system, you likely have a JSON formatter already installed `python3 -m json.tool somefile.json` or `cat foo.json | python3 -m json.tool` will print it in "one line per node" format. 3.9 introduces a --sort-keys switch for sorted objects also.

I use json_pp a lot. It's usually installed in the base OS.

json_pp The only thing I don't like is that it doesn't process commandline arguments. You have to pipe the file in. It is also fairly strict, I've run into a number of malformed JSON files that it rejects but other parsers would accept. Naked TRUE/FALSE statements are one thing it hates that are super common, especially from places like Google.

Re: The Pretty JSON Revolution

#123

Post by jandrese »

peterohler wrote: post #46
Macha wrote: post #13

Earlier quoted context omitted.

Pretty printing JSON is mostly for developer consumption, I'm not sure how the pretty printed JSON would end up being fed automatically to another system? (I have actually encountered a order-dependent JSON-subset parser before, but to my mind, that code is broken)

Pretty JSON is still just JSON. It should work with any JSON parser. Of course if it is being fed from one system to another there is no need to make the JSON anything other than compact one line JSON. Pretty is for human consumption.

Some parsers will reject JSON that has whitespace around the elements. Pretty JSON is really only for human consumption.

Re: The Pretty JSON Revolution

#124

Post by stickfigure »

gmfawcett wrote: post #112
stickfigure wrote: post #105

Earlier quoted context omitted.

...and a lot of other tooling assumes the order is relevant. Quite a lot of application logic in the real world, too. Which is why browsers preserve iteration order. JSON is a serialization format. Its components inherently have a serial order. You can't change this any more than you can legislate the value of pi to be 3.

Nitpicking, but JSON was designed as a data-interchange format, it only happens to be used for serialization. I agree that any kind of pipeline component (i.e., not a source, and not a sink) should preserve ordering where possible, for the sake of robustness.

JSON is defined (and has always been) as a serial stream of characters. I think it's fair to call that serialization.

Re: The Pretty JSON Revolution

#125

Post by jng »

mschuetz wrote: post #115
Zecc wrote: post #89

Earlier quoted context omitted.

> The position of commas in the rgb array are triggering me You mean: { "colors": [ { "color": "black" , "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red" , "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow" , "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green" , "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan" , "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue" , "hex": "#00f", "…

You mean: { "colors": [ { "color": "black" , "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red" , "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow" , "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green" , "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan" , "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue" , "hex": "#00f", "rgb": [ 0, 0, 255 ] }, { "color": "magenta", "hex": "#f0f",…

The last extra comma is valid javascript, but, (possibly) unfortunately, invalid JSON.

Re: The Pretty JSON Revolution

#126

Post by jng »

Zecc wrote: post #89
augusto-moura wrote: post #83

Earlier quoted context omitted.

The position of commas in the rgb array are triggering me Numbers to the right make it much more pleasant to my eyes { "colors": [ { "color": "black", "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red", "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow", "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green", "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan", "hex": "#0ff", "rgb": [ 0, 255, 255…

> The position of commas in the rgb array are triggering me You mean: { "colors": [ { "color": "black" , "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red" , "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow" , "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green" , "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan" , "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue" , "hex": "#00f", "…

Exactly. I format things like that in my source code. Anything else is too painful to bear. When code by other people who don't care about those things, it's hard to understand :)

Re: The Pretty JSON Revolution

#127

Post by jng »

Latty wrote: post #67
thechao wrote: post #24

Please: { "colors": [ { "color": "black", "hex": "#000", "rgb": [ 0, 0, 0 ] }, { "color": "red", "hex": "#f00", "rgb": [ 255, 0, 0 ] }, { "color": "yellow", "hex": "#ff0", "rgb": [ 255, 255, 0 ] }, { "color": "green", "hex": "#0f0", "rgb": [ 0, 255, 0 ] }, { "color": "cyan", "hex": "#0ff", "rgb": [ 0, 255, 255 ] }, { "color": "blue", "hex": "#00f", "rgb": [ 0, 0, 255 ] }, { "color": "magenta", "hex": "#f0f", "rgb": […

Personally, aligning columns like that drives me nuts. It's awkward to maintain and makes things harder to actually read most of the time.

How does it make it harder to read? Patterns and repetitions jump out of the page. Indeed, maintaining it takes time and effort, I wish the editor were smart enough, but I only see advantages with regards to reading the code.

Re: The Pretty JSON Revolution

#128

Post by wayneftw »

Macha wrote: post #13
taeric wrote: post #5

Earlier quoted context omitted.

I would be a little nervous sorting the keys. I thought it was not too uncommon for parsers to treat them as an alist where order matters. I guess so long as it is a stable sort, no big deal?

Pretty printing JSON is mostly for developer consumption, I'm not sure how the pretty printed JSON would end up being fed automatically to another system? (I have actually encountered a order-dependent JSON-subset parser before, but to my mind, that code is broken)

Outside of pretty printing - MySQL breaks your app if you depend on key order in an object because it alphabetically sorts object keys when you store it in a JSON column.

JavaScript itself will also sort object keys if they are numeric, so `{a: "a", c: "c", b: "b", "1": 1};` will be transformed to `{1: 1, a: "a", c: "c", b: "b"}`.

Re: The Pretty JSON Revolution

#129

Post by breck »

adwn wrote: post #119
breck wrote: post #84

Relevant plug: if Pretty Notations interest you, then you should keep an eye on Tree Notation https://treenotation.org/ .

a) That's not relevant, b) it's not nearly as new, interesting, or revolutionary as you think it is, and c) please stop spamming links to your website in every second thread here.

https://giphy.com/gifs/smile-clap-laff-3oEjHI8WJv4x6UPDB6

Re: The Pretty JSON Revolution

#130

Post by gmfawcett »

stickfigure wrote: post #124
gmfawcett wrote: post #112

Earlier quoted context omitted.

Nitpicking, but JSON was designed as a data-interchange format, it only happens to be used for serialization. I agree that any kind of pipeline component (i.e., not a source, and not a sink) should preserve ordering where possible, for the sake of robustness.

JSON is defined (and has always been) as a serial stream of characters. I think it's fair to call that serialization.

I'm not disagreeing that JSON is used for data serialization, but your last comment just muddies the waters. There are plenty of things that are serial in nature, but have nothing to do with "serialization" in the sense of data marshalling. I guess that the term is kind of unfortunate.

Consider just how how many data formats are ultimately defined as a "serial stream of characters" -- and then consider how few of those you would practically use for marshalling a general data structure.

Post reply on HN