FracturedJson

Role and Design of JSON (Comments, Scope, Philosophy)

• Debate over JSON’s lack of comments: some call the original reasoning (“would be abused for directives”) silly; others defend it via Hyrum’s Law—any extra feature will become a de facto API surface.
• Several note real‑world workarounds ("comment", "_comment_uuid" fields) and argue this is inevitable when people need to annotate configs.
• Some say if you need comments, you should use a different format (JSONC, JSON5, or a dedicated config format) rather than overloading plain JSON.
• View that JSON was intentionally kept simple to avoid becoming “the next XML”, even at the cost of missing conveniences.

FracturedJson: Use Cases, Pros and Cons

• Many find the table‑like, width‑aware layout noticeably more readable than standard pretty‑print, especially for large or nested structures.
• Suggested uses: debugging API responses, game‑dev JSON, logs, occasional manual inspection where a full schema/UI doesn’t exist.
• Some dislike examples where only some elements expand, or where long horizontal lines require scrolling, but others prefer reduced vertical height for huge files.
• Multiple requests to integrate with jq, editors, IDEs, or as a browser/preview extension, often just for viewing rather than rewriting source.
• Concern that realignment harms git diff, and that it shouldn’t be used as a primary human‑editable config syntax.

Implementations, Tooling, and Testing

• Current maintained implementations noted in C# and TypeScript/JavaScript, with a newer Python wrapper around the C# code and a fresh Rust port including a CLI.
• Some friction around needing a .NET runtime; Rust and other “CLI‑friendly” ports are seen as important for adoption.
• Discussion of reading from stdin and piping, with users wanting easy chaining with jq and shell tools.
• Several call for a language‑independent, data‑driven conformance suite so different implementations behave identically; debate around how far tests and mutation/fuzzing can “guarantee” equivalence.

JSON vs Other Formats (YAML, TOML, XML, Binary, Lax Supersets)

• TOML/YAML are proposed as better for human‑editable configs; others respond “just say Norway” and recount YAML pitfalls (implicit booleans, indentation fragility, legacy parsers).
• Mixed nostalgia for XML: it has comments and schemas, but is seen as verbose and harder to read.
• Some argue JSON is too restrictive as a human format; various extended or alternative formats are mentioned (JSON5, BONJSON, EDN, ASN.1, custom lax JSON variants).
• Others say for serious systems, use binary/schematized formats like Protobuf and treat JSON mainly as a debugging/human inspection layer.