JSON5 – JSON for Humans

Original Article ↗ Hacker News Discussion ↗

JSON5, a JSON superset that adds comments, trailing commas, and more relaxed syntax, is pitched as a more human-friendly way to write configuration and data files. Commenters welcome features that make hand-edited files easier to read and maintain, but worry about name confusion with standard JSON, interoperability problems with tools expecting strict JSON, and the broader problem of “yet another” config format alongside YAML, TOML, HJSON, and others. Many conclude that JSON’s success comes from its minimal, stable spec, and that any richer format must balance human convenience against complexity, ambiguity, and ecosystem fragmentation.

Overall sentiment

  • Many like JSON5’s goal of “JSON with nicer ergonomics,” especially for configs.
  • Others see it as “yet another almost-JSON format” that increases confusion and tooling pain.
  • Several argue the real problem is overusing JSON for configuration instead of dedicated config languages.

JSON5 features & perceived value

  • Widely appreciated:
    • Inline comments.
    • Trailing commas (cleaner diffs, easier editing).
  • Mixed feelings:
    • Single-quoted strings and unquoted identifiers seen as convenient by some, needless complexity by others.
    • Leading/trailing decimal points on numbers (.3, 3.) are viewed by some as human-friendly robustness, by others as readability or locale-dependent hazards.
  • Some wish JSON5 also had:
    • Multiline strings.
    • A proper datetime literal.
    • Better Unicode escape support (e.g., for non‑BMP chars).

Comments, schemas, and design philosophy

  • Large subthread on JSON’s lack of comments:
    • Many consider it a long‑term mistake, pointing to ugly workarounds like _comment keys, duplicate keys, or external docs.
    • Others defend the original choice as reducing abuse (e.g., parser directives in comments) and keeping the core spec simple for data interchange.
    • Some argue that if you need comments heavily you should use a different format or a preprocessor, not change JSON itself.

YAML, TOML, and other formats

  • YAML:
    • Praised for comments and expressiveness, but widely criticized for footguns: indentation significance, unquoted scalars auto‑typing (e.g., “Norway problem”), and huge spec complexity.
    • Some suggest using “JSON + # comments” as a constrained subset of YAML, though skeptics note this relies on discipline and tooling.
  • TOML:
    • Seen by some as a nice human‑oriented config format; others find nested data and arrays of tables confusing compared with explicit JSON structure.
  • Other contenders mentioned: HJSON, HuJSON/JWCC, KDL, Dhall, HOCON, CUE, Pkl, EDN, JSONC, Jsonnet, custom TS/TypeSpec‑based configs, etc.; adoption and tooling remain the main barrier.

Naming, compatibility, and ecosystem concerns

  • “JSON5” name is seen as misleading; it sounds like an official next version.
  • Fear that .json files might quietly become non‑JSON, breaking tools like jq.
  • Some advocate: servers may accept JSON5‑style input (comments, trailing commas) but always emit strict JSON, preserving interoperability.