An SVG is all you need

Original Article ↗ Hacker News Discussion ↗

Interactive power of SVG + JS

  • Many comments highlight that SVG plus embedded JavaScript and CSS can recreate much of what Flash once did (keyboard/mouse interaction, audio, animations).
  • Examples mentioned: interactive CNC assembly diagrams, a chess engine running entirely inside an SVG, SVG-based dashboards, a barbecue controller UI, a music game, a dance–blocking/choreography tool, SCADA-style monitors, and decorative/animated wallpapers.
  • SVG is treated as part of the DOM: scripts inside an <svg> behave like in normal HTML, enabling D3, Observable Plot, and other libraries for rich data visualization and research figures.

Tooling, authoring, and workflows

  • Designer tools already output SVG; some people generate SVG via Python for charts or build apps that emit SVG from code.
  • There’s experimentation with LLMs to manipulate SVG or compress QR-code SVGs, though some doubt current models handle complex SVG well.
  • New tools appear for markdown-to-SVG and for interactive research sites that reproduce paper figures in the browser.
  • Others note pain points: limited editors (especially on Linux), difficulty handling transforms and path extraction, and a desire for better, Word-like editors for HTML/SVG “documents.”

Portability, compatibility, and longevity

  • A key positive: a 20‑year‑old SVG still renders and remains interactive in modern browsers, which is seen as strong evidence of spec stability.
  • At the same time, people report real-world issues: Safari rendering bugs, lack of support in Slack, iOS native apps, email clients, and many Open Graph preview contexts.
  • SVG is praised for crisp scaling, but fonts and text are tricky: no native text wrapping, awkward or heavy font embedding, and inconsistent rendering across renderers.

Performance and complexity tradeoffs

  • Some report SVG becoming slow or memory‑hungry with many elements (dense maps, QR codes, chess grids, complex diagrams), and note that canvas/WebGL can be more efficient.
  • Others say they’ve built complex animations with hundreds of elements that perform fine, arguing that bad performance is usually in how it’s used.
  • There’s debate over whether SVG is suitable for highly interactive scientific environments, with disagreement on how “complex” it can get before frame rates suffer.

Security and sanitization

  • Inline SVGs can embed scripts and external references, triggering security reviews.
  • Suggested mitigations: strong Content Security Policy for served SVGs, sandboxing on separate domains, and sanitization tools (DOMPurify, svg-hush).
  • A linked write-up frames SVG as a significant attack surface; some respondents counter that CSP and proper handling largely address this.

Accessibility and document-format debates

  • Several comments worry that SVG-heavy content is not easily accessible to visually impaired users or keyboard-only users, especially for interactive charts.
  • There’s discussion of whether “one self-contained SVG per paper” is overkill compared to HTML+JS, notebooks, or PDFs with limited interactivity.
  • SVG is seen as a poor drop‑in replacement for PDF due to multi-page, printing, encryption, and strict layout needs, though others compare it favorably to PostScript-era programmable documents.