Git, JSON and Markdown walk into bar

Original Article ↗ Hacker News Discussion ↗

Trailing commas, commas-first, and editing ergonomics

  • Many dislike JSON’s lack of trailing commas; rearranging or appending lines forces editing two lines and leads to hidden syntax errors.
  • Some advocate leading commas (comma‑first) in SQL/JSON-like lists so every line is copy‑pasteable and the “last item is different” problem disappears. Others find this visually ugly and still error‑prone.
  • There’s debate whether trailing commas actually improve consistency:
    • Pro: every item looks the same, diffs are cleaner, reordering is trivial.
    • Con: a trailing comma obscures the fact that an item is currently the last one; some prefer explicit last entries.

JSON design trade‑offs: human vs machine

  • Complaints: no comments, no trailing commas, no multiline strings; people still type JSON by hand for configs, schemas, and game data, where comments and easier editing would help.
  • Others argue these constraints were good design: stricter grammar, simpler parsers, and consistent quoting outweigh minor annoyance, especially with editor support.
  • Some see JSON as “for machines to author,” with JSON5/JSONC etc. as evidence the ecosystem wants more human features—but note those haven’t displaced plain JSON.
  • There’s disagreement about whether comments “belong” in payloads:
    • One side: comments should live in documentation; JSON is not code.
    • Other side: configs, schemas, and mixed code‑data (e.g., scripts fields) clearly benefit from inline explanations.

JSON vs XML/YAML/TOML and schemas

  • Several call JSON a “tragedy” compared to XML’s mature ecosystem: schemas, DTDs, XSLT, built‑in validation, and transformation tooling.
  • Counterpoints: XML’s flexibility (attributes vs elements, verbose type encodings) led to complexity, ambiguity, and security issues; JSON is a simpler “minimum viable data struct.”
  • Some praise XML used in a disciplined way (e.g., no attributes, or attributes only as metadata). Others note JSON lacks an in‑band way to attach metadata like types.
  • YAML is viewed as easier to write but error‑prone and complex to parse; TOML is liked for small configs but criticized once nesting gets nontrivial.

Markdown, emphasis semantics, and underline history

  • Thread revisits the blog’s question of why *bold* and _italics_ instead of *bold* and /italics/.
  • One explanation: Markdown inherited _word_ from pre‑Markdown conventions where underline meant “typeset in italics,” and from the goal of expressing emphasis vs strong emphasis, not literal bold/italic.
  • Others argue that in practice bold/italic are used for many meanings (emphasis, foreign words, math, headings), so a purely semantic split (em/strong) doesn’t map cleanly to real usage.
  • People reminisce about older plain‑text markups (Fidonet, IRC, BBCode, org‑mode) using /italic/, *bold*, _underline_, ~strike~.
  • Lack of a single Markdown standard is highlighted: tools differ on which markers they accept and how they render them.

Diffs, structure‑aware tools, and version control

  • Line‑based diffs are cited as a driver behind the popularity of trailing commas and one‑item‑per‑line styles.
  • YAML/JSON diffs become especially bad when logical order doesn’t matter but syntax is ordered; some use specialized tools (e.g., order‑invariant YAML diff) to cope.
  • There’s skepticism that smarter JSON‑aware diffs/merges should replace making file formats friendlier to real‑world editing and VCS workflows.

Usage patterns, tools, and binary vs text

  • Some use Markdown as the core of note‑taking and personal knowledge systems (e.g., with Obsidian plus external scripts), valuing that the underlying data is just text.
  • Git‑history cleanup tools like BFG Repo‑Cleaner get brief mention for sensitive data removal.
  • One commenter criticizes using JSON for all game data as “amateur,” advocating binary, in‑memory‑layout formats for large numeric datasets; others point out the author is an experienced game developer and likely knows the trade‑offs.

Tone and personal remarks

  • Several readers find the blog’s dig at John Gruber unnecessary or mean‑spirited, arguing it weakens an otherwise technical, nostalgic piece.
  • Others interpret it as tongue‑in‑cheek but acknowledge the remark triggered a tangent about Gruber’s Apple fandom and perceived bias.