Just ported it to rust and plan on maintaining it if you want to add it to your original comment.

More details on a sibling comment:

https://github.com/fcoury/fracturedjson-rs https://crates.io/crates/fracturedjson

Comment with details: https://news.ycombinator.com/item?id=46468641

This is a good idea, though I don’t think it would guarantee program equivalence beyond the test cases.

This is also basically a pure function which makes it super simple to write a harness.

Data driven test suites are really good for building trust in a library. Both the html5lib-tests suite and my recent xss-bench are examples of this!

Ports are a derivative work; you should preserve the original author's copyright attribution.

Probably, we need a formal data format, because JSON is just a notation. It does not mandate the bit width of numbers, for example, or whether ints are different from floats. Once there is such formal model, we can map it 1:1 between representations.

I am writing this because I work on a related topic https://replicated.wiki/blog/args.html

This is very interesting, though the limitations for 'security' reasons seem somewhat surprising to me compared to the claim "Anything JSON can do, it can do. Anything JSON can't do, it can't do.".

Simplest example, "a\u0000b" is a perfectly valid and in-bounds JSON string that valid JSON data sets may have in it. Doesn't it end up falling short of 'Anything JSON can do, it can do" to refuse to serialize that string?

Can you tell me what was the context that lead you to create this?

Unrelated JSON experience:

I worked on a serializer which save/load json files as well as binary file (using a common interface).

From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem)

So I change the json format into something way more lax (optional comma, optional colon, optional quotes, multi line string, comments).

I wish we would stop pretending JSON to be a good human-readable format outside of where it make sense and we would have a standard alternative for those non-json-centric case.

I know a lot of format already exists but none really took off so far.

Reminds me of Lite3 that was posted here not long ago:

https://github.com/fastserial/lite3

What about compression rates?

I think JSON is too limited and has some problems, so BONJSON has mostly the same problems. There are many other formats as well, some of which add additional types beyond JSON and some don't. Also, a few programs may expect (and possibly require) that files may contain invalid UTF-8, even though it is not proper JSON (I think it would be better that they should not use JSON, due to this and other issues), so there is that too. Using normalized Unicode has its own problems, as does allowing 64-bit integers when some programs expect it and others don't. JSON and Unicode are just not good formats, in general. (There is also a issue with JSON.stringify(-0) but that is an issue with JavaScript that does not seem to be relevant with BONJSON, as far as I can tell.)

Nevertheless, I believe your claims are mostly accurate, except for a few issues with which things are allowed or not allowed, due to JavaScript and other things (although in some of these cases, the BONJSON specification allows options to control this). Sometimes rejecting certain things is helpful, but not always; for example sometimes you do want to allow mismatched surrogates, and sometimes you might want to allow null characters. (The defaults are probably reasonable, but are often the result of a bad design anyways, as I had mentioned above.) Also, the top of the specification says it is safe against many attacks, but these are a feature of the implementation, which would also be the case if you are implement JSON or other formats (although the specification for BONJSON does specify that implementations are supposed to check for these things to make them safe).

(The issue of overlong UTF-8 encodings in IIS web servers is another security issue, which is using a different format for validation and for usage. In this case there are actually two usages though, because one of these usages is the handling of relative URLs (using the ASCII format) and the other is the handling of file names on the server (which might be using UTF-16 here; in addition to that is the internal format of the file paths into individual pieces with the internal handling of relative file paths). There are reasons to avoid and to check for overlong UTF-8 encodings, although this is a different more general issue than the character encoding.)

Another issue is canonical forms; the canonical form of JSON can be messy, especially for numbers (I don't know what the canonical form for numbers in JSON is, but I read that apparently it is complicated).

I think DER is better. BONJSON is more compact but that also makes the framing more complicated to handle than DER (which uses consistent framing for all types). I also wrote a program to convert JSON to DER (I also made up some nonstandard types, although the conversion from JSON to DER only uses one of these nonstandard types (key/value list); the other types it needs are standard ASN.1 types). Furthermore, DER is already canonical form (and I had made up SDER and SDSER for when you do not want canonical form but also do not want the messiness of BER; SDSER does have chunking and does not require the length to be known ahead of time, so more like BONJSON in these ways). Because of the consistent framing, you can easily ignore any types that you do not use; even though there are many types you do not necessarily need all of them.

That's neat, but I'm much more intrigued by your Concise Encoding project[1]. I see that it only has a single Go reference implementation that hasn't been updated in 3 years. Is the project still relevant?

Thanks for sharing your work!

[1]: https://concise-encoding.org/

There's a C# CLI app in the repo: https://github.com/j-brooke/FracturedJson/blob/main/Fracture...

  Output is to standard out, or a file specified by the --outfile switch.  Input is from either standard in, or from a file if using the --file switch

It looks like both the JavaScript version and the new Python C# wrapper have equivalent CLI tools as well.

RCL (https://github.com/ruuda/rcl) pretty-prints its output by default. Pipe to `rcl e` to pretty-print RCL (which has slightly lighter key-value syntax, good if you only want to inspect it), while `rcl je` produces json output.

It doesn’t align tables like FracturedJson, but it does format values on a single line where possible. The pretty printer is based on the classic A Prettier Printer by Philip Wadler; the algorithm is quite elegant. Any value will be formatted wide if it fits the target width, otherwise tall.

I don't know, but you can always use <() process substitution to create a temp file.

You can (usually) specify the input file name as “-“ (single hyphen) to read from stdin

this would be amazing to be chained with jq, that was my first thought as well.

This is good! There are a number of these, so it seems like it's definitely somthing people want. The most popular of which I think is gron[0]. My own is jstream[1]. One tiny point of friendly feedback: you may want to consider adding an example usage/output so folks can see what it does literally.

[0] - https://github.com/tomnomnom/gron [1] - https://github.com/ckampfe/jstream

do you have an ouput example?

If you're reaching for a tool like this, it's because you don't have a well-defined schema and corresponding dedicated visualization; you're looking at some arbitrary internal or insufficiently-documented transfer-level data with nested structure, perhaps in the midst of a debug breakpoint, and need a quick and concise visualization without the ability (or time) to add substantial code into the running runtime. Especially if you're working on integration code with third parties, it's common to come across this situation daily.

I think yes? I fairly often find that I have something in JSON, which probably is from some system to system comms, and I'm trying to read it. Once it's not trivially small I often pipe it through jq or python -m json.tool or whatever, I like the idea of something that just does a better job of that.

If you discard the human-readability component of it, JSON is an incredibly inefficient choice of encoding. Other than its ubiquity, you should only be using JSON because it’s both human and machine readable (and being human-readable is mainly valuable for debugging)

I just built a C++ formatter that does this (owned by my employee, unfortunately). There's really only two formatting objects: tab-aligned tables, and single line rows. Both objects also support a right-floating column/tab aligned "//" comment.

Both objects desugar to a sequence of segments (lines).

The result is that you can freely mix expression/assignment blocks & statements. Things like switch-case blocks & macro tables are suddenly trivial to format in 2d.

Because comments are handled as right floating, all comments nicely align.

I vibe coded the base layer in an hour. I'm using with autogenerated code, so output is manually coded based on my input. The tricky bit would be "discovering" tables & block. I'd jus use a combo of an LSP and direct observation of sequential statements.

Right. In my previous work, I wrote a custom XML formatter for making it look table-like which was our use case. Of course, an ideal solution would have been to move away from XML, but can't run away from legacy.

Yaml is the worst. Humans and LLMs alike get it wrong. I used to laugh at XML but Yaml made me look at XML wistfully.

Yaml - just say Norway

Just say Norway to YAML.

    country: no

    country: false

    country: “no”

    Roles: [editor, product_manager]

    something:
        setting: true
    ---
    another:
        thing: false

Yaml works really well with LLMs (not to generate but to consume). So yes, we use it all the time in our service.

I'm the maintainer of FracturedJson. The decision to stop publishing a binary for the CLI version was made a long time ago: fewer features, fewer users, less mature .NET tooling (as far as I knew). And as you say, .NET isn't a common language for distributing CLI tools.

I plan to take a new look at that when I have the time. But a port to a more CLI-friendly platform could probably do a better job.

I really liked the idea, so I am porting it to Rust https://github.com/fcoury/fracturedjson-rs

Linters shouldn’t format code.

I dont know if you spend a fraction of your life scrolling vertically through megabyte sizes json files, but if something can reduce the height of the file thats welcome. We dont need to read every single line fro left to right, we just need to quickly browse through the entire file. If a line in this format is longer than fits the screen, its likely we dont need to know whats in the cut off right corner anyway.

It's a pretty sensible policy, really. Corollary to Hyrum's Law - do not permit your API to have any behaviours, useful or otherwise, which someone might depend on but which aren't part of your design goals. For programmers in particular, who are sodding munchkins and cannot be trusted not to do something clever but unintended just because it solves a problem for them, that means aggressively hamstringing everything.

A flathead screwdriver should bend like rubber if someone tries to use it as a prybar.

XML people were doing crazy things in the Java/.NET world and "<!--[if IE 6]>" was still a thing in HTML when JSON was being designed.

I also would have wanted comments, but I see why Crockford must have been skeptical. He just didn't want JSON to be the next XML.

Unrelated: why spaces inside the parentheses? It’s not the first time I see this, but this is incorrect!

    if ( x == ( y + z ) * w ) {

The trouble with yaml is that it's too hard to keep track of how indented something is if its parent is off the screen. I have to keep a t-square on my desk and hang it from the top of my monitor whenever this comes up.

That, and the fact that it has enough bells and whistles to that there are yaml parser exploits out there.

Minified json would use even less tokens

Works right up until you get an entity where the field `comments` is suddenly relevant and then you need to go change everything everywhere. Much better to use the right tool for the job, if you want JSONC, be explicit and use JSONC.

Personally, I think if your JSON needs comments then it's probably for config or something the user is expected to edit themselves, and at that point you have better options than plain JSON and adding commentary to the actual payload.

If it's purely for machine consumption then I suspect you might be describing a schema and there are also tools for that.

idk... "ans: 42 // an old reference from DA API" seems easier to read than wasting 4 lines of yours

multiply that for a long file... it takes a toll

---

also sometimes one field contains a lot of separate data (because it's straight up easier to deserialize into a single std::vector and then do stuff) - so you need comments between data points

I think integration into jq would be both powerful and sufficient.

People have a problem and are trying to solve it. We are not all required, nor able, to solve whatever the world’s most urgent problem is today.

In this case they are formatting JSON in an easier to read way. It’s not an alternative to CRDT, it is a totally different issue.