Live data from Hacker News

JSON Hero: Enhanced JSON structure visualization

jsonhero.io

171–180 of 203 posts

Re: JSON Hero: Enhanced JSON structure visualization

#171

Earlier quoted context omitted.

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

For me, it is because I can do JSON.parse() and boom, it is plain JavaScript objects, arrays, strings, etc. XML was never that simple.

That's actually a good observation, and one I hadn't previously considered

The trade-off of "that simple" is now every JSON tool has to reinvent XML-RPC, XPath, XML Schema, etc. In that way, JSON may be following the path of every other JS thing: arg, this framework is too heavy, I'm going to write a lighter one! ... ok, just with this one other feature .. ok, and this one ... arg, this framework is too heavy!

Re: JSON Hero: Enhanced JSON structure visualization

#172

JSON is actually a really good format, I disagree with their premise "JSON sucks". Like, sure it's got some use cases it doesn't handle well, but overall there's a reason it won.

The lack of ability to concretely define data structures is a huge pain, both when using it and when writing libraries to process it. You can throw JsonSchema at it, but now you have two problems. Can't use comments to try to work around that deficiency, even just to communicate intent to someone looking at an example record, at least not in vanilla json. Record streaming—basically necessary at anything resembling "scale", if you don't want to kill performance—is a non-standard afterthought in most of the ecosystem.

It wastes my time and tends, in practice, to cause bugs, all for no good reason.

I'd say "sucks" is accurate. Not that it's the only bad format we've come up with lately (YAML, ugh).

Re: JSON Hero: Enhanced JSON structure visualization

#175
post #54

Earlier quoted context omitted.

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.

> My guess is that XML is good for situations where text and data is mixed. I don't agree. My take is that HTML/XML-like syntaxes benefit from familiarity from front-end developers, and a DSL to express document/component trees ends up simplifying the job of expressing document/component trees.

"a DSL"... like HTML? Or do you have one in mind you feel is better.

Re: JSON Hero: Enhanced JSON structure visualization

#176
post #60

Earlier quoted context omitted.

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

What advantage does that have compared to simple bracket highlighting and indentation? Editors can easily highlight mismatched parentheses, they are however rarely smart enough to auto-close XML tag pairs. I just see it as unnecessary clutter. Meanwhile the only issue I have with JSON is the lack of support for trailing commas.

Named closing tags are another confirmation when inserting stuff at the end. I think multiple different confirmations can be easier to recognize than a single one.

Re: JSON Hero: Enhanced JSON structure visualization

#177
post #155

Earlier quoted context omitted.

It not being opt-in is the problem

If it's not opt-in, the software's spyware, pure and simple, and ought to be lumped in with other malware that should be rejected, shamed, and marginalized until/unless that behavior changes. I'm sticking to our much-better norms for this shit from c. 2000, damnit! It really is crazy how fast and completely that changed.

No idea why you're being downvoted. The only difference between telemetry and spyware is there's a "legitimate company" with "legitimate interests" behind it.

Re: JSON Hero: Enhanced JSON structure visualization

#178
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…

There's an issue on the github requesting a local version

https://github.com/apihero-run/jsonhero-web/issues/134

Re: JSON Hero: Enhanced JSON structure visualization

#179
post #146
post #64

Earlier quoted context omitted.

> 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. Exhibit A: DotNet! https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

Well, dotnet DOES mention it in getting started (first run): Telemetry --------- The .NET tools collect usage data in order to help us improve your experience. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell. Read more about .NET CLI Tools telemetry: https://aka.ms/…

The "HN crowd" is right. We don't want these corporations exfiltrating any information about us. We don't really care what it is or what they're going to use it for. We want them to have exactly zero bits of information about us. Their attempts to collect data without our consent demonstrates a complete lack of respect for us and our wishes.
Post reply on HN