Fake Trees: Using Indents for Simpler UIs

Original Article ↗ Hacker News Discussion ↗

Developers debate the practice of representing hierarchical data in UIs and databases using “fake trees” — flat lists with indentation or path-like keys — instead of explicit parent-child structures. Proponents argue these approaches are simpler, performant, and sufficient when only a nested visual layout is needed, invoking YAGNI to avoid premature complexity. Critics counter that such encodings mix presentation with data, complicate future features like subtree operations or reordering, and overlook well-established tree modeling techniques in relational databases such as adjacency lists, materialized paths, nested sets, and specialized types like PostgreSQL’s `ltree`.

When “fake trees” are appropriate

  • Several commenters note that many UIs only need the appearance of hierarchy: a flat list plus an indent level is often enough (e.g., TOCs built from HTML headings, comment threads rendered via indent).
  • For these cases, “fake trees” are praised as simpler, easier to implement, and cache‑friendly. Collapsing can be done by iterating siblings until an equal-or-lower indent is found.
  • Some argue this fits a YAGNI mindset: if you only need nested display today, don’t overbuild full tree semantics.

Risks, limitations, and future change

  • Many warn that representing visual hierarchy in the data model is “dangerous” and shortsighted.
  • Users will infer real parent–child relationships; requests for subtree operations, reordering, or batch actions often arrive later.
  • Critics emphasize that renaming or deleting intermediate nodes, enforcing valid parents, and moving subtrees can be awkward or expensive with purely visual encodings.
  • Several say the article underplays these issues and overstates the downsides of real trees, calling it shallow, rant-like, or clickbaity.

Tree representations in databases

  • Multiple canonical models are mentioned:
    • Adjacency list (parent ID).
    • Materialized path (e.g., a/b/c or dotted paths).
    • Nested set / MPTT for efficient subtree queries.
  • PostgreSQL ltree and SQL Server hierarchy types are cited as native materialized-path-like options, with notes about label restrictions and missing-parent caveats.
  • Some suggest storing order/indent first, then migrating to parent/child later since hierarchy can be reconstructed.

Performance and tooling

  • Experiences differ: recursive CTEs are described as both “fine and fun” and as slow or unwieldy at scale.
  • Nested JSON blobs are mentioned as another “fake tree” that can actually be quite faithful to the logical structure.
  • There’s a meta-thread that knowledge of these patterns (Celko-style hierarchies, classic SQL techniques) is becoming rarer, partly due to ORMs, NoSQL, and reduced emphasis on data modeling.