Academic writing still starts from a manuscript. The tooling changes, but the workflow is usually the same: draft, revise, share, format, submit.
That sounds obvious, but it matters because most academic tools are built around the wrong layer of the problem. They optimize either for final-page formatting or for general-purpose document editing. Researchers spend most of their time somewhere in between: shaping arguments, moving sections around, inserting figures, revising citations, and collaborating on text that will eventually need to fit a publisher template.
I think markdown is a practical foundation for that workflow.
Not because markdown is complete. It is not. But because it gets the core part right: a paper is mostly structured text, and structured text should remain easy to read, diff, generate, and transform.
Why Existing Tools Fall Short
Word is still the default for many people, but it is a poor source format.
- It is hard to version cleanly.
- It is hard for AI systems to edit reliably.
- It tends to mix content, layout, and editor state together.
LaTeX solves some of those problems, but it introduces a different set of tradeoffs.
- It is powerful, but the surface area is large.
- Browser-based editing is still awkward.
- Local setup is heavier than it should be for many authors.
- Even with better tools around it, it is still another formatting language to learn.
Typst improves on many parts of LaTeX, especially ergonomics, but it is still a separate system with its own syntax and conventions. That may be fine for people who enjoy learning document systems. It is less fine if the goal is to reduce friction for writing and collaboration.
Markdown sits in a different place. It is minimal, portable, and already familiar to a large number of technical users. More importantly, AI can read and generate it well. That matters more now than it did a few years ago.
Why Markdown Is Interesting
For most papers, the content itself is not unusually complex. It is mostly prose, figures, tables, equations, references, and section structure. The complexity comes later, when that content needs to satisfy page layout rules from ACM, IEEE, Springer, or whoever else is on the other side of the submission portal.
Markdown is interesting because it keeps the manuscript close to plain text while still describing structure. Underneath, it is just an AST with a familiar surface syntax. That makes it a useful interchange format between a human editor, an AI assistant, and a renderer that knows how to target a specific publication style.
In other words, markdown is not the whole product. It is the source layer.
Where Plain Markdown Stops Working
The obvious objection is that plain markdown is not enough for academic publishing. That objection is correct.
Markdown does not give you a strong template story out of the box. It does not have a built-in model for page layout. Complex tables are awkward. Figures need more metadata than a plain image tag usually carries. Publishers care about page breaks, margins, caption placement, and front matter conventions. Those are document concerns, not just text concerns.
So the right question is not whether markdown alone can replace Word or LaTeX. It cannot. The right question is whether markdown can be the authoring format at the center of a better system.
I think the answer is yes.
Toward a Markdown Dialect
The practical direction is a paper.md file with a small number of extensions.
This does not require inventing a new language from scratch. Markdown directives are already a reasonable path for attaching structured metadata to content blocks. They are not standard markdown, but they are widely recognized and fit this problem well.
That opens the door to richer academic elements without forcing the whole document into raw HTML. Figures can carry labels, captions, and placement hints. Tables can use markdown when they are simple and fall back to HTML when they are not. Citations and references can be resolved by the document pipeline instead of being hidden inside editor-specific state.
| Need | Markdown | Extension |
|---|---|---|
| Body text | Native | None |
| Figures | Partial | Directive metadata |
| Complex tables | Weak | HTML fallback |
| Templates | Missing | Document model + renderer |
Once you think about it this way, the architecture becomes clearer.
- Markdown handles author-friendly source editing.
- A document model handles structure that markdown alone cannot express.
- A renderer handles template-specific output.
That separation is important. It means authors can work in a lightweight source format without giving up the ability to produce a final document that respects strict venue requirements.
The Editor Should Not Be a Binary Choice
The editor question is also often framed too narrowly. People talk as if the choice is between a code editor and WYSIWYG, but those modes solve different problems.
A code editor is excellent for precision, source control, and AI-assisted editing. WYSIWYG is useful for visual inspection, layout awareness, and lower-friction editing for some tasks. For academic writing, it is reasonable to ask: why not both?
If the source format is stable and the document model is explicit, then the interface can present multiple views of the same manuscript. One view can look like a structured markdown editor. Another can preview the rendered pages. A third can expose higher-level document operations such as figure management, section navigation, or template switching.
That is a much more interesting direction than arguing about whether markdown should somehow become a full publishing format by itself.
Layout Still Matters During Writing
One mistake in technical writing tools is assuming layout only matters at the very end. In reality, authors care about layout long before submission.
They want to know whether a figure breaks awkwardly across pages. They want to see whether a section is too long, whether a table fits, whether the title block is reasonable, and whether the paper is drifting past a page limit. Those concerns show up during drafting, not only during export.
That means a paper editor needs some notion of pages, breaks, and template constraints even while the author is still working in source form. Pretext matters. The system should help the writer reason about the eventual document, not hide that reality until the final minute.
Why This Is a Good Fit for AI
This is also where markdown becomes especially useful in an AI-native workflow.
AI works better when the source is explicit, text-based, and structurally meaningful. A model can rewrite a paragraph, reorganize a section, propose a better caption, or transform a notes file into a polished draft more reliably when it is operating on markdown than when it is reverse-engineering a binary document format.
The benefit is not just generation. It is also review, transformation, and automation.
- Convert rough notes into a paper skeleton.
- Suggest section-level revisions.
- Normalize figures and captions.
- Enforce document conventions.
- Target multiple output formats from the same source.
That is much easier when the manuscript remains close to plain text.
Build the Product That Exists, Then Revisit the Stack
There is a separate implementation question here: what should the app itself be built with?
Electron is an easy target for criticism, especially on macOS. A fully native app is tempting. I have not written a Swift app before, and rewriting the whole thing with AI into a native shell is an interesting idea. It may even be the right idea later.
But not first.
The main problem is not whether the shell is Electron or Swift. The main problem is whether the writing model is correct. If the source format, editor model, and rendering pipeline are wrong, a native rewrite does not save the product. If those parts are right, the implementation can evolve.
So the priority is simple: make the writing workflow work first.
Closing Thought
Academic writing software does not need another monolithic editor pretending to solve everything at once. It needs a better separation of concerns.
Markdown is a strong starting point because it keeps the manuscript readable, portable, and compatible with both human and AI workflows. But the real opportunity is not markdown by itself. It is markdown plus a structured document model, template-aware rendering, and an editor that treats source and layout as complementary views of the same paper.
That is the direction behind Essay: not replacing academic writing with a new syntax, but giving the manuscript a better home.