einichi a year ago

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 file format convertors and permanently retain all submitted data.

  • alias_neo a year ago

    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.

    • Jenk a year ago

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

      • alias_neo a year ago

        Ouch, this is particularly egregious:

        "...To opt out, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable before you install the .NET SDK"

        • FearNotDaniel a year ago

          Just to be clear: that is to opt out of the single telemetry message sent by the installer itself on successful install, not to opt out of .NET telemetry in general. You can do that at any time post install by setting the env var, no need to remove and reinstall the entire SDK just to turn off telemetry.

          • alias_neo a year ago

            I still consider this fairly egregious in that if you've already installed it (but not used it) before finding this out; a bunch of details has already been reported about your environment. Does opting it before install also keep you opted out of all telemetry or does that have to be done separately?

            If a new starter did this on a company machine, boom, misconduct on their first day; though I hope the network/operations team have already put a block in place for that.

            That is an extreme example, but it's kind of annoying you have to look this up, and make sure you didn't typo the flag for every piece of software you use/test.

            • jaywalk a year ago

              That flag opts out of all telemetry.

          • ilyt a year ago

            It not being opt-in is the problem

            • yamtaddle a year ago

              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.

              • matheusmoreira a year ago

                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.

              • ilyt a year ago

                Well, it's not as simple. Telemetry can be something as benign as sending error report when app crashed (which generally is useful if it doesn't leak other data and leads to better app), or as intrusive as tracking every click.

                The context is also important, beta test of a game's entire point is to get that data to improve the product.

        • pseudonymcoward a year ago

          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.

          So seems relatively reasonable to me.

          • simplotek a year ago

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

            • sleepyfran a year ago

              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.

            • jve a year ago

              > These metrics even include MAC addresses.

              MAC address SHA256 hashes, to be precise.

              • account42 a year ago

                MAC addresses are only 48-bit and sparsely allocated (i.e. the first half indentifies the vendor). I wouldn't be surprised if the hashes for all normal hardware (i.e. with known vendors) can be easily brute forced.

      • jve a year ago

        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/dotnet-cli-telemetry
        
        https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...

        HN crowd associate telemetry with privacy or cancer and the T word gives shrugs... but it is not always the case.

        > Protecting your privacy is important to us. If you suspect the telemetry is collecting sensitive data or the data is being insecurely or inappropriately handled, file an issue in the dotnet/sdk repository or send an email to dotnet@microsoft.com for investigation.

        • Jenk a year ago

          It sends telemetry as part of the installation, too. It is implementing a deliberately dark pattern as well. It should be an option presented right at the installer screen, _and_ should be default to opt-out.

          • adalacelove a year ago

            >_and_ should be default to opt-out.

            Here I don't agree. It should be certainly be visible, so you can make an informed decision whether or not to use it. But it's a sad fact of human nature how little we are willing to contribute back even when people give us something for free, even if just a click away (not to mention paying a small amount, filling a bug report...)

        • matheusmoreira a year ago

          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.

    • briandear a year ago

      I worked at a $massive_tech_company_with_extreme_secrecy and using these tools was expressly forbidden because of the risk. Maybe one exists, but I would gladly pay $20 for a Mac app that could do all of this locally: like a Markdown Pro type app but for JSON formatting and validation. I want to simply open the app, paste in some json and have it format it to my requirements (spaces/tabs/pretty/etc.)

      • ilyt a year ago

        I vaguely remember some tool that was just a collection of random tools like that running as local server (including a bunch of crypto primitives) but I can't remember the name now...

        • einichi a year ago

          You’re probably thinking of the tool made by GCHQ, CyberChef

          https://gchq.github.io/CyberChef/

          • alias_neo a year ago

            Great tool that i'd recommend any software person, techy, reverse engineer etc should self-host.

            I host in in my kube cluster with all outbound connections blocked, just to be safe.

          • ilyt a year ago

            Yup, thanks!

  • Mogzol a year ago

    Completely agree. I could actually get a lot of use out of a tool like this, but the fact that even the VSCode extension sends the JSON to their servers and opens it at a publicly accessible URL makes this a no-go for me. I wouldn't recommend anyone use this for any remotely sensitive data.

    • chii a year ago

      the extension apparently can be configured to use a locally running instance of the server. But yes, by default it uses the remote version, and thus you post publicly the json, which may or may not be ideal depending on what you're doing.

      • Mogzol a year ago

        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.

        • mholt a year ago

          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 extremely difficult to stream large files in an efficient, reliable way. Web Workers make things slightly better, but there's so many issues with large-scale local compute in a browser tab.

          A few examples:

          - https://stackoverflow.com/questions/24708649/why-does-web-wo... (the answer actually came from Google+ which is still linked to, but no longer available; fortunately I summarized it in my post)

          - https://stackoverflow.com/questions/27081858/how-can-i-make-...

          You get deep enough into the weeds and eventually you realize you can make it work cross-browser if you know which browser you're using (YES, User-Agent does matter for things like this) and call you crazy for trying to find out:

          - https://stackoverflow.com/questions/27084036/how-can-i-relia...

          Despite all this, I *100%* agree and local-only processing is also a hard-rule for me as well. (That's why JSON-to-Go[1] does it all client-side. `go fmt` event compiles to WASM and runs in the browser!)

          [0]: https://www.papaparse.com/

          [1]: https://mholt.github.io/json-to-go/

          • simplotek a year ago

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

            • hutzlibu a year ago

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

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

          • rob74 a year ago

            Ok, I think I get what you're saying - this is a VS Code extension, but because VS Code is an Electron application, it's still "running in a browser"?

      • rob74 a year ago

        "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 what you're doing" - that's never ideal, it's just a smaller problem (if the JSON is publicly available anyway) or a much bigger problem (if it's sensitive personal data).

        • TeMPOraL a year ago

          > 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 explicit, bold warning that it's shipping data off your machine, is just being rude.

          • simplotek a year ago

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

            • TeMPOraL a year ago

              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.

              • simplotek a year ago

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

                You claimed that personal data was a red herring. It is not. Shipping personal data is the worst possible scenario. It's unthinkable to try to make the case that a data leak is not serious because it's just personal data.

                • TeMPOraL a year ago

                  > You claimed that personal data was a red herring. It is not. Shipping personal data is the worst possible scenario.

                  Which is exactly what makes it the red herring. Shipping personal data is one of the worst possible scenarios (I'd argue that, in corporate context, shipping data that's subject to export controls is worse, as it could easily get you fired, the company fined, and potentially land someone in jail) - which makes it a perfect distraction from all the other data that's being exfiltrated. "We're not collecting personal data" is the equivalent of putting a "doesn't contain asbestos" label on food packaging.

                  • simplotek a year ago

                    Either you do not know what's the meaning of "red herring" or you're failing to understand the problem. Personal data is the reddest of data, even and specially in a corporate context.

                    You can also have more data that is red, but if your infosec policies fail to prevent or stop personal information being sent, which is the lowest of low-hanging fruits to spot, then you will assuredly be leaking more red data that is harder to spot.

                    It makes no sense to try to downplay the problem if leaking personal data. It's the most serious offense in any context, not only for the data but specially for what it says about the security policies in place.

                    • TeMPOraL a year ago

                      > Either you do not know what's the meaning of "red herring" or you're failing to understand the problem.

                      Merriam-Webster: "red herring [noun] (...) 2. [from the practice of drawing a red herring across a trail to confuse hunting dogs] : something that distracts attention from the real issue"

                      English Wikipedia: "A red herring is something that misleads or distracts from a relevant or important question. It may be either a logical fallacy or a literary device that leads readers or audiences toward a false conclusion. A red herring may be used intentionally, as in mystery fiction or as part of rhetorical strategies (e.g., in politics), or may be used in argumentation inadvertently."

                      This is exactly the meaning I'm using, so I think I know it just fine. To reiterate once again: leaking personal data isn't the only way telemetry can be problematic - it's not even the major issue in practice, thanks to associated risk of fines and bad PR (GDPR was quite helpful here). Saying that your telemetry is fine because it's not collecting personal data is just a way to distract the reader. It's the equivalent of advertising your heavily processed food product as safe "because it doesn't contain asbestos".

          • pletnes a year ago

            I agree, mostly. But since when isn’t it obvious that posting data with a browser will send that data somewhere? And the users here are (from what I can tell) developers.

            I think this is a cool tool for public data and obviously I can’t paste private data sets on any public website, ever.

            • TeMPOraL a year ago

              It's not obvious ever since some of those tools started to blur the line; there are plenty of such little utilities that do everything client-side, or at least claim so. I don't use them with anything but public data, as it takes one mistake or one silent update for the data to get shipped off my machine, but there's a whole generation of devs now who were growing up with webapps and online-first software, so I can easily see some developers making this mistake.

              Plus, they offer a VS Code extension. It's not so obvious that it's just the same public website underneath.

              Additionally, developers who understand those concerns kind of expect that other developers also understand them, and thus would not create an on-line tool like this in the first place.

            • simplotek a year ago

              > I agree, mostly. But since when isn’t it obvious that posting data with a browser will send that data somewhere?

              I'd be surprised if anyone at all, specially developers, expects a browser to do anything other than transfer data to/from the internet.

  • eallam a year ago

    Eric here (one of the creators of JSON Hero) and this is a really good point. We built JSON Hero earlier this year and partly wanted to use it to try out Cloudflare Workers and Remix, hence the decision to store in KV and use that kind of architecture. We're keen to update JSON Hero with better local-only support for this reason, and to make it easier to self-host or run locally.

    • jessikat a year ago

      If the vscode extension did it all locally, I'd 100% install in an instant!

      • donkeyd a year ago

        To add to this, I'd probably pay for this too, if it wasn't too expensive.

    • epaulson a year ago

      There are instructions in the readme to 'run locally' - are you saying that even that version (running on localhost:8787) is sending something back to y'all, either from the client in the browser or sending something back via the locally-running server?

      I was totally about to clone this repo and run it locally so I can play with some internal json.

    • T3RMINATED a year ago

      If the vscode extension did it all locally, I'd 100% install in an instant! DITTO

  • wohfab a year ago

    This reminds me of an "Online HTML Minifier" website that analyzed the text and included affiliate links for random words within the text.

    And they operated for years, when someone noticed links on their own website, they haven't added themselves and tried to figure out, how it happened, because nobody else had access to the website.

    (Will update with a link, if I find it.)

  • naan_bread a year ago

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

    • ljw1004 a year ago

      I think there is an easy way to prove this to users. Make your thing be a single page self contained html file which they save into the hard disk. Then they can trust the restricted permissions with which chrome runs such local files.

      If you have a tech savvy audience they can also view your thing in an iframe with only sandbox="allow-scripts" to prove that it's not making network requests.

      I wrote an html/js log viewer with those security models https://GitHub.com/ljw1004/seaoflogs - it handles up to 10kline log files decently, all locally.

    • alpaca128 a year ago

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

      • informalo a year ago

        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.

        • remram a year ago

          It could be storing data and send it later when you visit the same origin from a different tab.

          Unless you were also using incognito or throwaway tab containers to discard stored data.

    • jspash a year ago

      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.

  • veltas a year ago

    No Dave, you can't upload this export-controlled document to this web tool. I don't care how convenient it is.

  • kQq9oHeAz6wLLS a year ago

    Just set up an online HL7 or better yet CCDA parser and let the PHI roll in.

  • throw903290 a year ago

    Even more, it has to work completely offline! And if it makes ANY network calls, it is a huge red flag for some!

  • ottoflux a year ago

    100% literally came here to make sure someone said this.

  • syngrog66 a year ago

    yep if I were a Bad Guy and had nation state resources I'd be salivating over trying to get "in" at JetBrains, GitHub and the like

  • kwertyoowiyop a year ago

    All those free online .PSD utilities make my spidey-sense tingle.

  • 2devnull a year ago

    Better yet, build an operating system and link it to the cloud.

aembleton a year ago

If anyone wants to try it out, but doesn't want to send them your Json, here's an example of some real world data https://jsonhero.io/j/t0Vp6NafO2p2

For me, this is harder to use than reading the JSON in a colour text editor such as VSCode. I'm getting less information on the page, and its harder to scan, but that might be because I'm used to reading JSON.

tfsh a year ago

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 single null value somewhere, or supposedly data which deviates from the majority data-type (i.e a number where every other value is a string).

I think there's value proposition in just edge case detection. Datasets can be massive, with something like JSON there exists no formal type verification. Although to be honest, I don't see a valid reason to use JSON as a backend given graph based databases with type-safe schemas exist.

1: https://news.ycombinator.com/item?id=32626873

  • rurban a year ago

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

    • vincnetas a year ago

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

      • pletnes a year ago

        Data dumps and exports between systems. REST APIs, databases, that sort of thing. CSV is the most common utf8/ascii option.

      • TeMPOraL a year ago

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

      • rurban a year ago

        I'm converting proprietary AutoCAD DWG files to some JSON format (libredwg) I invented. 600K bytes is a very small file, with just a couple of objects.

        Many other CAD formats also switched to JSON.

      • supernes a year ago

        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.

      • ilyt a year ago

        JSON logs would be obvious example here

      • janjones a year ago

        machine learning datasets are often in JSON and can be arbitrarily huge

mvindahl a year ago

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.

irrational a year ago

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.

  • KronisLV a year ago

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

    • orthoxerox a year ago

      Namespaces. I know why they were introduced, but they still were an incredible pain to use, especially with SOAP. You want to pass a <Customer> to the update method? No, it must be <Customer xmlns="http://example.com/api/customers/v2"> that is wrapped in a <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">.

      Oh, you're writing a service? You can't just XPath your way to that <Customer>, because it's a namespaced <Customer>, your XML parser will claim there's no <Customer> in the message, you have to register your namespaces "http://example.com/api/customers/v2" and "http://www.w3.org/2003/05/soap-envelope" and look for /soap:Envelope/soap:Body/c:Customer instead.

      JSON is annoyingly anal about its commas, but at least it has a single global namespace and I have never encountered a situation where I wished I could disambiguate between two different "customer" objects in my JSON payload.

    • irrational a year ago

      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.

      • mdaniel a year ago

        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!

    • IshKebab a year ago

      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.

  • 998244353 a year ago

    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.

    • eru a year ago

      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.

    • simplotek a year ago

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

      • irrational a year ago

        I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford. Before he invented JSON, we used XML to pass data around the web. After he invented JSON, it took quite awhile to catch on. There were many years of transition where some web services would only send xml and others could send xml or json. Eventually all web services gave you the choice of which one it would send. And then, gradually, xml was transitioned out and everything was json.

        • simplotek a year ago

          > I don’t understand what you mean by JSON was not invented. It was invented by Douglas Crockford.

          Douglas Crockford took his time to write up a specification for the JavaScript Object Notation (JSON).

          That specification is, quite literally, "based on a subset of the JavaScript Programming Language Standard ECMA-262 3rd Edition - December 1999."

          It's in the name. There is no way around this.

          MDN's doc on JavaScript's eval() vs JSON.parse() refer to JSON as "a subset of JavaScript syntax to represent data."

          Claiming that someone discovered JSON makes as much sense as reading the C standard section on struct initialization and proceed to claim you discovered the C struct notation (CSN).

          https://en.cppreference.com/w/c/language/struct_initializati...

          • irrational a year ago

            I don’t think that means it was not invented. Otherwise we would have had it years before. What I understand “based on a subset of JavaScript” to mean is, Crockford chose some of the JS data types (object, array, number, string) and invented a string representation of them that could be used as a data interchange format. That was revolutionary. I remember when I first learned about JSON. It felt like Crockford was a genius for coming up with it, and then wondering why nobody else had come up with it before him. There is no way we would have suffered through XML Hell for so many years I’d there had been another option. But there wasn’t another option. Why? Because Crockford hadn’t invented JSON yet.

    • s3000 a year ago

      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.

      • kaoD a year ago

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

        • alpaca128 a year ago

          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.

          • postalrat a year ago

            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.

      • 8n4vidtmkvmk a year ago

        because separating attributes and child elements is actually useful in that context. better matches the Dom. and we need the power of js to do stuffs.

      • simplotek a year ago

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

        • postalrat a year ago

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

  • stevoski a year ago

    Indeed. I’m (sorta) old and cranky and even I love JSON as a data interchange format. Because I had to use XML for years, including SOAP.

  • eallam a year ago

    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"

    • paco3346 a year ago

      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.

kondro a year ago

I like it, but don't love that it's a web app.

I guess I could fork it myself, but don't particularly want to have to run a web app to browser JSON either.

I wonder how easy it would be to port to Electron.

  • tfsh a year ago

    Forking perfectly functional browser-based web app into Electron apps is an irritating trend with very limited benefits. Some apps exist as Electron apps because they require native OS access, this app does not, therefore there is no reason to do so.

    Porting to Electron would be trivial but in doing so you incur the following ramifications:

    - the user has yet another instance of Chromium running on their device.

    - they can't interact with browser based UIs easily any longer (bookmarking, retaining in history, copying the URL, different cookie/login jars, etc...).

    - might fragment the users workflow even more if they have to interleave between electron apps and their browser

    - lack of user extensions and some important accessibility features

    In Chrome you can create a shortcut for the page and select "open in a new window" which by-in-large emulates the workflow you request. I'm sure there's a similar process for Firefox.

    • nemosaltat a year ago

      Interestingly enough, when I want the compartmentalization experience that comes from an “App” on macOS, I turn to… Microsoft Edge. Edge has a nifty little feature that lets you “Appify” a website. I mostly find this useful for company-required PWAs, and most-of-all, Microsoft Teams. The Edge-“Appified” MS Teams on macOS is leaps and bounds more performant than the “Native” (Electron) MS Teams apps on macOS (consumes ~25MB of mem vs ~800MB). Has the nice benefit of your “Apps” being a Command-Space away.

      edit: clarify & format

      • catoc a year ago

        Didn't know that about Edge, thanks!

        For other browsers (incl Edge) Fluid does the same for me (http://fluidapp.com (not affiliated))

        After opening a few emails: Outlook MacOs app: 922 MB Outlook PWA via Fluid: 42 MB

      • Lariscus a year ago

        Another benefit of this is that my ad-blocker still works with these apps and that you can always fall back to default browser behaviour like opening a link in a new tab.

    • cobertos a year ago

      I think at least forking and hosting it yourself if a good middle ground between forking into an Electron app.

      Who wants a tool they rely on to one day update with spyware, HTTP 404, or filled with ads (like Toptal did with keycode.info)?

    • zarzavat a year ago

      Browsers should make it easier to interact with the command line then. I want to be able to run a command and it opens the result in a browser tab.

      • dotancohen a year ago

        Every browser I've used supports passing a URL as an argument, and that URL is then opened.

        • zarzavat a year ago

          There’s probably some limit on that. JSON files are commonly 10s of MBs.

  • bakugo a year ago

    You are aware that Electron is just a stripped down browser, right?

Timpy a year ago

I get a lot of useful information from reading raw URLs, the exact thing they're advertising here is the thing I hate most about Jira. I even wrote a chrome extension that prevents Jira from loading smart links because I hate it so much. I can't imagine ever wanting a YouTube video preview while I'm skimming JSON data.

ranting-moth a year ago

Also, in case you're working in Typescript with a massive JSON and no types: https://quicktype.io/typescript

It generates TS type file from a raw JSON file. Has totally saved my sanity at least once.

stevage a year ago

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.

  • beardbandit a year ago

    I can think of one valuable use-case: parsing through JSON responses for APIs with poor fields/response documentation -- especially if you have to parse through a ton of information.

    Still way more readable than XML.

    • aembleton a year ago

      I think this is harder to parse than just having a well formatted structure in a text editor

    • dotancohen a year ago

        > Still way more readable than XML.
      
      AJAX should have been just AJ.
  • joeyjojo a year ago

    I could see a tool like this being really useful on my web game projects, where I would like artists/animators making contributions.

  • throwaway0x7E6 a year ago

    to make sense of API responses

    • brettermeier a year ago

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

ergocoder a year ago

I'll never paste a json from my work machine on a website... It is a security risk.

bsimpson a year ago

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 (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:5:38448)
        at Xe (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:9:6029)
        at yi (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:7:10750)
        at https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:5:38670
        at L.unstable_runWithPriority (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:1:4026)
        at rn (https://jsonhero.io/build/_shared/chunk-PZ2Z7HGX.js:5:38448)
Biggest SPA fail I think I've ever seen.
  • franga2000 a year ago

    Same (WebView inside Materialistic). The worst part is everything loads correctly, then crashes. If I time it just right, I can press the stop loading button and read the page in its entirety (styled and everything). I've seen it happen once or twice before on near-identical landing pages (maybe one of them was a previous post of this).

    It truly amazes me that anyone in their right mind would even consider writing the code that does this. This isn't something that "just happens" - someone intentionally wrote code to replace the whole page with an error message (probably a developer of some JS framework this site uses) and that's simply not acceptable. Even if this is a debug build (it obviously shouldn't be, but who knows), this behavior is insane.

  • eallam a year ago

    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?

    • ayewo a year ago

      I got a similar error when I first landed on your website from Firefox on macOS.

douglee650 a year ago

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.

  • ilyt a year ago

    The reason it won is "most popular(and only) web language used it".

    I'm not saying it's bad, I'm saying it didn't won on technical merits.

    I do dislike people using them for configs tho, even indented the readability is just "okay", the ease of change is worse than YAML (even with all it's problem), especially forcing no trailing `,` is just plainly obnoxious.

  • yamtaddle a year ago

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

    • user3939382 a year ago

      I use JSON Schema written in JSON5. That at least fixes the commenting problem.

alana314 a year ago

I just want JSON with comments. I don't want YAML.

  • toastal a year ago

    I want more Dhall. I want types for data structures and small functions for dealing with repetition.

  • user3939382 a year ago

    JSON5 is pretty nice, I hope it becomes the de facto standard at some point.

  • Zamicol a year ago

    JSON5, and optionally it has trailing commas! It's all I use now.

    • dwheeler a year ago

      More on JSON5 is here:

      https://json5.org/

      I like the comments and trailing commas too. It has a few other small improvements as well.

      • ilyt a year ago

        That does address pretty much most of my issues with it.

        It's actually good enough to even write configs in it. I do hope it will get enough traction to be standard...

  • maxbond a year ago

    Curious why YAML doesn't work for you?

    • bufferoverflow a year ago

      JSON is natively supported by many languages.

      I don't know of any language that supports YAML without a 3rd party library.

      • maxbond a year ago

        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.

        • davebranton a year ago

          YAML is much too complex. I am never able to remember all the different ways of formatting text, for instance, and have to resort to cheat-sheet guides such as this all the time.

          https://yaml-multiline.info/

          The YAML spec is thousands of lines long (23k words, to be more exact). This is even longer than XML (20k words). JSON's spec is less than two thousand words. For a language that's supposed to be human-readable, YAML is maddeningly complex.

          https://yaml.org/spec/1.2.2/

          Plus, of course, you can execute arbitrary code with it. By design. AND it contains semantic whitespace, which is personally my least favourite innovation ever.

  • jpoesen a year ago

    Then you'll want to look into JSONC.

franciscop a year ago

I've been frustrated with JSON when mixing text data and content due to the default prettier/JSON.stringify/browser format, which makes it very vertical, specially when mixing in 2d/3d data/arrays. I found a simple solution was to use json-beautify[1] before printing/saving data in files. Suddenly my 2000+ lines of scroll-fast JSON became 200-300 lines of highly legible data.

[1] https://www.npmjs.com/package/json-beautify

user3939382 a year ago

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.

  • Existenceblinks a year ago

    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?

    • user3939382 a year ago

      I agree. That's basically what I meant by, even when the base is auto-generated. In other words: you can generate a JSON schema from an example JSON. However, if you're using that to validate, say, an API response, the auto-generate tool can't possibly know what the valid range of values might be, or how some keys will shift depending on the request. Any type of variation like that requires hand-tuning.

      I use it in a variety of languages: JS/TS, PHP, Java.

      • Existenceblinks a year ago

        I believe a programming language can be written to generate any requirement you have on json schemas. Have you tried https://www.npmjs.com/package/ts-json-schema-generator and see what you can't do?

        I built a json schema editor gui saas, and my conclusion is no one is buying because they use lang libs to generate it. So I kinda surprise you said you wanted an editor.

        • user3939382 a year ago

          For my use case that doesn't really help at all. So I'm doing request/response in JSON with a third-party API and I want to programmatically detect if their response is valid, not based on any rules the API can know, but based on the context of my integration. So I use JSON schema to define what valid responses (for my particular application/integration) look like.

          How I do this now, is to get an example response, auto-generate the schema using a tool like this https://extendsclass.com/json-schema-validator.html and then hand-tune from there. In some cases the same endpoint response can have huge variations depending on the request so it's very tedious doing this by hand.

          A variation on the tool above that would help a lot would be if I could provide multiple example JSONs and it could return a schema that validates all of them.

          JSON schema is used in MySQL now natively, it's used in PHP, and from what I can tell a lot of other languages. The package you linked to assumes you're generating it from JS/TS. As JSON becomes even more popular as a data interchange format I think that assumption will be less true.

          This is just a complete guess, but maybe your tool wasn't getting traction just because it's so early in the life of JSON Schema. There's not even a final stable version 1 yet.

          • Existenceblinks a year ago

            I got you now. The data comes from an external source, and then you wanted to infer json schema from it. So I guess the json response from APIs don't have json schema defined for you. But you could define schema from their api documentation, right? It doesn't matter what tool used to generate the json schema, we only care about the result that is the schema so that you can it wherever.

            Trust me on JSON Schema spec, it's been in draft for a decade, to the point they stop calling it "draft" and put date on it instead. It's a frustrating specification (I read the whole thing dozen of time because I wanted it to fully compatible .. but decided to only adopt nice subset of it)

            Your use case is very niche though.

insane_dreamer a year ago

Super nice, but never going to paste/send my JSON to some web app for security reasons. Glad to see it can be run locally; might set it up on a local server.

benatkin a year ago

I'm not offended, but I'm also not gonna use something that says JSON sucks.

Thorentis a year ago

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

  • TeMPOraL a year ago

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

    • brettermeier a year ago

      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.

      • TeMPOraL a year ago

        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.

randomdrake a year ago

How far from WSDLs and SOAP we’ve come.

I applaud this effort. I hate that we’re back to where this feels necessary. I’m not sure if there’s anything better.

JSON sure felt better than XML. But did we abstract too far, or did we just get so much better bandwidth and processors, that enriched data exploration is just insignificantly possible?

I read the use-cases for this, but I feel like: if you’ve gone so far to where this is helpful/useful, have you just gone too far?

  • TeMPOraL a year ago

    > I read the use-cases for this, but I feel like: if you’ve gone so far to where this is helpful/useful, have you just gone too far?

    I don't understand this perspective. JSON isn't used only for RPC, even if that's what most frontend software is doing. For better or worse, it became a data serialization and interchange format - the need for such support tools arises naturally once you're generating or processing anything but most trivial data, and you value your time/sanity.

    • randomdrake a year ago

      Totally fair. I guess I was mostly considering the more typical client-server consumption, RPC-type uses and wasn’t really thinking just how much we use it for basic data interchange and serialization. Thanks.

massung a year ago

For those looking for the ability to (locally) open and query very large JSON files, Dadroit is great: https://dadroit.com.

It's been a while since I used it last, but it was a life saver for me when working with JSON lines files in S3 and Kafka log dumps.

A side tidbit, IIRC, it was written in Pascal.

osrec a year ago

As far as I'm concerned, JSON doesn't suck! For all its shortcomings, I still find it clear and easy to read, and when gzipped, it compresses reasonably well over the wire, especially when you have a bunch of repeated property names in arrays etc.

Nice tool, but like others have said, I'm pretty comfortable reading JSON in my editor.

itslennysfault a year ago

> JSON sucks

I don't understand this sentiment at all. Not even sure why we need this tool. Feels like a solution looking for a problem to me.

Personally, the built-in JSON parsing/formatting in VS Code (or any other editor) is plenty for me, and for API results Firefox will automatically format / collapse it.

Eg... open this link in Firefox: https://www.reddit.com/r/funny.json

gcau a year ago

Any VSCode extension which does this? Rather than a website

homero a year ago

I love JSON but wish it had comments

I guess I can just add an object

  • klaushougesen1 a year ago

    JSON5

    • homero a year ago

      Nice trailing commas too. Too bad it's not for machine to machine

dale_glass a year ago

There's something badly wrong with your website. I left the tab open, and somehow it grew to suck up 40GB RAM. You should really fix that.

olwmc a year ago

Tangentially related, I love this website: https://vanya.jp.net/vtree/. My first interpreter had a flag -j that output the AST as JSON so that I could see it on this site.

otabdeveloper4 a year ago

I couldn't figure out how to use this thing. (And I work with JSON for a living.)

dotancohen a year ago

I think that Emacs already provide all these features, other than the ability to email a portion of the JSON. Maybe Emacs doesn't support video previews, but it would not surprise me to find such a package.

lizardactivist a year ago

I'm not sure about the way-over-the-top name of the product, but it does look useful. Also, how much data is collected, and can people trust pasting in sensitive stuff there?

plusminusplus a year ago

It would be great to combine this with type annotations somehow (JSONC?) and have the UI nag you when a value doesn't match its expected type

(nice demo, thanks for sharing)

nodomain a year ago

Totally unclear after first glance on the site: what does it cost, what is your monetization strategy? Is it open source, for free? Please make this clearer.

enriquto a year ago

> JSON sucks. But we're making it better.

Why would you make something better at sucking? Just gron the damn thing and grep through it like a normal person.

thih9 a year ago

> JSON Hero only works on desktop (For now!)

That’s unfortunate!

I like that the landing page provides clear examples, but still, I’d prefer a full featured live demo.

julianlam a year ago

It's almost 2023, are people still looking at unformatted JSON strings in their browser?

Firefox even ships with a JSON viewer enabled by default.

jordanmorgan10 a year ago

"JSON Sucks".

It really doesn't though.

  • ilyt a year ago

    Not as readable as YAML/TOML. Vastly less if unindented.

    More annoying to write than YAML/TOML, no trailing comma. Yes I'd rank it lower than YAML even with its whitespace annoyances, good editor handle that, JSON is still annoying.

    Not super compact (althought it's not too bad when compressed).

    No proper numeric types, just one "sorta int, sorta float, depends on parser, say farewell to NaNs and infinities", you can't even losslessly transfer a normal IEEE flaot across it.

    The schema thing came late so rarely used or supported.

    So it really is pretty mediocre all things considered.

    Definitely "good enough" but could also be improved.

xigoi a year ago

Could the examples on the main page stop switching every second so I can actually lookat them?

baxuz a year ago

Would be great if this could be used as a web component for debugging purposes.

redanddead a year ago

Way better than most visualizers. Seems like an engineer built it.

shanipribadi a year ago

it still has the javascript limitation of ieee float for json numeric (hence rounding once you have bigger than 2^53) :-(