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

101–110 of 203 posts

Re: JSON Hero: Enhanced JSON structure visualization

#101

Post by simplotek »

pseudonymcoward wrote: post #85
alias_neo wrote: post #66

Earlier quoted context omitted.

Ouch, this is particularly egregious: "...To opt out, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable before you install the .NET SDK"

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 include MAC addresses.

https://dotnet.microsoft.com/en-us/platform/telemetry

> Seems quite reasonable as long as we accept them sending telemetry during install.

There is nothing reasonable about this. You should not be required to have tribal knowledge on how to use arcane tricks prior to running an application just to avoid being spied upon. It's a dark pattern, and one that conveys a motivation to spy upon unsuspecting users whether they approve it or not.

Re: JSON Hero: Enhanced JSON structure visualization

#102

Post by brettermeier »

TeMPOraL wrote: post #81
Thorentis wrote: post #67

> JSON Sucks Does it though? I'm not a huge fan of tools who bash the thing they're trying to help people work with. Maybe "JSON is hard" is a better tag line?

But it isn't. It's dumb, it's annoying, it's overused, but it's not hard .

And you prefer YAML, or which one isn't "dumb, annoying and overused"? I would pick JSON over many such formats. And no tools needed.

Re: JSON Hero: Enhanced JSON structure visualization

#103

Post by brettermeier »

throwaway0x7E6 wrote: post #14
stevage wrote: post #9

I'm not really clear on what the value-add is here. When is one needing to "visualise" JSON in this way, without editing it? Does it really help that much? Generally I just open in VS Code, reformat and use search etc.

to make sense of API responses

Why you need this tool for that? I think I would need longer with it as without, comparing to a nice formatted text in an editor (or maybe even the Firefox developer tools, which also format JSON very well).

Re: JSON Hero: Enhanced JSON structure visualization

#104

Post by simplotek »

mholt wrote: post #42
Mogzol wrote: post #39

Earlier quoted context omitted.

The fact that it needs a server at all seems unnecessary. It's all written in JavaScript, and isn't doing anything that couldn't be done in a browser, I see no reason why this can't be an entirely client-side application.

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.

Re: JSON Hero: Enhanced JSON structure visualization

#105

Post by TeMPOraL »

brettermeier wrote: post #102
TeMPOraL wrote: post #81

Earlier quoted context omitted.

But it isn't. It's dumb, it's annoying, it's overused, but it's not hard .

And you prefer YAML, or which one isn't "dumb, annoying and overused"? I would pick JSON over many such formats. And no tools needed.

I prefer s-expressions, but that's a matter of taste :).

By "dumb", I mean it's simple - almost as simple as it gets. I don't like YAML - it's more complicated than JSON in all the bad ways[0]. By "annoying" I mean the experience of using it in languages other than JavaScript, especially in statically-typed ones. I guess it's true for all such data formats - XML, YAML and s-exps are also going to create the same kind of type-related pain. By "overused" I mean, it's used too often in places where it shouldn't be[1], adding to software inefficiency and bloat at every layer.

But my point is, none of that is actually hard. It's just stupid, annoying drudgework.

----

[0] - Optimizing too much for looking "nice" to humans, by means of removing affordances that make the precise structure obvious. It's particularly apparent when you try to write some, and the document grows beyond screenful of lines in length, and 2-3 levels in depth.

[1] - There are many, many examples of JSON being used where a more streamlined text format, or a binary format, would be a better fit. One that comes to my mind and annoys me to no end, is when people encode large amounts of time series data in JSON, in a format like [{"x" : "123", "y" : "456"}, ...]. The data set becomes easily 10x the size it should be, 20-30x if it's not minified. Sure computers are fast and all, but I've long suspected - and recently seen some articles confirming - that at this point, software is often no longer IO-bound, but CPU-bound, and mostly on parsers.

Re: JSON Hero: Enhanced JSON structure visualization

#106

Post by simplotek »

TeMPOraL wrote: post #77
rob74 wrote: post #62

Earlier quoted context omitted.

"the extension apparently can be configured to use a locally running instance of the server" - well that sounds needlessly complicated, I mean, the code could be implemented directly in the extension (I know, that's probably easier than it sounds if you are trying to maintain both the extension and the online version with the same code base). "you post publicly the json, which may or may not be ideal depending on wha…

> or a much bigger problem (if it's sensitive personal data). Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. In some contexts, it may even be gross misconduct or illegal and potentially exposing your employer to large fines. And, in general, I'd say a tool like this that comes without ex…

> Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. (...)

"Personal data" means the reddest of data. If a system collects and tracks personal information then it will be expected to collect highly sensitive information that is not personal. It makes absolutely no sense at all to try to downplay security problems by coming up with excuses such as "oh it's only leaking personal data".

Re: JSON Hero: Enhanced JSON structure visualization

#107

Post by TeMPOraL »

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

'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.

Re: JSON Hero: Enhanced JSON structure visualization

#108

Post by simplotek »

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.

> 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.

It's my understanding that JSON was not invented. It's just the necessary and sufficient parts of JavaScript to define data structures, and could be parsed/imported in a browser with a call to eval().

People who complain about JSON completely miss the whole point. It's not that it's great or trouble-free, it's that it solved the need to exchange data with a browser without requiring any library or framework.

Re: JSON Hero: Enhanced JSON structure visualization

#109

Post by TeMPOraL »

simplotek wrote: post #106
TeMPOraL wrote: post #77

Earlier quoted context omitted.

> or a much bigger problem (if it's sensitive personal data). Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. In some contexts, it may even be gross misconduct or illegal and potentially exposing your employer to large fines. And, in general, I'd say a tool like this that comes without ex…

> Personal data is a red herring. It's not the only thing that matters. For starters, using this at work with anything not explicitly public is likely a violation of your contract. (...) "Personal data" means the reddest of data. If a system collects and tracks personal information then it will be expected to collect highly sensitive information that is not personal. It makes absolutely no sense at all to try to down…

I mean it the other way: I see the problems routinely downplayed with excuses like "it's not collecting personal data".

See e.g. this, elsewhere in this thread: https://news.ycombinator.com/item?id=33784919. What does the linked Microsoft page say? Quoting:

> The telemetry feature doesn't collect personal data, such as usernames or email addresses. It doesn't scan your code and doesn't extract project-level data, such as name, repository, or author. The data is sent securely to Microsoft servers using Azure Monitor technology, held under restricted access, and published under strict security controls from secure Azure Storage systems.

I.e. "we're not collecting personal data, so you have nothing to worry about". Plus the classic "the data is sent securely to our servers", as if that was supposed to be reassuring. It's one of the most common types of distraction I see: focusing on how the data in-flight won't leak to third parties, and ignoring the fact that it's the first party that shouldn't be getting this data in the first place.

Re: JSON Hero: Enhanced JSON structure visualization

#110

Post by alpaca128 »

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…

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