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

JSON Hero: Enhanced JSON structure visualization

jsonhero.io

Post reply on HN
Print view View original

51–60 of 203 posts

Re: JSON Hero: Enhanced JSON structure visualization

#51

Post by maxbond »

bufferoverflow wrote: post #41
maxbond wrote: post #26

Earlier quoted context omitted.

Curious why YAML doesn't work for you?

JSON is natively supported by many languages. I don't know of any language that supports YAML without a 3rd party library.

Hmm, for sure, personally I find it a very small price to pay for everything YAML offers, but I understand this is a matter of taste and judgement where reasonable people disagree, and that there are problem spaces/organizations where adopting dependencies is difficult/has a lot of red tape.

Is it merely about the ecosystem? I'm curious if something about the language isn't meeting people's needs.

Re: JSON Hero: Enhanced JSON structure visualization

#52

Post by eallam »

bsimpson wrote: post #17

Hahaha - I get this when opening it in an HN browser on my phone: TypeError: Cannot read properties of null (reading 'getItem') at u (https://jsonhero.io/build/_shared/chunk-LYGVB3WT.js:1:161) at https://jsonhero.io/build/_shared/chunk-LYGVB3WT.js:1:407 at Gf (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:9:6560) at L.unstable_runWithPriority (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:1:4026) at rn (h…

We definitely need to get better with our error messages! Thanks for the report, we'll look into it! What phone OS are you on?

Re: JSON Hero: Enhanced JSON structure visualization

#53

Post by eru »

998244353 wrote: post #45
irrational wrote: post #43

The first thing I see when I go to the site: JSON SUCKS Uh... It does? I remember when XML was the main data interchange format of the web. That sucked. JSON is amazing, terrific, wonderful, etc. in comparison.

It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON.

We had S-Expressions before we had JSON. (And JavaScript originally wanted to be a Lisp, too.)

It's not that we had XML and SGML and XDR because nobody had invented something as simple as JSON, yet. The real reasons are some complicated social hodgepodge that made those complicated beasts more accepted than the already-invented simpler approaches.

Re: JSON Hero: Enhanced JSON structure visualization

#54

Post by s3000 »

998244353 wrote: post #45
irrational wrote: post #43

The first thing I see when I go to the site: JSON SUCKS Uh... It does? I remember when XML was the main data interchange format of the web. That sucked. JSON is amazing, terrific, wonderful, etc. in comparison.

It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON.

Why does React use JSX when it could be all JavaScript and JSON?

My guess is that XML is good for situations where text and data is mixed.

Re: JSON Hero: Enhanced JSON structure visualization

#55

Post by mvindahl »

Tried it out on some REST response from a local test server.

And, well, as much as I applaud the effort, I also think that I'll stick to my text editor for browsing JSON data and to jq for extracting data from it.

My text editor because it's easy to perfom free text search and to fold sections, and that's all that I need to get an overview.

Jq because it's such a brilliantly sharp knife for carving out the exact data that out want. Say I had to iterate a JSON array of company departments, each with a nested array of employees, and collect everyone's email. A navigational tool doesn't help a whole lot but it's a jq one liner. Jq scales to large data structures in a way that no navigational tool would ever do.

Also, there is the security issue of pasting potentially sensitive data into a website.

Re: JSON Hero: Enhanced JSON structure visualization

#56

Post by [deleted] »

einichi wrote: post #31

My number one requirement for a tool like this is that the JSON content never leaves the machine it's on. I can only imagine the kind of personal information or proprietary internal data that has been unwittingly transmitted due to tools like this. If my objective was to gain the secrets of various worldwide entities, one of the first things I would do is set up seemingly innocent Pastebins, JSON checkers, online fil…

[deleted]

Re: JSON Hero: Enhanced JSON structure visualization

#57

Post by vincnetas »

rurban wrote: post #46
tfsh wrote: post #6

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 singl…

jsoncrack cannot even open the simpliest of my json files (600K: too large), whilst this handled it easily.

what is the use case for having 600K (lines? bytes?) JSON? I'm a bit shocked and curious at the same time :)

Re: JSON Hero: Enhanced JSON structure visualization

#58

Post by KronisLV »

irrational wrote: post #43

The first thing I see when I go to the site: JSON SUCKS Uh... It does? I remember when XML was the main data interchange format of the web. That sucked. JSON is amazing, terrific, wonderful, etc. in comparison.

> I remember when XML was the main data interchange format of the web. That sucked.

I wonder why - apart from the "Should this be an element or an attribute?" issues and oddities in various implementations, XML doesn't seem like the worst thing ever.

Actually, in a web development context, I'd argue that WSDL that was used with SOAP was superior to how most people worked with REST (and how some do), since it's taken OpenAPI years to catch up and codegen is still not quite as widespread, despite notable progress: https://openapi-generator.tech/

What does leave a sour taste, however, is the fact that configuration turned into XML hell (not in a web context, but for apps locally) much like we have YAML hell nowadays, as well as people being able to focus on codegen absolved them of the need to pay lots of attention towards how intuitive their data structures are.

That said, JSON also seems okay and it being simpler is a good thing. Though personally JSON5 feels like it addresses a few things that some might find missing: https://json5.org/ (despite it being a non-starter for many, due to limited popularity/support)

Re: JSON Hero: Enhanced JSON structure visualization

#59

Post by alias_neo »

einichi wrote: post #31

My number one requirement for a tool like this is that the JSON content never leaves the machine it's on. I can only imagine the kind of personal information or proprietary internal data that has been unwittingly transmitted due to tools like this. If my objective was to gain the secrets of various worldwide entities, one of the first things I would do is set up seemingly innocent Pastebins, JSON checkers, online fil…

Personal requirements aside (I have the same requirements); just using this would constitute misconduct at the very least at my place of work.

Yes it's a cool looking tool, but there are certslain requirements that ignorance doesn't exempt us from.

My pet gripe is all of the seemingly local (open source) tools that phone home with opt-out metrics, not mentioned in the "getting started" and take some obscure flag to disable and it's just that little bit more complex to do when running the defacto (containerised) build.

Re: JSON Hero: Enhanced JSON structure visualization

#60

Post by kaoD »

s3000 wrote: post #54
998244353 wrote: post #45

Earlier quoted context omitted.

It's always strange to think that we went through formats like XML (and even earlier, XDR) before inventing something as seemingly simple and obvious as JSON.

Why does React use JSX when it could be all JavaScript and JSON? My guess is that XML is good for situations where text and data is mixed.

Named closing tags are good when manually writing stuff because it reduces the opportunity for errors.
Post reply on HN