HN Debrief

Show HN: Extend UI – open-source UI kit for modern document apps

  • Open Source
  • Developer Tools
  • Programming
  • AI

Extend released 14 MIT-licensed UI components and examples for document-centric web apps. The package targets common pain points in products that need to display and work with PDFs, Word docs, and spreadsheets inside the browser, including annotation overlays, file upload flows, schema building, and e-signatures. The company says it built the kit after finding existing viewers too incomplete or rough for its own production workload, which runs millions of pages a day. The comments largely bought that premise. People building document automation tools immediately recognized the gap, especially for DOCX and XLSX preview without punting to Word, PowerPoint, or server-side PDF conversion.

If you build document intake, review, or AI workflow products, this is a useful starting point instead of rolling your own viewers or converting everything to PDF. Treat it as a React-first toolkit with real-world rendering experience, then validate mobile performance, search behavior, and fidelity against your own corpus before adopting it deeply.

Discussion mood

Mostly positive and pragmatic. People liked seeing a real open-source answer to browser-based document viewing, especially for DOCX and XLSX, but they were quick to call out missing basics in the launch such as clearly stating the React dependency and fixing demo performance and mobile issues.

Key insights

  1. 01

    Virtualized pages keep overlays usable

    The PDF and DOCX viewers are not just dumping full documents into the DOM. They virtualize pages with react-virtual, which is the difference between a toy viewer and something that can survive long documents while keeping bounding-box highlights lined up through zoom. Rotation support is still missing, so anyone doing document review with scanned or rotated pages should treat that as an open gap.

    If your product needs search, citation, or review overlays on large documents, page virtualization should be on your checklist before you evaluate visual polish. Test rotated pages early, because that is exactly where annotation math usually breaks.

      Attribution:
    • andrewlu0 #1
    • CraigJPerry #1
  2. 02

    XLSX rendering rests on a custom Rust stack

    The spreadsheet viewer is backed by a Rust XLSX/XLS parser compiled to WebAssembly, not a thin wrapper around the usual JavaScript spreadsheet packages. That matters because the authors explicitly said they ran into event loop issues with SheetJS and ended up building their own path, then render the parsed content onto a canvas. It explains why this exists at all. Spreadsheet rendering in the browser is still rough enough that teams keep rebuilding it when they need scale and responsiveness.

    If spreadsheets are central to your app, assume you may need a parser and rendering path designed for your workload rather than a generic JavaScript library. WebAssembly is worth considering when large files or UI responsiveness are already hurting you.

      Attribution:
    • andrewlu0 #1 #2 #3
    • dvt #1
  3. 03

    Avoiding PDF conversion is a real adoption hook

    One reader said this directly replaces a planned server-side DOCX and XLSX to PDF conversion pipeline. That is a strong signal about the market gap. Teams are still converting Office files to PDF because browser-native preview is unreliable, even though conversion throws away editability, spreadsheet behavior, and often layout fidelity in edge cases. A credible in-browser viewer removes infrastructure and product compromises at the same time.

    If you are converting Office files to PDF only to get a preview experience, re-check that decision. A browser viewer can cut backend complexity and preserve more of the original document behavior for users.

      Attribution:
    • hobofan #1
    • andrewlu0 #1

Against the grain

  1. 01

    React-only limits the library's reach

    Calling this a UI kit for modern document apps sounds broader than what is actually shipping. A commenter pushed back that shipping only React components leaves out a large chunk of the web stack, and the reply confirmed React was chosen because it fits the team's workflow and familiar conventions like shadcn and Tailwind CSS. That makes sense for them, but it also means this is not a general web platform building block yet.

    Do not mistake this for a universal document rendering layer. If your frontend stack is not React, budget for a wrapper, a fork, or a different approach entirely.

      Attribution:
    • spankalee #1
    • andrewlu0 #1
  2. 02

    Demo quality undercuts the launch

    Several readers found basic product-marketing issues faster than advanced rendering bugs. The site initially failed to say it was React-based, mobile Safari showed load problems for at least one person, the landing page felt slow even on a recent MacBook Pro, and an advertised spreadsheet search feature was hard to trigger or absent in practice. The authors fixed some copy quickly and argued the root page is an unusually heavy demo surface, but the first impression still suggested rough edges.

    Evaluate the package from isolated component pages or a local install, not from the all-in-one marketing page alone. At the same time, treat rough docs and demos as a warning that integration may require more self-service than the polished visuals imply.

      Attribution:
    • hju22_-3 #1
    • andrewlu0 #1 #2 #3
    • plastic041 #1
    • KolmogorovComp #1
    • qreoct #1

In plain english

canvas ↩
A browser drawing surface used to render graphics or custom layouts with JavaScript.
DOCX ↩
The Microsoft Word document format based on zipped XML files.
DOM ↩
Document Object Model, the browser's in-memory representation of a web page that JavaScript can read and modify.
lazy loaded ↩
Loaded only when needed, such as when a user scrolls a component into view, to reduce initial page cost.
mobile Safari ↩
Apple's Safari web browser running on iPhone or iPad.
PDF ↩
Portable Document Format, a common file format for fixed-layout documents that look the same across devices.
React ↩
A popular JavaScript library for building web user interfaces from reusable components.
react-virtual ↩
A React library for virtualizing long lists or page stacks so only visible items are rendered.
shadcn ↩
A popular set of copyable React UI components and patterns built with Tailwind CSS.
SheetJS ↩
A widely used JavaScript library for reading and writing spreadsheet files such as XLSX.
Tailwind CSS ↩
A utility-first CSS framework that provides many small styling classes you combine directly in markup.
WebAssembly ↩
A low-level binary format that lets code written in languages like Rust run in the browser at near-native speed.
XLS ↩
An older Microsoft Excel spreadsheet file format that predates XLSX.
XLSX ↩
The Microsoft Excel spreadsheet format based on zipped XML files.

Reference links

Product links

  • Extend UI
    The main open-source UI kit being launched, with demos and component pages.
  • Extend demo video
    A video walkthrough of the document UI components released with the launch.
  • Extend AI
    The company product that originally used these components internally before open-sourcing them.

Parsing and rendering libraries

  • lopdf
    Rust library mentioned as part of one commenter's local PDF parsing stack.
  • rtf-parser
    Rust parser mentioned for handling Rich Text Format files in a document workflow tool.
  • calamine
    Rust spreadsheet parsing library mentioned as part of a working XLSX ingestion stack.

Related Hacker News reference