Show HN: Tritium – The Legal IDE in Rust

Original Article ↗ Hacker News Discussion ↗

Tech stack & architecture

  • Native desktop app written in Rust, using egui (immediate-mode GUI) for a VS Code–like interface; WASM/canvas “web preview” shares the same code.
  • Rust praised for speed, safety, and thread-friendliness once the learning curve/borrow-checker is overcome; rust-analyzer considered essential.
  • DOCX support was reimplemented from scratch after an earlier library dropped unrecognized data; current approach aims to preserve all content, falling back to raw XML when needed.
  • PDFs rendered via PDFium; current implementation does grayscale and downsampling for speed, with plans to expose quality/speed trade-offs and improve Retina/DPI handling.
  • Some commenters argue for DOM-based web text editing for accessibility, IME, and keyboard handling; author defends canvas/native approach for performance and control, especially relative to Electron.

Document support & core features

  • Targets transactional practices (M&A, finance, real estate, capital markets, etc.).
  • Key value props: fast redlines/diffs compared to Word/Litera, better handling of defined terms/symbols, multi-document search/replace, and integrated PDF viewing.
  • Roadmap includes external reference “go to definition” for cases/statutes, packaged libraries, shared history, and iManage-style collaboration.

UX, onboarding & preview issues

  • Many see the VS Code–style UI as intuitive for techies but unfamiliar for lawyers; debate over mimicking Word vs. selecting more technical users.
  • Feedback includes: unclear change-tracking/formatting controls, small fonts, missing basic formatting in web preview, no touch/pinch zoom, nonstandard shortcuts (Ctrl+Z on macOS), back-button interception, and issues with Japanese/IME and dead keys.
  • Web demo criticized for slow loading, 404s, layout bugs (infinite-loop pagination), and general WASM latency; author emphasizes it’s only a limited preview and encourages desktop use.

Integration with Word & legal workflows

  • Strong concern around docx fidelity, formatting stability, and not losing comments/content when round-tripping with Word; author promises “no data loss” and eventual near-full DOCX coverage.
  • Security and confidentiality are major adoption blockers; lawyers distrust anything that looks like “uploading to a server,” favor desktop, and want clarity on telemetry and AI usage (strong preference for opt-in).
  • Some suggest focusing on Word add-ins or auxiliary tools rather than full replacement; others note existing add-ins are widely used but considered clunky.

Adoption incentives & broader ideas

  • Debate over whether hourly billing disincentivizes efficiency; author positions initial focus on in-house counsel and more tech-forward firms.
  • Several lawyers and ex-lawyers express desire for git-like version control, “drafting as code,” and legal DSLs, but worry mainstream lawyers may resist.
  • Additional product ideas surface: legal DSLs (e.g., CST-style markup), “build/lint” against statutes, better footnote/back-reference navigation, and educational/consumer-facing document understanding, though the project intends to stay focused on professional users.