DEV Community

Cover image for Word Is for Writers. LaTeX Is for Academics. Neither Is for Developers.
Kevin
Kevin

Posted on

Word Is for Writers. LaTeX Is for Academics. Neither Is for Developers.

There's a third option, and it lives in the editor you already have open.

Pick any developer who regularly writes documents longer than a README. Ask them what they use. You'll get one of three answers: Word (reluctantly), Google Docs (with apologetic hand-waving about version control), or LaTeX (with the haunted look of someone who has debugged one too many undefined control sequence errors at midnight).

None of them will say they enjoy it. The reason is simple: all three tools were built for someone else.


The Wrong Tools for the Job

Word was designed for typing letters. Its fundamental model (WYSIWYG editing where formatting is baked directly into the document) hasn't changed since the early nineties. That works fine if you need to print a letter. It falls apart when you need to version-control a contract, keep styling consistent across a 30-page document touched by six people, or reproduce the same report next quarter without reformatting it from scratch.

LaTeX is the other extreme. Structurally brilliant, genuinely painful to use. The syntax is verbose and unforgiving. Error messages are famously useless. There is no live preview: you compile, wait, check what broke, fix it, compile again. Nobody who isn't forced to use it chooses it voluntarily in 2026.

The gap between these two is where most developers are stuck.


Markdown Was Already the Answer (Partly)

Developers already solved the documentation problem with Markdown. It's plain text, version-controllable, readable without rendering, writable in any editor. READMEs, changelogs, docs sites, pull request descriptions: all Markdown. No proprietary format, no binary blobs, no formatting drift when someone else opens the file.

The limitation is that standard Markdown was never designed for professional output. No page layouts, no headers and footers, no auto-numbered figures, no equations, no styled tables, no citations. For a README it's enough. For a quarterly report, a scientific paper, or a client-facing specification it isn't.

That's the gap Autype closes.


Why Not Just Use LaTeX for Serious Documents?

This is the reasonable counterargument. LaTeX does have proper content-layout separation. Its output quality is excellent. Cross-references and bibliographies are handled correctly by default. There's a reason it's still the standard in academic publishing.

The problem is the entry cost and the daily friction. Setting up a working LaTeX environment (distribution, packages, compiler, editor) is its own project before you've written a single word. The workflow is a loop of write-compile-debug that never fully goes away. And when someone outside your team needs to edit or comment on the document, you're converting to DOCX via Pandoc and hoping for the best.

With Autype, equations use the same LaTeX syntax ($$E = mc^2$$). The output quality is comparable. But the rest of the document is normal Markdown, the setup is an extension install and an API key, and exporting to DOCX is a single click. You keep the math without the ceremony.


What Extended Markdown Actually Looks Like

Autype's syntax is a strict superset of standard Markdown. Everything you already write keeps working. What's added is the layer that turns a text file into a print-ready document.

This is a single excerpt from the business report example that ships with the extension:

## Revenue Overview {#revenue-overview}

Total revenue for Q4 {{fiscalYear}} was **$4,215,000**, driven by strong
performance across all product lines.

:::chart{type="bar" title="Quarterly Revenue ($K)" caption="Revenue by Quarter" anchor="fig-revenue"}
labels: Q1, Q2, Q3, Q4
dataset: Subscription | 1850, 2100, 2450, 3035 | #3b82f6
dataset: Services     |  720,  810,  980, 1180 | #22c55e
:::

As shown in [Figure {num}](#fig-revenue), subscription revenue grew
consistently throughout the year. The quarter-over-quarter growth rate:

$$
\text{QoQ Growth} = \frac{R_{Q4} - R_{Q3}}{R_{Q3}} \times 100\% = 22.9\%
$$

:::table{caption="Financial Summary" anchor="tab-financial"
         headerBg="#1e293b" headerColor="#ffffff" rowAltBg="#f8fafc"}
| Metric            | Q3 2024    | Q4 2024    | Change  |
|-------------------|------------|------------|---------|
| Total Revenue     | $3,430,000 | $4,215,000 | +22.9%  |
| Gross Margin      | 75.0%      | 78.0%      | +3.0 pp |
| Operating Margin  | 15.2%      | 18.5%      | +3.3 pp |
:::

See [Table {num}](#tab-financial) for the full breakdown.
Enter fullscreen mode Exit fullscreen mode

{{fiscalYear}} is a variable substituted at render time. The bar chart is defined inline (no Excel, no screenshot). The equation is rendered as proper print-quality typography. The styled table has a dark header, alternating rows, a caption, and an anchor. The cross-references ([Figure {num}], [Table {num}]) resolve to sequential numbers in the rendered document, the same way LaTeX's \ref{} works, without the setup cost.

The full set of supported elements: bar, line, pie, doughnut, radar, scatter, bubble, and polar area charts; LaTeX math; styled tables with captions and anchors; QR codes (URL, WiFi, vCard); auto-generated table of contents, list of figures, list of tables, list of abbreviations, bibliography; multi-column layouts; page breaks with optional orientation changes; cross-references; headers and footers with logos and page numbers. All plain text.


The VS Code Extension

The Autype extension makes this workflow native to VS Code. Open a Markdown file, click Render, and the PDF appears in a side panel next to your editor.

Demo: Markdown editor on the left, live PDF preview on the right — charts, tables, and styled headings visible in the output

A project is a folder with an autype.json config alongside your content files:

my-report/
├── autype.json      ← page size, margins, fonts, headers, footers, variables
├── report.md        ← main document
├── appendix.mdd     ← additional document in the same project
└── images/          ← local images, uploaded and cached automatically
Enter fullscreen mode Exit fullscreen mode

A folder can contain any number of .md and .mdd files. Each renders as an independent document, but all share the same autype.json. A project folder can hold a main report, an executive summary, and an appendix, all with identical styling and zero config duplication.

autype.json is where the design lives: font family, sizes, colors, heading hierarchy, header (logo and document title), footer (page numbers), variables. Content and design are completely separate. Change the font or update the logo without touching the Markdown. Commit both to git, and the exact output is reproducible by anyone with the extension installed.

The insert toolbar

The preview panel has a vertical toolbar with one-click inserts for every extended element: headings, bold, italic, images, charts, styled tables, math equations, QR codes, page breaks, column layouts, variables, table of contents, list of figures, list of tables, and more. Every insert drops a ready-to-edit block into the document at the cursor position. You don't need to memorize the syntax to get started.

Local images

Drop an image into the images/ folder and reference it with a standard Markdown path: ![caption](images/logo.png). On the first render, the extension uploads it to the rendering API and caches it by content hash. Unchanged images aren't re-uploaded on subsequent renders. The path in the Markdown stays local and relative; the file is part of the repository.

Automatic indices and cross-references

::toc generates a table of contents from the actual headings. ::listOfFigures and ::listOfTables produce numbered lists of every captioned figure and table. Every chart, captioned image, and styled table gets an auto-incremented number you can reference with [Figure {num}](#anchor) or [Table {num}](#anchor). The numbers stay correct regardless of what gets added or reordered before them. Bibliography citations work the same way: define sources in autype.json, cite inline with @[id], and the reference list is generated automatically.

Getting started

  1. Install Autype for VS Code from the Marketplace
  2. Create a free account at app.autype.com and copy your API key
  3. Run Autype: Set API Key from the command palette (Cmd+Shift+P) and paste it in
  4. Right-click any folder in the Explorer and choose Autype: Create New Document to scaffold the project (creates autype.json, a .mdd file, and an images/ folder)
  5. Open the .mdd file, click the Autype icon in the editor title bar, and hit Render

Click the Autype icon in the editor title bar to open the live PDF preview panel

The extension connects to Autype's rendering API. The free plan covers unlimited preview renders (watermarked) and rate-limited PDF exports. No credit card required.

The Autype status bar button opens the command menu — Set API Key stores your key in VS Code's secure storage


Export: PDF, DOCX, and ODT

The most common objection to Markdown-based documents is: "My colleagues work in Word." Fair point. It's not a problem.

Autype exports the same document as PDF, DOCX, and ODT. The DOCX output is a proper Word document: it opens in Microsoft Word, LibreOffice, and Google Docs, can be edited further, and preserves formatting. The developer writes in Markdown in VS Code, the colleague in the business team gets a DOCX they can annotate and return, the client gets a PDF. All three come from the same source file.

This is also the practical advantage over LaTeX for most teams. Converting a LaTeX document to an editable DOCX is a project in itself. In Autype it's a dropdown in the export panel.


Documents Belong in the Repository

Because the document is plain text, it fits naturally into a git workflow. The report lives in the same repo as the code it describes. Changes are commits. Drafts are branches. Reviews are pull requests, with real diffs, inline comments, and approvals. git blame shows who changed the revenue figures and when. The autype.json that defines the visual design is committed alongside the content, so the output is reproducible by anyone with the extension.

A .docx file can't do any of this. Word documents are binary blobs with no meaningful diff, no merge strategy, and no version history that doesn't require SharePoint.


Word and LaTeX aren't going anywhere. If you write one document a quarter and don't care about reproducibility or version control, switching tools isn't worth the effort.

But if you write documents regularly as part of a development workflow (reports, specs, API references, papers, anything that needs to look professional and survive review cycles), the friction you've been absorbing isn't inherent to the problem. It's just a consequence of using tools built for different people.

The documentation is at docs.autype.com. The full syntax reference is at https://docs.autype.com/markup-reference/overview.

Top comments (0)