My concern here is that by gravitating to HTML you lose the ability for a human (you!) to easily co-author the document with the LLM. If it’s just an explainer for your consumption, that’s not a concern - but if it’s a spec sheet for something more complex, I deeply value being able to dive in and edit what is produced for me. With a HTML doc it is much harder to do that than with MD.
Now of course you could just reprompt your LLM to change the HTML - but when I already have a clear idea of what I want to say in my head, that’s just another roadblock in the way.
If this pattern becomes more common I suspect human/LLM co-creation will further dwindle in favour of just delegating voice, tone and content choice to the LLM. I was surprised not to see this concern in the blog post’s FAQ.
Markdown supports inline HTML for interactive elements, I think an interesting potential alternative would be an md doc with a known HTML template and simple build (e.g. single line pandoc command).
This is the way - lightweight build process - host it on your private tailnet to consume the document on whichever device you so choose - tablet, phone - also makes it easier to share with co-colaborstors etc. in a more secure way.
yah this should be the way. simpler text in markdown and rich visuals and complex tables in html. coding agents should handle this locally instead of wasting tokens as well.
I actually think there is a second level to this. Yes HTML will get you most anywhere, but I found that letting the LLM define its own language is also unreasonably effective.
Currently working on a dumb little mobile game with isometric view and sound:
- told codex to write a tool that lets its place blocks in a prepared three.js document and have chromium dev tools take a screenshot. It made up a little JSON structure that defines blocks / colors and some other effects and it outputs 2.5d tilesets.
- told it to create a uv python script that would let it define sounds and music, and it made a yaml format that lets it create noises.
We completely shot past the svg pelican test. Codex has created both perfectly adequate prototype art of soldiers/knights/priests as well as a prototype soundtrack.
They can map things like this. They are amazing translation layers. As long as it is a shape of problem or data they are trained on they can translate. The DSL they made up is shaped like some other data format they know for that latent space. It seems amazing, and it is, but it is also a core feature of how LLMs work. The problem is it works until it doesn’t. Fuzzy can only get you so far before it decoheres without rigor.
We have been authoring HTML by hand for decades with ease. Text editors are very good at it, and many have commands to auto-wrap, auto-close etc. Reading and writing is simple.
Templated though, not manually writing it out for every blog post say. I think GP means it just has more friction as a writing format than markdown for example.
No, literally manually typing out HTML tags and everything. Many of us did it so much things like Emmet (https://emmet.io/) were invented and used so we could hammer out full HTML documents even faster.
Even after React became popular, people are still manually typing out HTML elements, although they call it "JSX" instead, but in reality it's just HTML.
My first blog on the internet literally was a bunch of .html files, where my post "template" was the first post copy-pasted when you wanted to make a new post. Changing the design involved changing the same thing across all files.
Basic HTML really isn’t a big step up from Markdown though, and no one was complaining about that. In some instances it’s simpler even. I often forget the exact syntax for a table in Markdown, by comparison <table>, <tr> and <td> are easy to remember. All of the major parts of Markdown are pretty easy, <h1>, <strong>, etc etc. It was written with human authorship in mind.
Typing out <p> for every paragraph is annoying, for sure. But a converter that switches out \r\n\r\n for a new paragraph would be a reasonable middle ground IMO.
When using AI, I often find myself preferring either plain text (no markup whatsoever; just manual / text editor formatting of text blocks) or simple html to markdown, depending on the situation. To the point that I rarely see any point in using markdown for anything. If it is meant for to be a simple text mainly for human consumption, the markups often don't add much clarity (and often bring in an amateurish look, as if the author didn't know how to emphasize using English constructs), in which case plain text feels more pprofessional. If it is meant to be [lightly] processed before being presented to a human, or if it is meant to be processed by a tool / bot / LLM, then HTML is infinitely more straightforward.
Also I often call out my colleagues if they try to put a table in markdown. Markdown is not built for tabular data in most professional settings (i.e., one or two table cell could easily take a whole line of markdown to express). A basic <table><tr><td style="background: red">some number</td></tr></table> goes a long way.
Well if you're going to be like that you may as well say something about assembly, butterflies, and what the hell's a web log anyway, spiders and beavers have nothing to do with one another.
'we have been authoring' is present perfect continuous. Going forwards, and for at least the last two 'decades', HTML blog posts can use CMSs.
I can code up a complex HTML table by hand faster than I create a basic MD table, but other than that, I find it difficult to achieve a good writing flow with pure HTML, even with all the automation. I author a lot of API docs, READMEs, and how-to guides, and find MD to provide the perfect mix of decently powerful markup and flexibility with supporting raw HTML when needed. The only constraint is that some markup renderers don’t support or severely restrict HTML passthrough (I ran into this with GitHub recently).
Simple HTML is easy to do. If you just want a document with information and it does not need lots of branding and great aesthetics. That is what you are looking at as an alternative to Markdown.
This is shockingly true. Most newer FE devs I have encountered are mostly trained on the popular frameworks and lack understanding of the underlying fundamentals, e.g., they only know TypeScript + SCSS and some smattering of HTML but more often know whatever templating engine and MVC(ish) backend the framework uses. It’s really helpful to understand what the browser is actually doing and all the “stuff” the framework spits out on the other end.
Modern JS/TS devs probably not, but I wouldn't even call someone a "frontend dev" if you don't know HTML, kind of being a infrastructure engineer and not knowing how any OSes work.
It’s not just knowing HTML as in writing a bunch div tags and patting yourself on the back. If you aren’t able to achieve at least 80% WCAG AA compliance you can’t write HTML.
Most frontend devs have no idea what any of that means. But then it seems everyone who can write 3 lines of code professionally refers to themselves as an ”engineer”.
Yes, it's literally about being able to use HTML effectively and knowing what you are doing, then you know HTML. I'm not sure why you bring up some arbitrary accessibility guidelines, that has no bearing if someone is using HTML correctly and neither would I gatekeep the "frontend" label on some arbitrary "must pass this particular standard", never heard something so outlandish when it comes to who could call themselves frontend developer or not.
Hand on heart. When was the last time you built a serious production system for a real business that was 100% built from HTML without using any build step? Just editing the footer and header in every file when it updates (or using iframes)
I suppose that only applies if you constrain yourself to a raw teletypewriter emulator… in any proper coding environment, editing HTML should be absolutely simple - even an embedded WYSIWYG editor would be an option if rich model output is a way we head into.
A counter argument would be that all programming languages of the last decades have been plain text based. No other more structured format has ever gained traction even though modern editors could be argued to be able to support that easily. Turns out, it doesn't actually work that way.
But we’re not even dealing with a programming language in any classical sense here. Interacting with an LLM coding system is a multi-mode communication system with on-demand, purpose-generated ephemeral UI. That doesn’t fit any of the established categories, so I think carrying over constraints from them doesn’t make sense either.
Even Claude Code can whip up interactive, tabbed, multiple choice questions for example. If you use the superpowers plugin, it'll sometimes spawn a small web server demoing UI concepts or previewing more complex choices using LLM-generated HTML. Claude Code on the web will do even more involved React apps on the fly next to the chat. There's no technical reasons this couldn't get more complex, or vertically integrated with code editors.
I'd definitely call that on-demand, purpose-generated ephemeral UI.
Most people edit documents in Microsoft word, though, so it didn’t seem too far fetched that LLM content would be edited similarly, especially as more and more non-programmers use it.
I’ve started using HTML for reports recently. But I always use a markdown file as an intermediate and tell the LLM to generate a fancier version of it with SVG for graphs/pictures based on tables in the markdown.
One idea that could be useful for products like Browser Use and Stagehand is instead of using videos of the session, they can use HTML slideshows to show the step-by-step progress of the session. Single file HTMl can be downloaded and shared and annotated as well. I hope someone from those companies are here and will take this advice. I am not advocating for replacing the video sessions but also have the HTML Slideshow as another session artifact.
seems like it'd be fairly straightforward to get things setup where text blocks are double click to edit, have drag handles, delete buttons etc, and then you can also use surfingkeys to get vim style navigation.
overall i'm seeing a potential here for more human authoring, as you can really multiply the surface of your inputs with deterministic widgets rather than just delegating.
Not sure how you use CC, but the last 6 months has felt like significant optimization efforts to me. Last year Claude would just read and edit files, now it's all kinds of basic tool gymnastics with grep/awk/sed/etc to narrowly slice and avoid token-heavy reads. Resuming sessions that aren't even that large get a scary prompt about using a significant portion of your token budget if you continue without compacting.
To me it feels like a worse experience, and they probably feel it too, but it makes sense from an optimization perspective. I've probably learned some shell tricks, but also going blind from watching Claude try dozens of variations of some multi-line chained and piped wall of bash nightmare, instead of just reading a few files.
I've noticed that's changed over the past month or so. Claude-code used to happily pipe build commands straight into context, but recently it's been running them as background tasks that pipe to file, and it'll search and do partial reads on the output instead.
It also gives tips on reducing context size when you run /context .
Presumably they are actually starting to feel the pinch on inference costs themselves with what still feels like a fairly generous max plan.
And it seems to use head, tail etc. more than it used to, even when unnecessary, which, combined with the recent(?) tendency of more chaining and as you said, piping to temp files and the like, totally screwed up claude code’s auto approval system for me (by auto approval I mean the system to decide which commands can be run without permission prompt, based on the permissions.allow setting among other things, not to be confused with a specific new approval mode called “auto” that burns more tokens to decide whether the command is safe). I had to write my own auto approval system and plug it in as a hook.
By what measure? HTML as they're describing it here includes CSS and presumably Javascript. Markdown has only a handful of elements and they're all more human readable in their unrendered form. Show both to someone who has never seen either and it's obvious which they would describe as "simpler".
HTML made by Claude will, by default, be "sleek, modern", with colorful tables, cards, maybe Tailwind for styling. And, of course it will, if you wanted a barebones HTML, you would just have asked for markdown!
So the LLM decided to present some content using 4 cards, and you now want to add new itens. You can't just add new lines of text: you need to copy the whole HTML of the cards. But the LLM used different colors for each card, so now you have the first cards with varying colors and the new cards all the same color as the last card. Now you have to think about colors... etc etc
It depends what we mean I guess, isn’t Markdown supposed to allow [hx]ml tags anyway if user need them? Then it’s more about asking the LLM to generate Markdown with this in consideration, and privilege rendering the output of reports in the preferred browser after relevant rendering.
1. I believe many applications that use markdown allow html. Others don't due to security/rendering issues.
2. One of the limiting factors of LLM is context. An html table takes up way more tokens than a markdown table. Especially if it's a WYSIWYG editor that has all kinds of css and <span> tags just for fun.
> An html table takes up way more tokens than a markdown table
That might be the case today but there’s no reason for it to always be true. They are different representations of the same thing, an LLM could (arguably should!) store an internal representation that uses fewer tokens.
I don't think human coauthoring documents with AI is viable, due to very different costs. It's like with combining hand-written assembler and compiler output. I think ideally there will be some delineation which parts of the document are human-produced and which are AI-produced.
It's possible that use of `contenteditable` and ability to save the file could help but that has a lot of limitations/gotchas, so I'm inclined to agree.
Most editors format and highlight markdown syntax as bold, italic or strike through, but I have never seen the same thing for html. They only highlight the html-specific parts leaving the content unstyled.
HTML isn't difficult to read or edit by hand, non-technical people did it for years before the web became commoditized and generating everything with javascript became the standard. It's more awkward than Markdown, yes, but basically simple.
Sorry but what? HTML's really simple, I've been using it for 30 years now. Pretty much everything you need to know to do something useful can be learned in an hour.
I know that it's 2026 and we've spent the last 15 years hiring people into our field who don't understand the hacker mindset but I didn't think that I'd find them here. They would have been ran out pretty quickly.
When exploring a new idea or tool, my go to prompt is
```
In a single index.html, no dependencies, sparse styling, create an app that <idea>
```
Even before AI, it's how I built small tools, and there's something lovely about being able to email my friends the tool, and tell them "If you want to make a change, toss it to your LLM!"
It is incredible how far you get with a single HTML-file, containing styles and JS, when building dashboards, small apps and other utilities that can interact with an API or otherwise fetch data from somwhere.
I just drop it on my personal ~ folder on the shared server at work and voilà, everyone can check it out and use it immediately!
And you get sandboxxing for free! My company got tailscale recently, and its just the final cherry on top: `tailscale serve` my `/tools`, and I don't even have to worry about auth!
Same. When I iterate on a design for a new client, I create a simple index.html with inline CSS and when I'm satisfied with the result I take the file and insert it next to my project template files and just ask the LLM to take the design from index.html and work it in the template files.
I never really thought about this use case before, and I feel a bit dumb because of that. It’s so obvious that it would be useful. My focus with LLMs so far has been on The App, not all the ancillary stuff around The App. All that ancillary stuff doesn’t have to be fully complete or polished and doesn’t have to handle every possible case. It just needs to be functional enough to be useful. When you’re done with it, throw it away and generate a new one tomorrow.
My manager does this and with a straight face comes to me after with it and goes “put this in production” and wonders why it takes more than 5 minutes.
I absolutely hate the absolute rot these tools have caused to people’s brains.
Last week, we discovered our 'AI-native' marketing VP put his team's entire documentation hub on a public Github Pages site for an entire week. This included prospect lists, meetings, marketing metrics like CaC/lead times, funnel metrics, etc. He did not solicit feedback from engineering and violated multiple points in our AI policy. Of course there will be no repercussions.
Same - and always had been, really, even before LLM codegen. Always try it out in the smallest quickest simplest case first! You can always make it bigger and more complicated later.
Web technologies got so many things right. People complain about it so much but it's amazing.
I worked with a vibe coded app at my last job (and since quit due to it) and because it was a nextjs SPA frontend with a separate API backend, the user facing urls didn't match the backend endpoints. Because AI uses react hooks for everything, state is in-memory, url-based routing isn't a thing unless you design for it. So links aren't free and thus we have no way for users to link to anything other than top-level entry points. LINKS! Especially for internal tools, everything being linkable is vital to collaboration and problem solving.
The need for uniform resource locations and verbs was so well thought out, 30 or 40 some odd years ago.
it does, it's a nextjs app so there's a bunch of top level pages that work as you'd expect. The issue is that we're trying to be a real company, those pages have nested logic, multiple views, sub navigation, search, filtering, wizards, all of which are in a cascade of react hooks because AI is obsessed with self-contained hooks. none of that state is linkable.
What i learned, by fire, is that nextjs works well with its nested routing and layout-to-hold-context magic. it's quite nifty but it's not free and not obvious, you have to design for it. I can't state enough that AI will ship a billion hooks, it loves hooks for self-contained state. My colleague made a good point that that style is a feature; it limits blast radius of N features all building on top of each other.
A couple of tradeoffs I don't see mentioned here for HTML vs MD:
- HTML is significantly less token-efficient
- Difficult to provide precise feedback on plans HTML, much easier to do this in MD.
Both of these tradeoffs set Anthropic up for success. Using HTML as our medium will increase token usage, and I'd bet they're investing in tools to mark up HTML (part of Claude Design) which will help improve lock-in. Either coincidence or brilliant strategy.
Both the original Markdown spec [1] as well as CommonMark [2] clearly specify support for inline HTML. With that you can kind of get the best of both words depending on your use case.
For the most parts you just write the regular Markdown headers and paragraphs, embed images, insert tables etc without the need for any HTML tags, making it readable in source form. And if you want to embed an SVG file for example, which the author of the article mentions as one use case, you just embed the SVG directly, and people can render the Markdown in their favorite viewer.
Let's say you're viewing a raw Markdown file in VS Code. You come onto an HTML tag, so you hit Cmd+Shift+V to open the preview and that's it.
Of course for full-fledged web pages with interactive buttons and fully customized styling and all of that, which the author shows in some examples, this is not feasible. But you can get very far when you have mostly text/images/tables and just want to add some extras here and there.
Have been working with HTML in decades and still it's quicker to write markdown for simple documents. Now if you'd have some middle ground that would be nice. And actually there are already things like Githubs Markdown which has more features, you can embed mermaid etc. Or you'd use something like MDX (which readme.com is using internally) where you mix in components when needed - those could even be based on something like bootstrap because you might like having cards and layouts. Now the only thing missing is support in the interface. Plain HTML can already be rendered, adding a more capable Markdown shouldn't be too hard.
I've been advocating heavily this approach since January for non-coding use. The important property is an editable, understandable (by LLMs and humans), and renderable source-of-truth that can be incrementally modified.
I talk to laypeople about their AI work -- I am constantly doing this, inserting myself into AI conversations on the street like an anthropologist when I encounter them...
HTML artifacts are the new browser URL bar, wherein some users have a mental model that that bar is actually Google.
Many people now talk about their "spreadsheet" or their "presentation" or "marketing tear sheet", or "slide show", "competitive analysis", "hvac system diagram" or whatever the thing they were working on and how lame it was working with ChatGPT or Claude Web.... and how miraculous Claude Code or OpenClaw is with creating these new documents...
I will ask them what the documents actually are and what the difference in experience was. It takes a lot of teasing (because they don't have the computing vocabulary yet) or having them show me, and it will always come down to that the artifact is HTML.
Their pleasant experience is that it is iterating on an HTML file (+CSS +images) living on a filesystem with high quality instant rendering; plus it can sprinkle JavaScript when it needs to. It might even revision control it without them knowing if there's a git system. [I suggest they checkpoint their work if they don't; revision control is the next stage of learning for the laypeople?]
Whereas the Web-embedded experiences are stabbing multiple times on a DOCX/PPTX/XLSX lingering in a context window and a vague notion of local storage (rendered as HTML anyway in a sidebar), etc. The HTML workflow also allows other media to be integrated much more easily.
So really all this presentation work is Vibe-Coding by the masses; they don't need to know about all the turtles underneath them. But if they are willing, they could crack it open and see and edit it; or easily hand it off to another agent.
Go figure that the system created for collaborative multimedia communication ends up being useful for the machine intelligence to help us communicate.
We previously had our (https://www.definite.app/) agent write reports / dashboards in a YAML spec that would get rendered by our frontend framework (i.e. charts and tables).
For example, user says "build a report with revenue and orders by month and show 100 most recent orders". The agent would write a spec that would get rendered by our frontend.
This runs fast, but we were drowning in feature requests for what the framework could render (e.g. "I don't want labels here", "I DO want labels there", "can this chart be a heatmap", etc.)
A few months ago, we let the agent just write HTML instead. It takes longer to generate, but you get unlimited customization.
There are a host of issues with the new approach (non-technical users debugging a monstrous app they created), but net-net our customers like it much better.
"With HTML, as long as you upload the file (for example to S3), you can share the link easily. Your colleagues can open it wherever they wish and easily reference it."
You don't have to host html files. You can just email it and any browser can view it.
For similar reasons, I strongly prefer org-mode to markdown. I find that with org-mode and extensions (such as in-line elisp) I have a _significantly_ more powerful system. For example, specs can have tasks and roadmaps inline which reduces risk of drift. The biggest downside is, unfortunately, not enough folks are emacs proficient.
I hadn't considered HTML and I'm definitely going to try this.
I've reached for this solution many times too; it's certainly convenient.
What I don't like is that all the resulting pages look the same. It's so easy to tell when a page is authored by Claude, and by now, I get the same “ugh another one” feeling as Dall-E generated images would give when they were completely overdone.
Maybe it's just be, but if not, maybe HTML generated outputs will also end up being dialed down from where they're at now.
But maybe not, since it's obviously a useful thing to be able to do. I wonder if there's a way out. To be able to introduce some natural entropy so not everything ends up looking the same. I guess not, since we're using machines whose natural mode of behavior is regression toward the mean. And maybe having it be harder to tell the author wouldn't even be desirable anyway.
I moved from Markdown to JSON for all spec writing about 9 months ago. Although not HTML, it still has the same benefits. Claude and the other models are just so much more reliable in a structured format like JSON/HTML/XML.
The most important thing is that I can run static analysis on a structured format. This is important even for my spec documents. I can write data fields and have static analysis analyze it. For example, to confirm database fields match across various spec documents, etc.. The static analysis is also why you use JSON/XML instead of HTML, since you can now have your own custom schema.
Also don't use YAML, as that's far more unreliable. (If you chop a YAML file in half, it's still valid)
I think this is super interesting, but i think you and the OP is talking about two different problems: presenting text to end users and structuring text for agents
This flow is really for LLM consumption, since Markdown spec documents are for LLMs anyways. And you can always write a JSON-to-markdown converter for human use (actually, LLMs remember Markdown content better than JSON, so you should use that in your flow a well).
The real change is in generation side, and now the spec docs are LLM generated JSON based on other spec docs or human prompts. LLMs seem to write JSON better than Markdown or YAML, if you tell it to follow a schema.
For my schemas, I found LLMs really wanted to just use markdown embedded in the strings, so I've been considering doing away with the schema. I also figure that embedding markdown in a string may make it perform worse as it has to juggle nested formats, and thus escaping and such (wanted: eval for this). By replacing the json tool call with basic markdown extraction, I'd lose some structured data but gain flexibility (html would be even more flexible).
Wondering if you are referring to adherence to required data in a schema when you say LLMs do better with json vs markdown, or something else? Or perhaps to tool calls and/or strict json output being more reliably formatted for clean extraction?
This viewpoint talks about consuming markdown natively without reference to how non-technical users view it: as rendered HTML. At best, this makes a case for introducing a few more useful constructs into markdown (without ruining it's simplicity of course).
> I’ve started preferring HTML as an output format instead of Markdown and increasingly see this being used by others on the Claude Code team, this is why.
This is why I read long agent output either by using VIM and MacOS Quicklook (with a markdown extension for rendering) or paste output into MarkEdit (an editor with a preview pane; I think it’s cross platform?). Worst case, have an agent build you a simple local web page that interprets Markdown and renders it. Markdown was invented as a shorthand for web syntax[0]. That’s what it’s for! I bet you spend more tokens and time asking an agent to convert its native markdown to html than any of these.
The unreasonable effectiveness of the most popular "programming" language used by the most people on Earth ever that has been careful crafted by extremely dedicated people for decades and that is use to communicate by, to and from the most people that ever existed (because yes, most "apps", on mobile at least but even more and more on desktop are just HTML pages too).
The phrase "unreasonable effectiveness" is used here in the context of AI. Where "we put a whole bunch of markup characters in the context" not messing up the output significantly could be considered unexpected. The actual performance impact is unknowable, given the difficulty of measuring LLM performance. And whomever pays for your tokens won't be pleased either.
While it has been used in the context of HTML before, it's a bit of a "meme" as several papers used that phrase. Much like the "X is all you need" snowclone.
I always worry about posting comments like this. A lot of tech bros are like "form logical arguments about why this clickbait isn't clickbait otherwise you are a troll". You beat me too it. Thanks for your service.
I also love how maybe 10% of the posts on here are like "some thing that has existed for 40+ years ,/:/; Claude/chatgpt". So much advertising at the expense of a dead internet it's ridiculous.
I realize Claude Code is pretty impressive in a lot of ways -- certainly the way I'm working looks really different than it did last year -- but I think it is kind of funny that we are rediscovering basic ideas like "HTML is capable of richer display than Markdown."
I’ve been prompting my way to all kinds of interactive HTML artifacts the last month or so. It’s way more fun than making decks and static documentation.
I even did a workshop with PartyKit cursors, dot voting, reflection comments, and an individual rating at the end.
Oh, and I can add super lightweight analytics so I know who actually reads my things or interacts with my prototypes. ^_^
Just copy and paste the parent post into $yourFavouriteLLM and ask it to make a blog post for you to read about it. No need to ask the author to do more work than is necessary /s
Firstly I think this is a super interesting approach to a real problem. I think it offers a lot. I wonder about frustrations around consistency etc though. Have you had any?
I have been building a slightly different solution to the same problem. So far I’m pretty happy with the results and I have enough returning users that I think others are too (https://sdocs.dev/analytics).
SDocs is cli (`sdoc file.md`) -> instantly rendered Markdown file in the browser
When you install the cli it gives you the option to add a note in your base agent file (`~/.claude/CLAUDE.md`, etc.). This means every agent chat knows about SDocs and you can say “sdoc me the plan when you’re done with it” and the file will pop open instead of you having to find that terminal session to know it’s done.
Going browser first means you’re not required to install anything to get a great experience.
Despite being in the browser, the content of SDocs rendered Markdown files remain entirely local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`):
The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.
This also means you can share your .md files privately by sharing the url.
To go a bit deeper towards the HTML side of things I’ve added tagged code blocks that the agent is given documentation on how to use. Eg ```chart or ```mermaid (for mermaid diagrams). These then become interactive elements on the page (mermaid is best example of this currently)
I really like this idea. The md preview thing is super annoying. However, I was hoping your solution was like a local desktop app thats a dedicated md rendering app, things you've asked for line up in the queue for review. My browser is like a junk drawer, can't be bothered to go hunting in there.
HTML is a structured document format designed for publishing content online. It gives precise control over elements such as headings, links, images, sections, forms, styling hooks, and layout behaviour in the browser. But the cost is complexity.
Markdown is a lightweight document format that leans toward easy writing, reading, and sharing. It is much simpler than HTML, easier to edit by hand, and works well for notes, documentation, drafts, README files, and content that may later be converted into HTML, PDF, or other formats.
That's why I'll continue to use Markdown for most of my notes and documentation, while I'll only use HTML for "public facing" documents.
I notice this trend where presentations are being made with html. Even I have some prompts that create quick html + JavaScript for data viz. may be it will become our new ppts
When building new features, I use a skill that generates 5+ variants based on various companies' design language and patterns, in plain html/css/js - quick throwaway prototypes, gives me an idea of different ways the thing could look or behave. It's very very useful and I usually end up combining a couple of the best aspects. For side projects with no designer, it's been great.
I don't have any issue with markdown though - but terminal isn't a place to review it and leave useful feedback. Use one of the many tools that are popping up or build your own (like I did) to leave comments and iterate.
I use Markdown + plugins and one of the Git providers to maintain software contracts with other teams that I can’t trust to do the right thing. It has the benefits of having readable diffs and being maintainable by a human, if needed. HTML as the author acknowledges does not make readable diffs.
Markdown remains great because the other side is just going to use Claude to do their work anyway, and I can use Claude to verify their work meets my specifications.
I've created a number of apps for myself using just html or, simple node+sqlite running locally. Great for learning apps, personalized todo/priority tracking, etc.
The problem I have with this shift is that you basically give up on writing documentation by hand, not only for you, but for everybody who might want to edit your documentation.
I'm also not convinced that it solves meaningful problems :
> I've found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read,
In my experience, LLMs are not concise when it comes to documentation, so using an easier file format to read because the text is too large sounds to me like solving the wrong problem
> Markdown files are fairly hard to share since most browsers do not render them natively well.
Yes, but developers tools (IDE, Git forge) do. What most/some of them don't render natively IS HTML.
>I tend to not actually read more than a 100-line markdown file
I tend to not actually read more than 100-lines of anything anymore. I've long referred to myself as "the Google generation": only being able to read the summaries in a search result. That, and the typical doomscrolling model of social media have affected my attention span. Reading anything more substantial takes real effort now.
Have we gone full circle? From the invention of HTML to the rebirth of plain text with MD to the rediscovery of HTML anbrhe age of LLM?
The facts that this article needs to list the pros of HTML over MD, like inreraction, visual density, etc, is weird to me. Maybe the ahdience is not tech-savvy people but I read it as an unnecessary word salad.
It feels like a word salad that's been created to hit a word target because it's also LLM generated. Really not worth spending 5-10 minutes reading some "AI" output.
I had created my own chat tool that can render html responses directly in the chat interface, if needed. It is very handy for when I am needing rich(er) responses dealing for mathematical expressions. But it burns more tokens. It is useful, but I don’t need it for coding.
I've been doing something similar with scientific papers, you give it the paper and ask it to reproduce it as a nice html blog post and it often recreates all the diagrams and formats everything really nicely
This article is bringing up a point that I’ve thought about for a long time, even outside of the context of LLMs. It’s very surprising to me HTML never caught on more just as a common document for sharing information outside of a website/ web server. Just something to pass around like we do Word or Excel documents.
I don’t think the idea of generating HTML is a novelty. Anyone using an LLM to create a web app has done that. Any “novelty” here is the idea of favoring HTML rather than Markdown for internal docs like specs, design docs, etc. Maybe you were already doing that. I sure haven’t been. In hindsight it’s obvious that it would be useful in some circumstances. Previously, I’ve had a bias against HTML because it’s annoying to read in a text editor.
Or, you could do what I did, and process your markdown using Typst. The result is consistent, beautifully formatted documents, generated from your markdown, with mermaid diagrams.
I built a Markdown viewer https://markant.md to go with the flow rather than against it. I also cooked up a mew format, which basically bundles markdown and images into “Markbooks” https://markbooks.org. LLMs don’t even need an Agent Skill to understand the format, as it is just a zip with and index.md plus assets.
I’d love for people here to consider the idea.
I was running into issues with markdown and mermaid the other day and decided to tell Claude to use HTML, then realized that opened up the option of JS as well. Given we were trying to model state management in an existing typescript application, we could use ts-morph to correctly map out the call sites within different components, even use math to determine various factors of refactoring or relocating and so on.
It ended up being a large document but it was infinitely more useful than plain old markdown. I think I’ll do it more often now. Creating interactive specs is a really fascinating way to work. I’ve always verified my work in similar ways, but this was more… Verification-forward, I guess. And it took hours instead of days.
It’s actually really fun to be building and refactoring these days. No idea how long the fun will last, but I’m thoroughly enjoying it right now. I know it will make some people think I’m a hack, but I know that approach enabled me to do a faster, more targeted, ultimately better job of improving state management in the application. It’s not because Claude wrote the code (I still did quite a bit of it), but because Claude helped me establish the right work to do for the right reasons, using tools I couldn’t dream of throwing together 5 years ago.
I'm thinking of adding support for GitHub-flavored markdown (including things like Mermaid diagrams) in my agent wrapper tool and then adding something like a skill for Claude Code to always write GitHub-flavored markdown and use its features when communicating with me. Seems a lot better than general Markdown.
Though now I'm wondering: why not just add full HTML embedding support as well? I'm talking not just for specific deliverables, but for any of the agent's responses with the user.
Discovered this quite by accident. My cofounder and I were building a pdf editor and I’d analyzed 1,400 PDFs to see where our editor broke. I asked Claude to make an explainer of the process and it popped out an html with a working interactive pdf renderer.
ELI5: What is the context? Is this something to the effect of "Claude; please solve <> problem with with function <> in module <>. Instead of plain text, return your results as formatted HTML instead of plain text"?
Mario zechner did a talk on this where he states that he just gets everything from an agent as an html slide show. It looks better and you can page through it and there can be diagrams etc… Unfortunately I couldn’t find a link to the talk.
One thing I found quite good in earlier LLMs once they introduced the “Canvas” tool is to let them iterate on a thing (which they would do with React and friends) and then finally asking them to convert to a single file HTML+JS which they’d do admirably.
Which I use for things like reading podcasts (I’m not much of a listener - prefer to read) all single page HTML. I also make little sims for myself like: https://viz.roshangeorge.dev/baby-opportunity-cost/
LLMs are good at tag demarcation. I wonder if that’s why we use tags for in-band signaling (<reasoning>) etc. or whether they’re good for it because they trained them to be good for in-band signaling. Would be cool to hear from someone at a lab about this.
We’ve been doing this for a couple of months at work for internal memos and decision records, it’s really powerful. I love being able to drop in interactive visuals and more dynamic content. We have a Cloudflare R2-backed Document Store for managing them, and CLI for publishing, and I’m working on an MCP server for long-term discovery and context.
My team kept asking if they could leave comments though, so I built Annotent [1] to help with that, which is also MCP-backed.
> I find it difficult to read a markdown file of more than a hundred lines.
Apologies if I'm slightly demeaning here, but what? Markdown is largely plaintext. Unless the output is completely littered with markdown formatting (specifically, imo, tables and maybe links would be the hardest for a human to parse), is this not just saying "I have a difficult time reading large bodies of text" (which is of course fine - people prefer different ways ingesting information)
From reading the post, this seems like a "I personally prefer more visual, interactive elements in output" rather than "agents using markdown leads for less understandable output", and not at all what I would recommend for the average person to use unless said agent or interface or whatever had an extremely seamless way of displaying the HTML. If I had to open the agents response in a browser every time I wanted anything detailed I would lose my mind.
I've certainly had agents generate more rich visualizations such as through html, but I can't imagine using that as my default.
Interesting read. I totally agree but like he said it takes 2 to 4 times the time to generate one. With today’s prices for tokens it’s not affordable. But once models are getting cheaper and cheaper I am sure the industry will move to this.
I always liked the Idea of HTML as a document format. And i never understood why people prefered .docx or .txt. And where are the whysiwyg editors like dreamweaver? Really loved this stuff back in the day.
HTML+Tailwind is the only format where "looks roughly correct" and "is structurally correct" have the same probability. Every other output format needs a renderer to find out which one you got.
Yeah, I agree with this. I've been doing the same thing. Whenever I have to do a review, I ask the llm to create a dashboard. It's a godsend for reducing cognitive burden.
I think the reason stuff like this wasn't done earlier was due to fears about context pollution, but post training has gotten so good that you can do virtually anything in the context window and not have it affect the quality of output.
I've been struggling with markdown recently as I really want the claims it makes in documents to be programmatically verifiable e.g. citations, I want a simple script to check that each of the files and lines of code it references actually exist. Perhaps HTML can be used for this. It certainly has a better chance than markdown.
It's been confusing to me that so many people have treated markdown as the lingua franca for agent instructions when their training corpus must be dramatically biased to HTML instead of Mardown.
Markdown only makes sense for us meatbags becuse it's easy for us to edit and version control, but if you're sharing anything where the audience is an agent publicly, HTML must be just as interpretable.
Claude understands AsciiDoc just fine. His training data makes it so that most AsciiDoc documents he generates uses Markdown-like capabilities, but a gentle push in an appended system prompt (like a “feel free to use all of AsciiDoc’s features”) makes him create very nice documents to iterate on, in my opinion.
~html has more capabilities than markdown~ the real title
Weren’t llms specifically originally set to output and print markdown format since it is simpler and easier everyone to read? No different rendering/libraries/apis to worry about…
The author is completely missing the point of markdown.
"HTML can convey much richer information compared to markdown. It can of course do simple document structure like headers and formatting, but it can also represent all sorts of other information"
Yes exactly, and markdown is used when someone wants to just have raw text.
> I'm not sure what direction to take the onboarding screen.
I don't know, maybe, you could just pay people to use it, and see where the problems are, and then be informed by that?
We're using LLMs as if human contact and experience is hard to come by at a point in history when it's anything but. These goofy models are a complete and total dead end. They're actively in the way of better approaches.
I guess the author has never heard of Markdown editors with a preview feature, and doesn't know that the Claude Code VS Code plugin opens plans in preview mode.
I've felt the opposite. With MD being the preferred planning+documentation output for LLMs, the time of "hype" seems to be now. It seemed just a few years ago that devs hated writing properly formatted markdown.
Do we have local first html renderers that don’t complain about cors and wrong file addresses? I don’t want to spin up a server just to open an HTML file
Let’s be fair, about half of these things are provided by markdown as well:
> Tabular data using tables yes
> Illustrations with SVG yes
> Code snippets with script tags yes
> Workflows using SVG and HTML svgs yes
> Images using image tags yes
> Design data with CSS no
> Interactions using HTML elements with javascript + CSS no
> Spatial data using absolute positions and canvases no, although svgs help
That said, I can kinda get behind this ‘html, not markdown’ idea - as much as I like keeping things lean and mean, and markdown is ‘just enough’ semantics and style on top of plaintext… it can admittedly be more useful to recieve a more flavorful writeup from an LLM, if it’s going to be a piece that really requires you to engage with it, rather than just a quick read. Certainly a better fit for reports.
Another great use case is piping database output (e.g. psql) directly to HTML. HTML tables can be opened in a browser or directly in Excel. So all you need for a complete BI tool is a database and the command line.
Feels like markdown is token-efficient since its abbreviating HTML tags. Think about a large table. Also, HTML can't be especially rendered inside, say, Neovim, so now interacting with an LLM interface gravitates towards GUIs. Good for accessibility, I guess, there's that. Maybe the need for token efficiency will finally realize my dream of writing Slim[0], or some such, straight to the browser, full native compat.
> I find it difficult to read a markdown file of more than a hundred lines.
This is the sort of observation that should make you concerned about your own skills, rather than spur you to generate an article (longer than you can read easily) trying to give advice to other people.
The linked article could have been made using Markdown, and yet the author still chose to represent themselves this way; there's no point changing the tool when the problem is the user.
Now of course you could just reprompt your LLM to change the HTML - but when I already have a clear idea of what I want to say in my head, that’s just another roadblock in the way.
If this pattern becomes more common I suspect human/LLM co-creation will further dwindle in favour of just delegating voice, tone and content choice to the LLM. I was surprised not to see this concern in the blog post’s FAQ.
Currently working on a dumb little mobile game with isometric view and sound:
- told codex to write a tool that lets its place blocks in a prepared three.js document and have chromium dev tools take a screenshot. It made up a little JSON structure that defines blocks / colors and some other effects and it outputs 2.5d tilesets.
- told it to create a uv python script that would let it define sounds and music, and it made a yaml format that lets it create noises.
We completely shot past the svg pelican test. Codex has created both perfectly adequate prototype art of soldiers/knights/priests as well as a prototype soundtrack.
Even after React became popular, people are still manually typing out HTML elements, although they call it "JSX" instead, but in reality it's just HTML.
My first blog on the internet literally was a bunch of .html files, where my post "template" was the first post copy-pasted when you wanted to make a new post. Changing the design involved changing the same thing across all files.
Typing out <p> for every paragraph is annoying, for sure. But a converter that switches out \r\n\r\n for a new paragraph would be a reasonable middle ground IMO.
Also I often call out my colleagues if they try to put a table in markdown. Markdown is not built for tabular data in most professional settings (i.e., one or two table cell could easily take a whole line of markdown to express). A basic <table><tr><td style="background: red">some number</td></tr></table> goes a long way.
Both. We manually run HTML just fine back in the day.
'we have been authoring' is present perfect continuous. Going forwards, and for at least the last two 'decades', HTML blog posts can use CMSs.
I did not go to a front end high school.
Most frontend devs have no idea what any of that means. But then it seems everyone who can write 3 lines of code professionally refers to themselves as an ”engineer”.
I'm not and I've used it for years. With Markdown being a thing that has been less common, sure, but that's more of a zeitgeist thing.
No, we've been generating it with templates or authoring templates.
Authoring HTML by hand is a very early 2000s thing to do.
Yesterday. Astro components.
3 million people will have seen it as I type this. More next week.
Nope, it's a fixed, coded and shipped UI: the agent TUI.
I'd definitely call that on-demand, purpose-generated ephemeral UI.
overall i'm seeing a potential here for more human authoring, as you can really multiply the surface of your inputs with deterministic widgets rather than just delegating.
I’ve done something similar with Figma-like commenting and find myself pulling it into all kinds of personal projects.
"No bread? Let them eat cake!"
To me it feels like a worse experience, and they probably feel it too, but it makes sense from an optimization perspective. I've probably learned some shell tricks, but also going blind from watching Claude try dozens of variations of some multi-line chained and piped wall of bash nightmare, instead of just reading a few files.
Also: https://platform.claude.com/docs/en/agents-and-tools/tool-us...
It also gives tips on reducing context size when you run /context .
Presumably they are actually starting to feel the pinch on inference costs themselves with what still feels like a fairly generous max plan.
HTML made by Claude will, by default, be "sleek, modern", with colorful tables, cards, maybe Tailwind for styling. And, of course it will, if you wanted a barebones HTML, you would just have asked for markdown!
So the LLM decided to present some content using 4 cards, and you now want to add new itens. You can't just add new lines of text: you need to copy the whole HTML of the cards. But the LLM used different colors for each card, so now you have the first cards with varying colors and the new cards all the same color as the last card. Now you have to think about colors... etc etc
[0]: https://spec.commonmark.org/0.31.2/#html-blocks
2. One of the limiting factors of LLM is context. An html table takes up way more tokens than a markdown table. Especially if it's a WYSIWYG editor that has all kinds of css and <span> tags just for fun.
That might be the case today but there’s no reason for it to always be true. They are different representations of the same thing, an LLM could (arguably should!) store an internal representation that uses fewer tokens.
I think most of us live somewhere in the middle, using the right tool / output for the job.
The same could be said of any proprietary file format (which HTML is not!) Designers aren't concerned when they create inside a .psd or .ai file.
This feels very similar IMO.
It's arguable even more readable.
<b>bold</b> <i>italic</i> <u>underline</u>
I can never remember how many stars and ticks correspond to what in markdown.
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
2: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
3: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I know that it's 2026 and we've spent the last 15 years hiring people into our field who don't understand the hacker mindset but I didn't think that I'd find them here. They would have been ran out pretty quickly.
On a serious note some kind of rich Markdown would definitely help.
Arguing for html on a platform with less rich semantics than markdown is just ultimately funny
I guess it’s both
``` In a single index.html, no dependencies, sparse styling, create an app that <idea> ```
Even before AI, it's how I built small tools, and there's something lovely about being able to email my friends the tool, and tell them "If you want to make a change, toss it to your LLM!"
It is incredible how far you get with a single HTML-file, containing styles and JS, when building dashboards, small apps and other utilities that can interact with an API or otherwise fetch data from somwhere.
I just drop it on my personal ~ folder on the shared server at work and voilà, everyone can check it out and use it immediately!
its super convenient to be able to throw tools like this together and load them on a static site.
I absolutely hate the absolute rot these tools have caused to people’s brains.
We fired him.
He’s suing for wrongful termination and…homophobia.
People are completely cooked. These tools are too powerful and normies are too stupid to use them responsibily.
I worked with a vibe coded app at my last job (and since quit due to it) and because it was a nextjs SPA frontend with a separate API backend, the user facing urls didn't match the backend endpoints. Because AI uses react hooks for everything, state is in-memory, url-based routing isn't a thing unless you design for it. So links aren't free and thus we have no way for users to link to anything other than top-level entry points. LINKS! Especially for internal tools, everything being linkable is vital to collaboration and problem solving.
The need for uniform resource locations and verbs was so well thought out, 30 or 40 some odd years ago.
What i learned, by fire, is that nextjs works well with its nested routing and layout-to-hold-context magic. it's quite nifty but it's not free and not obvious, you have to design for it. I can't state enough that AI will ship a billion hooks, it loves hooks for self-contained state. My colleague made a good point that that style is a feature; it limits blast radius of N features all building on top of each other.
Yeah i had to move on from there.
Both of these tradeoffs set Anthropic up for success. Using HTML as our medium will increase token usage, and I'd bet they're investing in tools to mark up HTML (part of Claude Design) which will help improve lock-in. Either coincidence or brilliant strategy.
What’s harder than with markdown about precise feedback? You can have ids, sections and more with tags.
For the most parts you just write the regular Markdown headers and paragraphs, embed images, insert tables etc without the need for any HTML tags, making it readable in source form. And if you want to embed an SVG file for example, which the author of the article mentions as one use case, you just embed the SVG directly, and people can render the Markdown in their favorite viewer.
Let's say you're viewing a raw Markdown file in VS Code. You come onto an HTML tag, so you hit Cmd+Shift+V to open the preview and that's it.
Of course for full-fledged web pages with interactive buttons and fully customized styling and all of that, which the author shows in some examples, this is not feasible. But you can get very far when you have mostly text/images/tables and just want to add some extras here and there.
[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks
I talk to laypeople about their AI work -- I am constantly doing this, inserting myself into AI conversations on the street like an anthropologist when I encounter them...
HTML artifacts are the new browser URL bar, wherein some users have a mental model that that bar is actually Google.
Many people now talk about their "spreadsheet" or their "presentation" or "marketing tear sheet", or "slide show", "competitive analysis", "hvac system diagram" or whatever the thing they were working on and how lame it was working with ChatGPT or Claude Web.... and how miraculous Claude Code or OpenClaw is with creating these new documents...
I will ask them what the documents actually are and what the difference in experience was. It takes a lot of teasing (because they don't have the computing vocabulary yet) or having them show me, and it will always come down to that the artifact is HTML.
Their pleasant experience is that it is iterating on an HTML file (+CSS +images) living on a filesystem with high quality instant rendering; plus it can sprinkle JavaScript when it needs to. It might even revision control it without them knowing if there's a git system. [I suggest they checkpoint their work if they don't; revision control is the next stage of learning for the laypeople?]
Whereas the Web-embedded experiences are stabbing multiple times on a DOCX/PPTX/XLSX lingering in a context window and a vague notion of local storage (rendered as HTML anyway in a sidebar), etc. The HTML workflow also allows other media to be integrated much more easily.
So really all this presentation work is Vibe-Coding by the masses; they don't need to know about all the turtles underneath them. But if they are willing, they could crack it open and see and edit it; or easily hand it off to another agent.
Go figure that the system created for collaborative multimedia communication ends up being useful for the machine intelligence to help us communicate.
For example, user says "build a report with revenue and orders by month and show 100 most recent orders". The agent would write a spec that would get rendered by our frontend.
This runs fast, but we were drowning in feature requests for what the framework could render (e.g. "I don't want labels here", "I DO want labels there", "can this chart be a heatmap", etc.)
A few months ago, we let the agent just write HTML instead. It takes longer to generate, but you get unlimited customization.
There are a host of issues with the new approach (non-technical users debugging a monstrous app they created), but net-net our customers like it much better.
You don't have to host html files. You can just email it and any browser can view it.
I hadn't considered HTML and I'm definitely going to try this.
What I don't like is that all the resulting pages look the same. It's so easy to tell when a page is authored by Claude, and by now, I get the same “ugh another one” feeling as Dall-E generated images would give when they were completely overdone.
Maybe it's just be, but if not, maybe HTML generated outputs will also end up being dialed down from where they're at now.
But maybe not, since it's obviously a useful thing to be able to do. I wonder if there's a way out. To be able to introduce some natural entropy so not everything ends up looking the same. I guess not, since we're using machines whose natural mode of behavior is regression toward the mean. And maybe having it be harder to tell the author wouldn't even be desirable anyway.
The most important thing is that I can run static analysis on a structured format. This is important even for my spec documents. I can write data fields and have static analysis analyze it. For example, to confirm database fields match across various spec documents, etc.. The static analysis is also why you use JSON/XML instead of HTML, since you can now have your own custom schema.
Also don't use YAML, as that's far more unreliable. (If you chop a YAML file in half, it's still valid)
The real change is in generation side, and now the spec docs are LLM generated JSON based on other spec docs or human prompts. LLMs seem to write JSON better than Markdown or YAML, if you tell it to follow a schema.
Wondering if you are referring to adherence to required data in a schema when you say LLMs do better with json vs markdown, or something else? Or perhaps to tool calls and/or strict json output being more reliably formatted for clean extraction?
This is why I read long agent output either by using VIM and MacOS Quicklook (with a markdown extension for rendering) or paste output into MarkEdit (an editor with a preview pane; I think it’s cross platform?). Worst case, have an agent build you a simple local web page that interprets Markdown and renders it. Markdown was invented as a shorthand for web syntax[0]. That’s what it’s for! I bet you spend more tokens and time asking an agent to convert its native markdown to html than any of these.
0. https://daringfireball.net/projects/markdown/
Using bots has been insane and self-referrential.
Is it really unreasonably effective?
While it has been used in the context of HTML before, it's a bit of a "meme" as several papers used that phrase. Much like the "X is all you need" snowclone.
The HTML version dates from 2021 (https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...) when client side rendering and web apps were still their peak.
I also love how maybe 10% of the posts on here are like "some thing that has existed for 40+ years ,/:/; Claude/chatgpt". So much advertising at the expense of a dead internet it's ridiculous.
I even did a workshop with PartyKit cursors, dot voting, reflection comments, and an individual rating at the end.
Oh, and I can add super lightweight analytics so I know who actually reads my things or interacts with my prototypes. ^_^
I have been building a slightly different solution to the same problem. So far I’m pretty happy with the results and I have enough returning users that I think others are too (https://sdocs.dev/analytics).
I’ve built SmallDocs (https://sdocs.dev; Show HN: https://news.ycombinator.com/item?id=47777633).
SDocs is cli (`sdoc file.md`) -> instantly rendered Markdown file in the browser
When you install the cli it gives you the option to add a note in your base agent file (`~/.claude/CLAUDE.md`, etc.). This means every agent chat knows about SDocs and you can say “sdoc me the plan when you’re done with it” and the file will pop open instead of you having to find that terminal session to know it’s done.
Going browser first means you’re not required to install anything to get a great experience.
Despite being in the browser, the content of SDocs rendered Markdown files remain entirely local to you. SDoc urls contain your markdown document's content in compressed base64 in the url fragment (the bit after the `#`):
https://sdocs.dev/#md=GzcFAMT...(this is the contents of your document)...
The url fragment is never sent to the server (see https://developer.mozilla.org/en-US/docs/Web/URI/Reference/F...: "The fragment is not sent to the server when the URI is requested; it is processed by the client").
The sdocs.dev webapp is purely a client side decoding and rendering engine for the content stored in the url fragment.
This also means you can share your .md files privately by sharing the url.
To go a bit deeper towards the HTML side of things I’ve added tagged code blocks that the agent is given documentation on how to use. Eg ```chart or ```mermaid (for mermaid diagrams). These then become interactive elements on the page (mermaid is best example of this currently)
Markdown is a lightweight document format that leans toward easy writing, reading, and sharing. It is much simpler than HTML, easier to edit by hand, and works well for notes, documentation, drafts, README files, and content that may later be converted into HTML, PDF, or other formats.
That's why I'll continue to use Markdown for most of my notes and documentation, while I'll only use HTML for "public facing" documents.
I don't have any issue with markdown though - but terminal isn't a place to review it and leave useful feedback. Use one of the many tools that are popping up or build your own (like I did) to leave comments and iterate.
Markdown remains great because the other side is just going to use Claude to do their work anyway, and I can use Claude to verify their work meets my specifications.
I'm also not convinced that it solves meaningful problems :
> I've found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read, In my experience, LLMs are not concise when it comes to documentation, so using an easier file format to read because the text is too large sounds to me like solving the wrong problem
> Markdown files are fairly hard to share since most browsers do not render them natively well. Yes, but developers tools (IDE, Git forge) do. What most/some of them don't render natively IS HTML.
I tend to not actually read more than 100-lines of anything anymore. I've long referred to myself as "the Google generation": only being able to read the summaries in a search result. That, and the typical doomscrolling model of social media have affected my attention span. Reading anything more substantial takes real effort now.
Presumably you mean rendered HTML rather than the source documents?
The facts that this article needs to list the pros of HTML over MD, like inreraction, visual density, etc, is weird to me. Maybe the ahdience is not tech-savvy people but I read it as an unnecessary word salad.
It is just realization by author that HTML is also useful tool and MD lacks some stuff.
He didn’t write anything about “now we should stop using MD files”.
It is more like: “I see I can do cool stuff with HTML and found cases where it definitely is right tool for the job”.
2. It is not designed to work as a single file, and AFAIK there is no universal way to do it.
3. its not as easily editable as Word or Excel to most people.
4. There are alternatives such as PDF.
https://typst.app/universe/package/cmarker/
It ended up being a large document but it was infinitely more useful than plain old markdown. I think I’ll do it more often now. Creating interactive specs is a really fascinating way to work. I’ve always verified my work in similar ways, but this was more… Verification-forward, I guess. And it took hours instead of days.
It’s actually really fun to be building and refactoring these days. No idea how long the fun will last, but I’m thoroughly enjoying it right now. I know it will make some people think I’m a hack, but I know that approach enabled me to do a faster, more targeted, ultimately better job of improving state management in the application. It’s not because Claude wrote the code (I still did quite a bit of it), but because Claude helped me establish the right work to do for the right reasons, using tools I couldn’t dream of throwing together 5 years ago.
Though now I'm wondering: why not just add full HTML embedding support as well? I'm talking not just for specific deliverables, but for any of the agent's responses with the user.
These days, modern LLMs just get it right first time. I like these little tools for myself. E.g. some are like this one here: https://viz.roshangeorge.dev/voxtral-viewer/?t=jeffrey-epste...
Which I use for things like reading podcasts (I’m not much of a listener - prefer to read) all single page HTML. I also make little sims for myself like: https://viz.roshangeorge.dev/baby-opportunity-cost/
The single page format has some conveniences like you can iframe it in when you want like I do on this blog post to illustrate an idea: https://wiki.roshangeorge.dev/w/Blog/2025-02-14/Fertility_Ra...
LLMs are good at tag demarcation. I wonder if that’s why we use tags for in-band signaling (<reasoning>) etc. or whether they’re good for it because they trained them to be good for in-band signaling. Would be cool to hear from someone at a lab about this.
To review PRs in a little custom app is a very good idea. Who cares about 1.2x more tokens when clarity is squared?
Nice article!
My team kept asking if they could leave comments though, so I built Annotent [1] to help with that, which is also MCP-backed.
1. https://www.annotent.com/
Apologies if I'm slightly demeaning here, but what? Markdown is largely plaintext. Unless the output is completely littered with markdown formatting (specifically, imo, tables and maybe links would be the hardest for a human to parse), is this not just saying "I have a difficult time reading large bodies of text" (which is of course fine - people prefer different ways ingesting information)
From reading the post, this seems like a "I personally prefer more visual, interactive elements in output" rather than "agents using markdown leads for less understandable output", and not at all what I would recommend for the average person to use unless said agent or interface or whatever had an extremely seamless way of displaying the HTML. If I had to open the agents response in a browser every time I wanted anything detailed I would lose my mind.
I've certainly had agents generate more rich visualizations such as through html, but I can't imagine using that as my default.
Surely a html page could do the same but I would see that as the last step, to give to someone else.
What happens when my site changes style, I put it back through the LLM I guess and get some bonus hallucinated content.
In html I don’t like the extra ornaments (borders, bullets, badges, etc).
To be fair, I usually ask for concise and specific information, where this kind of response style would be a distraction.
I think the reason stuff like this wasn't done earlier was due to fears about context pollution, but post training has gotten so good that you can do virtually anything in the context window and not have it affect the quality of output.
Markdown only makes sense for us meatbags becuse it's easy for us to edit and version control, but if you're sharing anything where the audience is an agent publicly, HTML must be just as interpretable.
- work text / human or mixed input: markdown, plain text
- fancy looks / interaction: html
avoid creating problems, try solving them instead. and don't start futile smoke campaigns.
Using Claude Code: The Unreasonable Effectiveness of HTML
https://news.ycombinator.com/item?id=48069859
Sure enough, this is full of listicles and of a length no human would write for an idea as simple as "Use HTML instead of Markdown."
Classical overly confident llm bullshitting.
Weren’t llms specifically originally set to output and print markdown format since it is simpler and easier everyone to read? No different rendering/libraries/apis to worry about…
It's a very beautiful language, it's quite simple, if you like simple.
"HTML can convey much richer information compared to markdown. It can of course do simple document structure like headers and formatting, but it can also represent all sorts of other information"
Yes exactly, and markdown is used when someone wants to just have raw text.
I don't know, maybe, you could just pay people to use it, and see where the problems are, and then be informed by that?
We're using LLMs as if human contact and experience is hard to come by at a point in history when it's anything but. These goofy models are a complete and total dead end. They're actively in the way of better approaches.
If that's the goal, use haml and sass
You get human readability + the power of html
If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.
In turn, chatbots pump up markdown by making it the default output format.
What in the world.
Because it can have little components with jsx (html like) bits, it’s fairly human readable and editable.
Components give it semantic compression and the high level scan makes it easier to understand and change.
> Tabular data using tables yes > Illustrations with SVG yes > Code snippets with script tags yes > Workflows using SVG and HTML svgs yes > Images using image tags yes > Design data with CSS no > Interactions using HTML elements with javascript + CSS no > Spatial data using absolute positions and canvases no, although svgs help
That said, I can kinda get behind this ‘html, not markdown’ idea - as much as I like keeping things lean and mean, and markdown is ‘just enough’ semantics and style on top of plaintext… it can admittedly be more useful to recieve a more flavorful writeup from an LLM, if it’s going to be a piece that really requires you to engage with it, rather than just a quick read. Certainly a better fit for reports.
It's the best markdown editor.
So when I need to check any past reference I just open my folder or files.
Html it's so ugly.
I wish IA products add a save al chat button, to avoid copy and paste every response.
[0]https://slim-template.github.io/
This is the sort of observation that should make you concerned about your own skills, rather than spur you to generate an article (longer than you can read easily) trying to give advice to other people.
The linked article could have been made using Markdown, and yet the author still chose to represent themselves this way; there's no point changing the tool when the problem is the user.