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

121–130 of 203 posts

Re: JSON Hero: Enhanced JSON structure visualization

#121

Post by jspash »

naan_bread wrote: post #76
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…

I agree. My tool flatterer: https://lite.flatterer.dev/ converts deeply nested JSON to csv/xlsx, is done in web assembly in the browser. It hard to prove that it is not sending data to a server, so it can be trusted. I know people could check dev tools but that is error prone and some users may not be able to do it. I wish there was an easy way to prove this to users as it would make online tools like this much more…

Turn off wifi? Unplug the ethernet cable? Try it from my garden shed where there never seems to be connectivity no matter what I try.

Re: JSON Hero: Enhanced JSON structure visualization

#123

Post by hutzlibu »

simplotek wrote: post #104
mholt wrote: post #42

Earlier quoted context omitted.

Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. * I'm not justifying doing it on the server, especially for an application like this where yes: it can be done in the client.* But I do sympathize because I know from experience why it's easier to do it server-side, without any conspiracies. I wrote Papa Parse[0] about 10 years ago, and back then at least, it was extre…

> Processing multi-GB files in the browser is... fun. Doing that kind of thing on a server is easier. This sounds like a strawman. Not everyone wrangles multi-GB files, let alone JSON documents. Those who do are already readily aware of the implications. I mean,some popular text editors even struggle with multi-GB of plain text files. You don't need a server to handle JSON. There is no excuse.

"You don't need a server to handle JSON. There is no excuse."

No technical excuse, but lots of buisness reasons I guess.

Re: JSON Hero: Enhanced JSON structure visualization

#124

Post by informalo »

alpaca128 wrote: post #110
naan_bread wrote: post #76

Earlier quoted context omitted.

I agree. My tool flatterer: https://lite.flatterer.dev/ converts deeply nested JSON to csv/xlsx, is done in web assembly in the browser. It hard to prove that it is not sending data to a server, so it can be trusted. I know people could check dev tools but that is error prone and some users may not be able to do it. I wish there was an easy way to prove this to users as it would make online tools like this much more…

Would be nice to have the option to switch tabs into offline mode, just like we can mute them.

You can do that with Chrome dev tools: Network -> No throttling -> Offline

Don't know how reliable this is though or whether a web developer could work around this.

Re: JSON Hero: Enhanced JSON structure visualization

#126

Post by sleepyfran »

simplotek wrote: post #101
pseudonymcoward wrote: post #85

Earlier quoted context omitted.

That's only for the telemetry that happens during the install process (if I've read the link correctly). Seems quite reasonable as long as we accept them sending telemetry during install. ("A single telemetry entry is also sent by the .NET SDK installer when a successful installation happens") For telemetry during actual use, you can set that flag any time, and a message is shown on first use to inform you about it.…

> That's only for the telemetry that happens during the install process (if I've read the link correctly). Wrong. That's for the dotnet cli tool to phone home each and every time you run a command. https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr... Microsoft even provides a page which showcases summaries of some of the metrics they collect from you if you don't disable this feature. These metrics even in…

But they do mention that you can disable it at anytime, only that for the telemetry that is sent with the installer you have to set the flag beforehand (obviously):

> The .NET SDK telemetry feature is enabled by default. To opt out of the telemetry feature, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 or true.

> A single telemetry entry is also sent by the .NET SDK installer when a successful installation happens. To opt out, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable before you install the .NET SDK.

Re: JSON Hero: Enhanced JSON structure visualization

#127

Post by paco3346 »

eallam wrote: post #49
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.

Yea I really wanted to write "JSON is worse is better" because JSON is great and simple. We really just mean "reading complicated JSON files sucks"

So why not say that? When I see a tool or service make a claim as simple as "JSON SUCKS" it makes me think I'm not the target audience.

I can read a 10 like file without a parser. What I don't like is 7 layers deep, nested, 890 lines long.

Re: JSON Hero: Enhanced JSON structure visualization

#128

Post by Existenceblinks »

user3939382 wrote: post #27

I need a JSON schema editor for macOS. I found this: https://www.json-buddy.com/ but it's Windows only and has what I call a "millions of tiny buttons" UI. JSON schema is awesome but it's really tedious to write by hand, even if the basic is auto-generated. It can also get really complex and thumbs up or down doesn't cut it for developer experience. I want something where I can debug/step through the validation.

I think nobody writes JSON Schema by hand .. I see most of them use their lang libs to generate it. What language are you using?

Re: JSON Hero: Enhanced JSON structure visualization

#129

Post by IshKebab »

KronisLV wrote: post #58
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…

It's not the worst ever (that would be YAML) but it does have an accumulation of annoying features.

* Elements and attributes (as you said).

* Text children mixed up with elements. These two are both good for writing documents by hand (i.e. HTML) but really annoying to process.

* Namespaces are frankly confusing. I understand them now but I didn't for years - why is the namespace a URL but there's nothing actually at that URL? 99% of the time you don't even need namespaces.

* The tooling around XML is pretty good but it's all very over-engineered just like XML.

* The syntax is overly complicated and verbose. Repeated tag names everywhere. Several different kinds of quoting.

* XML schema is nice but it would be good if there was at least some support for basic types in the document. The lack of bool attributes is annoying, and there's no standard way to create a map.

JSON is better by almost every metric. It is missing namespaces but I can't think of a single time I've needed that in JSON. Mixing up elements from different schemas in the same place is arguably a terrible idea anyway.

The only bad things about JSON are the lack of comments and trailing commas (which are both fixed by JSON5) and its general inefficiency.

The inefficiency can be sometimes solved by using a binary JSON style format e.g. CBOR or Protobuf. With very large documents I've found it better to use SQLite.

Re: JSON Hero: Enhanced JSON structure visualization

#130

Post by supernes »

vincnetas wrote: post #57
rurban wrote: post #46

Earlier quoted context omitted.

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 :)

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.
Post reply on HN