The Unreasonable Effectiveness of HTML
- Author: Thariq
- Article title: Using Claude Code: The Unreasonable Effectiveness of HTML
- X source: status/2052809885763747935
- Examples gallery: thariqs.github.io/html-effectiveness
Markdown became the default because it is simple, portable, mildly rich, and easy for humans to edit. But Thariq’s workflow has changed: he is increasingly not hand-editing the files himself. Instead, agents produce specs, planning documents, brainstorm outputs, reviews, and mockups. Once that happens, markdown’s biggest advantage weakens, and HTML’s expressive range starts to dominate.
- Cheap to write
- Portable
- Easy to edit directly
- Good for short linear documents
- Better at visual hierarchy
- Better at comparison and dense information
- Can be interactive
- Easy to share as a link
Format is not cosmetic here. The format changes what people will actually read.
The article lays out several reasons. The first four are the structural core: information density, readability, sharing, and interaction. Then it adds two more: better data ingestion when used from Claude Code, and the simple fact that making these artifacts is more joyful.
Ctrl/Cmd + wheel to zoom. Scroll to pan. Drag to pan when zoomed. Double-click to fit.
- Tables instead of ASCII hacks
- CSS and layout for structure
- SVG for diagrams and illustrations
- Script tags for richer snippets/behavior
- Large specs become navigable
- Responsive layouts improve phone reading
- Tabs, links, and sections reduce friction
- Upload once, share a URL
- No special markdown renderer needed
- Higher chance coworkers actually open it
- Sliders and knobs for tuning designs or algorithms
- Controls that export changes back into prompts
- Documents become lightweight playgrounds
- Claude Code can inspect files, git history, browser context, MCP tools
- That context can be turned into a richer report artifact
- This is one reason to use Claude Code over a plain chat surface
- The author explicitly says it is simply more fun
- That emotional involvement matters
- More engagement means more review, iteration, and trust
This is the deeper layer: the article is really about a changed human-agent relationship. If humans are mostly steering, inspecting, comparing, and exporting rather than hand-authoring every line, then the artifact should optimize for review and interaction, not just editability.
| Question | Markdown-first workflow | HTML-first workflow |
|---|---|---|
| Primary human role | Edit and annotate the document directly | Inspect, compare, tune, and steer the artifact |
| Artifact shape | Single linear note/spec | Page, dashboard, explainer, prototype, or mini-tool |
| Best for | Short plain documents | Dense, multi-modal, shareable artifacts |
| Human bottleneck | Stops reading after ~100 lines | Can navigate visually and actually finish reading |
The article is concrete, not abstract. It gives repeated examples across several categories. Those examples matter because they show HTML is not just for reports — it is useful anywhere the agent is trying to help a human compare, review, tune, or understand something complicated.
- Explore multiple implementation options
- Compare visual designs side by side
- Create an implementation plan with mockups, data flow, and code snippets
- Build a web of related artifacts rather than one giant markdown file
- Render actual diffs with margin annotations
- Color-code findings by severity
- Explain tricky logic with diagrams
- Attach HTML explainers to PRs
- Prototype components, interactions, and animations
- Use HTML as a sketch layer even if the real app is Swift or React
- Add tuning controls like sliders and knobs
- Synthesize info from code, Slack, git history, and the web
- Turn it into a report, explainer, or deck
- Use SVG diagrams to make hard topics readable once
This section was easy to miss if you skim, but it is one of the sharpest ideas in the whole article. Sometimes text prompts are the wrong interface. In those cases, ask the agent to make a throwaway HTML editor for the exact data you’re working on — not a product, not a framework, just a one-off operational UI.
- Draggable cards across Now / Next / Later / Cut
- Pre-sorted by the model’s best guess
- Copy final ordering back out as markdown
- Form-based editing UI
- Grouped by area
- Warn on dependency violations
- Export only the changed keys
- Editable prompt on the left
- Sample inputs with live rendering on the right
- Variable slot highlighting
- Character/token counter and copy button
- Some decisions are painful to express in pure text
- Drag/drop, sliders, and forms externalize cognition
- You don’t need to productize the tool for it to be useful
- Reordering tickets or feedback
- Editing config with constraints
- Tuning prompts and templates
- Curating datasets or annotations
The article explicitly addresses objections. That matters because the argument is not “HTML is universally superior.” It is “the benefits are often worth more than people assume.”
- HTML is less token-efficient than markdown
- It usually takes longer to generate
- HTML diffs are noisy and harder to review in version control
- Bad design quality can make artifacts ugly or distracting
- He is more likely to actually read the result
- Other people are more likely to read the result
- The added expressiveness dominates the cost for many tasks
- With large context windows, token overhead matters less
FAQ distilled from the article
- Isn’t it less token efficient? Yes, often. But the author argues the increase is outweighed by expressiveness and by the fact that he actually reads the result.
- When do you still use markdown? The author says he has largely stopped using markdown for almost everything, while admitting he is on the maximalist end.
- How do you view the HTML? Usually just open it locally in a browser, or upload it to somewhere like S3 for link sharing.
- Does it take longer? Yes — explicitly called out as 2–4× slower than markdown.
- What about version control? This is called one of the biggest downsides: HTML diffs are noisy and hard to review.
- How do you make it match your taste? Use a frontend design plugin or build a design-system reference file from your own codebase.
The article’s advice here is deliberately anti-ceremonial. Don’t overengineer a `/html` ritual too early. Don’t treat the format as magic. Start by asking for a real HTML artifact and be explicit about what the artifact should help you do.
- Ask what the artifact should enable: compare, explain, tune, review, share
- Prompt from scratch at first
- Develop a skill later if patterns repeat
- Think in terms of pages and interfaces, not just documents
- Turning it immediately into a cargo-cult slash command
- Using HTML for everything without a human-readability reason
- Focusing on prettiness over utility
- Forgetting to define an export path when interactivity is involved
This is the part most summaries flatten, but it is the real ending. The author had begun to fear that because he had stopped reading plans deeply, he would have to leave Claude alone to make choices. HTML changed that feeling. It made him feel more in the loop than ever before.
HTML is valuable here because it increases the odds that the human will actually look, understand, react, and steer.
- Long markdown plans get skimmed
- Human trust becomes passive
- Agent choices feel more opaque
- Artifacts become readable enough to inspect
- Controls and visual structure invite steering
- The human remains engaged in decisions
- Better review loops
- Higher trust grounded in inspection
- More effective collaboration with stronger agents