Why DocsLit
Most documentation tools are built on React. That means your docs site ships a JavaScript framework, hydrates static content the browser already rendered, and asks you to learn JSX just to add a callout. DocsLit takes a different approach: standard Markdown, native web components, and zero framework runtime.
The numbers
Client-side JavaScript
This is the JavaScript your readers download on every page load. Less JS means faster Time to Interactive, better Lighthouse scores, and lower mobile data costs.
Why the gap is so large
React-based documentation tools pay three taxes that DocsLit avoids entirely:
React + ReactDOM is ~28 KB gzipped before your docs site adds a single word. Then add a client-side router, state management, and the framework's own bootstrapping code. Docusaurus bundles webpack runtime, route manifests, and the entire SPA shell — on a 4,000-page site, main.js alone reached 10 MB uncompressed.
DocsLit loads Lit from a CDN import map. Lit is 5 KB gzipped. There is no router library, no state management layer, and no bootstrapping overhead.
React SSR renders your page to HTML on the server, then the browser downloads JavaScript to "hydrate" that HTML — recreating the virtual DOM, attaching event listeners, and diffing against what's already on screen. For a documentation page, 75% or more of this work is wasted: static headings, paragraphs, and lists gain nothing from hydration.
DocsLit produces plain HTML at build time. Web components upgrade themselves in place — no virtual DOM, no diffing, no wasted work. Only interactive elements (tabs, accordions, code blocks) run JavaScript.
MDX compilation requires a dedicated pipeline: @mdx-js/mdx (25 dependencies), a bundler integration (webpack or Vite), and a JSX runtime. Docusaurus pulls 1,000+ npm packages into node_modules (300–500 MB on disk).
DocsLit uses unified + remark + rehype — the same Markdown pipeline — but outputs plain HTML instead of JSX. Components are concatenated strings, minified with a single esbuild call. Total production dependencies: 20 packages.
Build performance
React-based tools
Docusaurus builds a 50-page site in 30 seconds to 2 minutes. A 1,500-page site takes 5 minutes cold. A 2,000-page site can take 20 minutes.
Each build runs webpack (or Rspack), Babel (or SWC), the MDX compiler, and React's server-side renderer. The output is a full SPA with code-split route bundles.
DocsLit
DocsLit renders Markdown to HTML with unified, writes files to disk, and is done. No bundler runs. No framework compiles.
The build produces individual .html files, one CSS file, one JS file, and a search index. Static hosting serves these directly — no Node.js server required.
What you don't need
What you get for free
Features that require plugins, configuration, or paid tiers on other platforms are built into every DocsLit site:
Every static build generates llms.txt, llms-full.txt, and a working MCP server (mcp-server.js) that AI agents can use to search, list, and read your documentation. No plugin, no configuration, no third-party service.
A search index is generated at build time and loaded client-side. No Algolia account, no DocSearch application, no external API calls.
Request any page with Accept: text/markdown and get raw Markdown back. APIs and AI agents can consume your docs as structured content without scraping HTML.
Run docslit build --offline to produce a self-contained site with lazy-loaded pages. Works without a server, from a file:// URL, or on an air-gapped network. No external requests, no inline event handlers — hardened for secure environments.
docslit import auto-detects and converts projects from Mintlify, Docusaurus, Nextra, GitBook, MkDocs, Sphinx, ReadMe, VuePress, VitePress, Starlight, and Fern. One command, no manual rewriting.
The authoring experience
With React-based tools, adding a callout to a documentation page looks like this:
With DocsLit, you write:
No import. No JSX. No file-level configuration. The component is available everywhere because it is a web component registered in the browser, not a framework-specific module.
When React-based tools make sense
DocsLit is not the right choice for every project:
- You need deeply custom interactive pages — if your docs include full React applications (embedded playgrounds, drag-and-drop editors), a React-based tool gives you direct access to the React ecosystem.
- Your team already maintains a React design system — if you want to reuse existing React components without porting them to web components, staying in React avoids duplication.
- You need ISR or server-side logic per request — tools like Mintlify and Nextra can run server-side code on each page load. DocsLit produces static files.
For documentation sites that prioritize speed, simplicity, and portability, DocsLit delivers a faster site with less complexity.