JSON5 – JSON for Humans

Original Article ↗ Hacker News Discussion ↗

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.