Native all the way, until you need text

Original Article ↗ Hacker News Discussion ↗

Native rich text and Markdown are hard

  • Many commenters report that “just” rendering and editing rich text/Markdown natively is far from trivial, especially with streaming updates (LLM chats, logs, long documents).
  • Problems cited: slow layout, UI jank when text streams in, broken selection (e.g., selecting a whole chat message), and poor behavior with large documents or long histories.
  • Several people stress that text layout with rich formatting, bidi languages, glyph shaping, and inline images is one of the hardest UI problems.

SwiftUI, AppKit, TextKit debates

  • Some say AppKit / NSTextView / TextKit 1 are solid and performant, but integrating them cleanly into a modern SwiftUI app is awkward.
  • TextKit 2 is described as powerful but “kinda broken” and hard to use correctly; others claim good results but acknowledge complexity.
  • A recurring theme: SwiftUI is convenient but often slower and less flexible, especially on macOS; non-trivial or non-standard UIs frequently hit limits.

Electron, WebKit, and “native vs web”

  • Many argue that embedding WebKit to render Markdown/HTML is the most pragmatic option on Apple platforms; WebKit is considered “native enough.”
  • Others push back, saying that relying on a browser engine just to get rich text is perverse and undermines the point of native toolkits.
  • Electron is framed as “the worst option except all the others”: heavy, memory‑hungry, but with a huge, battle‑tested text/layout stack and ecosystem, which explains its popularity.

Performance and memory trade‑offs

  • Disagreement over priorities:
    • One side: RAM is abundant; UX smoothness and developer time matter more than saving hundreds of MB.
    • Other side: Electron/Web engines cause unnecessary hardware churn, paging on 8–16GB machines, and are still slower than well‑engineered native UIs.
  • Some benchmarks and anecdotes show SwiftUI lagging vs AppKit or Qt; others claim modern SwiftUI can be fast if carefully optimized.

Tooling gaps and ecosystem alternatives

  • Suggestions include Qt, JUCE, Slint, WebKit, litehtml, Rust and C++ renderers, and custom engines (e.g., block editors, VMPrint‑style layout).
  • Several note that browsers/Chromium have had vastly more investment than native UI stacks, which explains their maturity in text rendering.

Meta: skill vs framework

  • A strong “skill issue” chorus claims native APIs can do this if used well.
  • Others counter that for many product teams, spending months building a custom editor instead of features is unrealistic, so web‑centric solutions win.