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.
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).
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.
> PS: Really cool static site generators that shoot for simplicity don't require you to create extra template files written in a new, made-up template language. When you want to create a new post, you give it (a) the static files from your existing site and (b) the markdown for your new post. The "templating" engine inspects your existing posts (incl. e.g. class attributes) and then copies the same document structure into a new file, except with the right stuff (timestamp, title and heading, post content...) substituted in to the places where it's supposed to go.
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.
A lot of editors will auto add the ending tag, and auto-update the ending tag if you rewrite the start tag. I think it's gotten pretty darn easy to use HTML er I mean XML ;)
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.
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)
Maybe not in your corner of the internet, but businesses used server side includes (SSI) for that, not iframes.
You add “include” tags to your HTML file and your web server like nginx or varnish would replace it with the fragment at runtime.
<!--#include virtual="../footer.html" -->
I saw this was quite popular for big publishing houses with millions of articles still relatively recently 10 years ago. They would only write the HTML body of a new article and the other fragments would be included by the web server.
Very cheap, stable, and very big changes across the whole website could be done instantly since cache invalidation is trivial (the web server knows all modified dates of all fragments).
Also, no additional CDN or caching needed. Later, with CDNs there was even a variant where these fragments were hosted at the edge (ESI).
10 years ago. I bet you can’t name a single production site writing HTML files without any build tools at all. Just raw dogging using notepad directly on the server.
That is the point. No one writes HTML without any abstractions anymore. You use a framework or a build tool. Because just editing pure html files is a pain in the ass. Probably haven’t done that since 2010.
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.
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.
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.
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.
I can edit html. Also, I don't bother with html editing. If it's a doc that needs editing, I just tell Claude to format it for ease of editing and then I just go through and type whatever crap I want to say. Then I ask Claude to clean it up.
BUT, I only do this as an easy way of referencing specific ideas and text in notes to instruct Claude. I say, "I have added notes. Read them and adjust the doc accordingly." Or, "Read the notes I added. Turn them into html."
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.
Well said. It is so much better for when the human can see what the LLM has changed and iterate on it with the LLM, making their own changes. Markdown is better for that.
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.
It's usually faster though, so you get to spend more time on thinking.
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.
I started using Thariq’s approach yesterday and it works very well. One thing I noticed is that I’m no longer wary of reading long and complex spec documents. Opus does a great job with web design and uses a combination of clean, modern styling and interactive elements that reduces my cognitive load and improves my ability to understand the details of what it is planning to build.
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.
Yeah. We could even have some kind of plugin or SKILLS.md file that helps convert from this kind of structured prompt into another even more deterministic, predictable output.
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!
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.
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.
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.
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.
I have to draw a very sharp line in generating these kinds of tools, I treat them as single use throwaway things and do my best to never have anyone besides myself even see the tools themselves (e.g. reviewing some calculation results).
Else I fully expect to get saddled with turning a temporary thing for a very narrow problem into something production ready.
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.
I think one of the greatest issues of the last generation of developers is that they never learned about links. They think `div onclick` is equivalent. It pains me that `a` makes up 50% of the HTML acronym but devs don't use it.
I bet that LLMs will actually help generate real links going forward.
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.
Second this. If the point of HTML is to have a lot more visuals, then it also means that you will need quite a lot of CSS and JS to make it so. That must mean more tokens.
But, on the other hand. That could be a trade worth taking. Co-working with claude to create a pretty big plan for a rewrite (i know, i know), and showing it to the team is a lot easier in HTML compared to md.
For me, this is just another tool in the toolbox. Doesn't need to be black and white. html or md. Can be both.
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.
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.
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.
> 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.
"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.
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.
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.
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.
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.
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.
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.
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.
Visual explainers certainly come in hand. You need to have both the extra time and cost of tokens accounted for when you ask for these. As well as maintainability - you lose things like vcs/diffs over plans that are much more readable as markdown.
The more interactivity on the surface, the better. Esp if they create feedback loops with the agent. Simple annotations to start.
Markdown still goes a long way. I’ve effectively been enriching plan rendering in Plannotator. Now supporting GFM, custom svgs, etc.
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
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.
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.
This makes me think of a thing I have been planning to do. Maybe one of you will do it and tell me some cool refinements.
I run a web server on my Mac. Consequently, I have an HTTP process available. I keep intending to make an endpoint that Claude can use. I would tell it to make a document for commenting (or put a list of options or whatever) and post it to, I guess, the planning folder we are working in. The endpoint would know how to do this because I wrote it.
When it gets there, I would, I wanted to keep it, tell Claude to integrate the results into the file as static HTML. Or, if I don't care about that, just read it and do whatever I said and leave it disconnected.. The goal isn't to make a website.
This supports interactive conversations with Claude via HTML.
By "planning", I actually meant "thought of one time". So, I did it.
The endpoint verifies that the destination specified by the POST is in my project folder. If it points at an existing file, it creates a version. It does not overwrite.
I added a CLI, watchFile, that blocks Claude until the file shows up.
And made a skill that tells Claude to respond nicely to "Make an interactive document that...".
Claude Code has basically made software functionality, "Your wishes come true".
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.
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.
#1 and #3 are big ones for sure and related. That has to do with most people aren’t developers & don’t code. I get that’s the biggest reason it’s not common. I’m just saying even among developers, I would think it would be a little more common. You can obviously do so much more with it than PDF, it opens a lot of interesting options. I don’t think #2 is a concern at all. The “universal” way to do it is double clicking the file :) every computer in the world will open an HTML document in the default browser (not the case on mobile though).
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.
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."
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.
Seems to me that html is a nice output format for a lot of use cases. However, since AI is getting pricier, markdown is a more sensible default. I prefer something that's natively human readable 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.
In an alternate universe where HTML was the native input-output format of LLMs, we'd be talking about the unreasonable effectiveness of Markdown in sparing tokens for reasoning.
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.
If I were to reach for HTML to consume LLM markdown files, and that is an interesting idea, I'd want to use a build system and define my own design system for my specs.
I'd still want the LLM using markdown, its a much better fit than HTML for loading context. I'd want to consume it in a nicer visual representation. It writes something like `<ds-table>` and it builds to a styled HTML table for me.
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.
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.
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 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 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.
Mmm....His position of "stopped using markdown altogether for almost everything" strikes me as overstated and selfpromotional. The 2-4x higher generation cost is non-trivial when you're operating under rate limits, and Git versioning friction is a real problem for your work in big and complex repos. I use the rule "HTML for deliverables, Markdown for infrastructure" and it seems more defensible than HTML maximalism.
Or we could just use our brains, eyes, fingers, and programming languages. Which all clearly work just fine, despite what the AI promoting hypesters would have you believe. Plain text is fine. Markdown is fine. All of it is OK. Don't give in to FOMU and peer pressure, kids. Conformity is not required.
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.
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.
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.
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 have tried that and it works well for me.
I can also recommend using a Visual Studio plugin called Markco that lets you comment a markdown file. It’s resembles words commenting feature. I use it to comment LLM generated markdown.
Increases the blast radius needlessly, and can ultimately introduce bugs in our docs too. Yikes! But yea I get it, it's prettier. What they're actually advocating for is a version of markdown with prettification.
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).
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.
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"?
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'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 is why I built https://saasufy.com/ - There are 23 generic HTML components which can be assembled to provide a flexible way to render any kind of data and flexible form elements to flexibly update the data (or show errors when validation fails). It's fully declarative so there is very little room for errors. I find that this helps a lot when working with LLMs. There are no complex bugs. The only kinds of bugs you might encounter are syntax or UX related. No weird race conditions or complex technical issues.
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.
~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…
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.
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.
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.
This reminds me of some article on HN a while back that XML makes Claude more effective... I guess it makes even more sense to ask for HTML back, since it is XML.
> 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.
Generating markdown is faster so unlike our friend here, I still do use it for straightforward things.
BUT, in general, I tell Claude, "I think we should starting a project planning folder for this. Put (the stuff we just talked about) into an html doc. while you're at it, make an index.html and put relative link to the page with a little explanation of what we are up to."
Or, just yesterday Claude and I worked out the design for a substantial AI enabled database tool. I had it make an explanatory doc for my team. It was a single html file that navigated through forty scenes that demonstrated it. MAGIC.
If you aren't doing your collaboration with Claude in html, listen to this guy. Your life and work will be better.
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.
The examples that are asking for UX sketches, design and animations utterly irrelevant -- of course HTML is going to win over plaintext when the requested artifact is a page in a webapp.
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
> 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.
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.
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.
We need a Rich Text Standard akin to Unicode. It's truly absurd that we can universally read and write emojis with variable skin color across all platforms, but I can't send bold or italic text.
If can use emojis in my terminal text editor - even in a Markdown document itself - why the hell can't I bold or italicize?? We desperately need to fix this insanity.
Markdown by itself is: Headings, bold, italic, lists, blockquote, code, horizontal rule, link and image. That's it. Everything else is some sort of custom addition like tables.
Surely in 2026 we can figure out how to make this a universal standard.
I truly despise Markdown. I'd say about 25% of my posts on HN is me ranting about how much I hate it. This has mostly just lowered my karma, but that's OK. I'm not wrong, it sucks.
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?
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.
that’s exactly the core value proposition of the tool I have been working on : https://github.com/livetemplate/tinkerdown
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.
LLMs do fantastic when you do the architecting for them. Don't let them make system decisions, and you'll have a great time.
This sounds very intriguing have you written more about it anywhere we can read?
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.
[flagged]
Typical HN condescending bitterness at it again. Thank you for this very constructive feedback.
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.
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).
I did this on an airplane once because I didn't have Internet and I've never felt more like a real hacker since
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.
> PS: Really cool static site generators that shoot for simplicity don't require you to create extra template files written in a new, made-up template language. When you want to create a new post, you give it (a) the static files from your existing site and (b) the markdown for your new post. The "templating" engine inspects your existing posts (incl. e.g. class attributes) and then copies the same document structure into a new file, except with the right stuff (timestamp, title and heading, post content...) substituted in to the places where it's supposed to go.
<https://news.ycombinator.com/item?id=30961588>
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.
>Templated though, not manually writing it out for every blog post say.
Both. We manually run HTML just fine back in the day.
A lot of editors will auto add the ending tag, and auto-update the ending tag if you rewrite the start tag. I think it's gotten pretty darn easy to use HTML er I mean XML ;)
[flagged]
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.
That incredibly condescending phrase should be banned from HN.
It doesn't need to be explicitly imo, it falls short of many of the commenting guidelines.
It fits perfectly.
You have been authoring HTML by hand for decades. Not every SWE is a FE dev.
People have been authoring html by hand for a long time before the specialization to Frontend dev even existed...
I learned HTML 20+ years ago in high school.
I did not go to a front end high school.
Your high school taught you a front-end markup format. I'm sure it seemed like a good idea to someone at the time.
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.
Java engineers write lots of HTML in java docs:)
Yes so far, but it‘s switching heavily towards Markdown.
Most front end devs can’t get HTML right either.
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.
I suspect this unintentionally satisfies my conclusion.
Only if you're willfully ignorant of the wider discussion.
Obviously. Me having technical knowledge you appear to not have on the discussion at hand makes me ignorant of the discussion at hand.
HTML was invented for physicists to be able to write papers. It's not something that's beyond anyone without frontend dev experience.
CSS, on the other hand...
You don't have to be a FE dev (which is largely a junior/mid-level position anno 2026) to write HTML.
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.
Why not just use XML at this point? It has "stricter typing" and can make the spec better.
>We have been authoring HTML by hand for decades with ease
No, we've been generating it with templates or authoring templates.
Authoring HTML by hand is a very early 2000s thing to do.
After you a FE webdev that doesn't regularly author HTML by hand?
Can’t answer the person who responded to you but:
Yesterday. Astro components.
3 million people will have seen it as I type this. More next week.
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)
Maybe not in your corner of the internet, but businesses used server side includes (SSI) for that, not iframes.
You add “include” tags to your HTML file and your web server like nginx or varnish would replace it with the fragment at runtime.
I saw this was quite popular for big publishing houses with millions of articles still relatively recently 10 years ago. They would only write the HTML body of a new article and the other fragments would be included by the web server.Very cheap, stable, and very big changes across the whole website could be done instantly since cache invalidation is trivial (the web server knows all modified dates of all fragments).
Also, no additional CDN or caching needed. Later, with CDNs there was even a variant where these fragments were hosted at the edge (ESI).
10 years ago. I bet you can’t name a single production site writing HTML files without any build tools at all. Just raw dogging using notepad directly on the server.
LLMs aside, when was the last time you wrote React/JSX and didn't write a subset of HTML by hand in them?
That is the point. No one writes HTML without any abstractions anymore. You use a framework or a build tool. Because just editing pure html files is a pain in the ass. Probably haven’t done that since 2010.
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.
HTML is plain text based at the same level as any programming language I can think of.
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.
>with on-demand, purpose-generated ephemeral UI
Nope, it's a fixed, coded and shipped UI: the agent TUI.
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.
MS Word uses HTML under the hood, right? (Or some SGML at least.)
It was less a comment about the format and more a comment about the application used to do the editing.
There's a visual editor for Windows Forms apps that is well thought of.
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.
Yes that’s the case. And as Anthropic staff, author has an incentive to promote workflows that require an agent to interact with text documents.
I've yet to see Anthropic promote any sort of token optimization strategy to its users - they always assume we all have infinite inference.
"No bread? Let them eat cake!"
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.
Valid points, but they address a totally different matter than the one I pointed out.
They give you multiple models and knobs to control effort? What are you looking for?
I completely agree but hadn’t found a way to put it to words. It could be the model too trained on optimized strategies
At the same time it has gotten WAY better at parsing giant documents due to this.
Nah they do. They push Sonnet pretty hard rather than Opus for most tasks.
Also: https://platform.claude.com/docs/en/agents-and-tools/tool-us...
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.
HTML is by far simpler than Markdown.
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".
Markdown covers only a very small subset of HTML. By definition you are wrong.
Is HTML really that much worse to edit than MD?
Yes, I do think it is.
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
Markdown is essentially just syntactic sugar for HTML[0], so yes it was made to be easier to edit than HTML.
[0]: https://spec.commonmark.org/0.31.2/#html-blocks
It’s a bit easier yeah but there’s not much in it.
Let’s see…
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.
[dead]
HTML is super human readable if you stick to a subset of it.
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.
Oddly enoght those are now called the "bring attention to" element [1], the "idiomatic text" lement [2], and the "unarticulated annotation" element.
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/...
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.
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.
I can edit html. Also, I don't bother with html editing. If it's a doc that needs editing, I just tell Claude to format it for ease of editing and then I just go through and type whatever crap I want to say. Then I ask Claude to clean it up.
BUT, I only do this as an easy way of referencing specific ideas and text in notes to instruct Claude. I say, "I have added notes. Read them and adjust the doc accordingly." Or, "Read the notes I added. Turn them into html."
It's an insanely productive pattern.
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.
Well said. It is so much better for when the human can see what the LLM has changed and iterate on it with the LLM, making their own changes. Markdown is better for that.
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.
It's usually faster though, so you get to spend more time on thinking.
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.
If it’s a collaborative doc, you could make a pretty quick WYSISWYG or markdown editor for inline editing.
I’ve done something similar with Figma-like commenting and find myself pulling it into all kinds of personal projects.
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.
It highlights the extremes the anthropic team adopts LLMs in their workflow.
I think most of us live somewhere in the middle, using the right tool / output for the job.
Makes sense for actual devs. For non-devs who'd just edit docs via LLMs anyway (myself), I can't imagine it'd introduce much friction.
Yes, and you can always embed HTML in Markdown for <script>, <style>, <svg>, and other tags that cannot be coded in Markdown.
I started using Thariq’s approach yesterday and it works very well. One thing I noticed is that I’m no longer wary of reading long and complex spec documents. Opus does a great job with web design and uses a combination of clean, modern styling and interactive elements that reduces my cognitive load and improves my ability to understand the details of what it is planning to build.
Not sure what you mean. HTML is designed to be authored and edited by humans
You could just do `<fixme>my two cents<fixme/>`
HTML is trivial to edit by hand in Notepad or nano.
Time was everyone took pride in writing HTML in Notepad.
Why is it a problem if co-authoring the document is a touch more difficult?
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.
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.
Next up after HTML: someone rediscovers programming languages and comes up with the idea to use them to prompt agents.
Maybe with some kind of plugin for more deterministic output from those languages?
Yeah. We could even have some kind of plugin or SKILLS.md file that helps convert from this kind of structured prompt into another even more deterministic, predictable output.
I have heard people say prompting via JSON is much more deterministic lol
[flagged]
[dead]
We should ask the agents to output TeX instead. /s
On a serious note some kind of rich Markdown would definitely help.
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!"
This is the way!
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!
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.
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.
[flagged]
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.
A while back I figured out this trick and used it to crank out a bunch of calculators for analog electronics: https://cofree.coffee/~solomon/calculators/
its super convenient to be able to throw tools like this together and load them on a static site.
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.
We had a CSM vibe code a dashboard and put it on publically avaiable unauthenticated Firebase. Leaked a bunch of customer PII.
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 have to draw a very sharp line in generating these kinds of tools, I treat them as single use throwaway things and do my best to never have anyone besides myself even see the tools themselves (e.g. reviewing some calculation results).
Else I fully expect to get saddled with turning a temporary thing for a very narrow problem into something production ready.
This is also what Claude does on web when you ask for html (it creates it as an artifact), so the model is probably really well trained for it.
I recommend allowing AI to use TailwindCSS and Alpine in the context, as this would generate great lightweight dynamic web pages.
I agree! I get much better results when I give LLMs some light architectural constraints such as to use tailwind and alpine.
I don't know why my comment was down voted. Can someone tell me why?
because the original prompt specifically said no dependencies, and now you've introduced two dependencies.
The irony of this being a Twitter post with pictures of html rendering instead of an interactive html page is not lost on me.
Arguing for html on a platform with less rich semantics than markdown is just ultimately funny
https://thariqs.github.io/html-effectiveness/
I guess it’s both
Don't get me started on the "templating" for Twitter Articles, it doesn't even support markdown...
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.
I think one of the greatest issues of the last generation of developers is that they never learned about links. They think `div onclick` is equivalent. It pains me that `a` makes up 50% of the HTML acronym but devs don't use it.
I bet that LLMs will actually help generate real links going forward.
Wait so when u navigate to a different page/tab the url wouldn’t update?
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.
Yeah i had to move on from there.
[flagged]
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.
Also there’s a wider code execution vulnerability for HTML. Plaintext would never hurt you.
It’s a little less efficient but there’s not a huge difference unless lots of it is structural or visual.
What’s harder than with markdown about precise feedback? You can have ids, sections and more with tags.
Second this. If the point of HTML is to have a lot more visuals, then it also means that you will need quite a lot of CSS and JS to make it so. That must mean more tokens.
But, on the other hand. That could be a trade worth taking. Co-working with claude to create a pretty big plan for a rewrite (i know, i know), and showing it to the team is a lot easier in HTML compared to md.
For me, this is just another tool in the toolbox. Doesn't need to be black and white. html or md. Can be both.
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.
[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks
You should never have to preview a markdown document, in my opinion. At that point, just make an HTML document.
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.
orgdown is better than markdown which is better than markup, except the text ain't hyper. i've been working on this since feb & have reached xanadu
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 think MDX is the perfect middle ground. I'm gonna start using it instead of plain Markdown thanks to this comment. Thanks!!
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.
> 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.
0. https://daringfireball.net/projects/markdown/
While I agree it probably uses more tokens, the author works for Anthropic and has probably never paid for a token
If you want to be vibe all the way, why don't you ask a bot to summarize the long output?
Using bots has been insane and self-referrential.
Which Quick Look extension? I've been looking for a good one.
https://github.com/sindresorhus/quick-look-plugins lists some good ones. (I still use Peek.)
"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.
Or just ask Claude to find a connector to share html
Heck, these days the email is the HTML
they dont exec js
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.
How do you protect against prompt injection in this case?
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. ^_^
Blog post plz
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).
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)
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.
Interesting point. If you have any ideas how SmallDocs could be both let me know…!
Obsidian does a great job of providing WYSIWYG rendering of editable markdown. HTH.
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).
Is it really unreasonably effective?
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.
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 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.
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 don’t think so.
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”.
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.
Are you using that cmarker commonmark Typst package? Is it good?
https://typst.app/universe/package/cmarker/
No, I built my own pipeline using pandoc+Typst. Works great.
We've circled back to TimBL's original vision of hypertext documents with links. It's beautiful.
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.
>But HTML documents are much easier to read, [than markdown]
Presumably you mean rendered HTML rather than the source documents?
Writing and editing html by hand is very simple, it can be just a few basic tags.
Many of us had CC routinely generate HTML ever since it became available. Surprised that it's presented as some kind of novelty.
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.
Yes, I meant internal docs, in line with the topic at hand.
I’ve done a lot of exploration here.
Visual explainers certainly come in hand. You need to have both the extra time and cost of tokens accounted for when you ask for these. As well as maintainability - you lose things like vcs/diffs over plans that are much more readable as markdown.
The more interactivity on the surface, the better. Esp if they create feedback loops with the agent. Simple annotations to start.
Markdown still goes a long way. I’ve effectively been enriching plan rendering in Plannotator. Now supporting GFM, custom svgs, etc.
https://github.com/backnotprop/plannotator
For fun, I also enabled annotations on top of these type of svgs, see here https://x.com/plannotator/status/2052851731998941380?s=46
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
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.
Md and plotly is all you need. The only thing that is truly missing is some sort of Markdown-based forms
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.
There’s nothing unreasonable about HTML being effective at what it was designed for.
This makes me think of a thing I have been planning to do. Maybe one of you will do it and tell me some cool refinements.
I run a web server on my Mac. Consequently, I have an HTTP process available. I keep intending to make an endpoint that Claude can use. I would tell it to make a document for commenting (or put a list of options or whatever) and post it to, I guess, the planning folder we are working in. The endpoint would know how to do this because I wrote it.
When it gets there, I would, I wanted to keep it, tell Claude to integrate the results into the file as static HTML. Or, if I don't care about that, just read it and do whatever I said and leave it disconnected.. The goal isn't to make a website.
This supports interactive conversations with Claude via HTML.
By "planning", I actually meant "thought of one time". So, I did it.
The endpoint verifies that the destination specified by the POST is in my project folder. If it points at an existing file, it creates a version. It does not overwrite.
I added a CLI, watchFile, that blocks Claude until the file shows up.
And made a skill that tells Claude to respond nicely to "Make an interactive document that...".
Claude Code has basically made software functionality, "Your wishes come true".
Another upgrade. Now the skill knows to create a containing folder with index.html if none exists and then to link any new docs to it.
Now I have a favorite in my bookmark bar for each project I am working on that shows me the docs.
I'm so happy.
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.
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.
1. People do not know its possible
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.
#1 and #3 are big ones for sure and related. That has to do with most people aren’t developers & don’t code. I get that’s the biggest reason it’s not common. I’m just saying even among developers, I would think it would be a little more common. You can obviously do so much more with it than PDF, it opens a lot of interesting options. I don’t think #2 is a concern at all. The “universal” way to do it is double clicking the file :) every computer in the world will open an HTML document in the default browser (not the case on mobile though).
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.
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."
looks like a disproportionally huge wall of text (on twitter no less) for a non-issue. just choose your tools sensibly:
- 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.
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.
Seems to me that html is a nice output format for a lot of use cases. However, since AI is getting pricier, markdown is a more sensible default. I prefer something that's natively human readable 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.
In an alternate universe where HTML was the native input-output format of LLMs, we'd be talking about the unreasonable effectiveness of Markdown in sparing tokens for reasoning.
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.
If I were to reach for HTML to consume LLM markdown files, and that is an interesting idea, I'd want to use a build system and define my own design system for my specs.
I'd still want the LLM using markdown, its a much better fit than HTML for loading context. I'd want to consume it in a nicer visual representation. It writes something like `<ds-table>` and it builds to a styled HTML table for me.
I’ve also realized CC is exceptional on html, creating local apps for reviewing output, dashboards sourced from DuckDB, etc.
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!
Quarkdown is a partial and interesting alternative : https://github.com/iamgio/quarkdown
This one is interesting and has potential, for me. I never liked HTML/XML/etc and Markdown might be a little _too_ minimal.
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.
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.
1. https://www.annotent.com/
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.
[0]https://slim-template.github.io/
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 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.
Markdown is not necessarily about presentation. It’s about structure that carries information.
Surely a html page could do the same but I would see that as the last step, to give to someone else.
Mmm....His position of "stopped using markdown altogether for almost everything" strikes me as overstated and selfpromotional. The 2-4x higher generation cost is non-trivial when you're operating under rate limits, and Git versioning friction is a real problem for your work in big and complex repos. I use the rule "HTML for deliverables, Markdown for infrastructure" and it seems more defensible than HTML maximalism.
Or we could just use our brains, eyes, fingers, and programming languages. Which all clearly work just fine, despite what the AI promoting hypesters would have you believe. Plain text is fine. Markdown is fine. All of it is OK. Don't give in to FOMU and peer pressure, kids. Conformity is not required.
This is HTML very much as an output format though.
What happens when my site changes style, I put it back through the LLM I guess and get some bonus hallucinated content.
(Edit) nvm, the usual Xcancel (https://xcancel.com/trq212/status/2052809885763747935) just links to an article (http://x.com/i/article/2052796100608974848)
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.
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.
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.
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 have tried that and it works well for me. I can also recommend using a Visual Studio plugin called Markco that lets you comment a markdown file. It’s resembles words commenting feature. I use it to comment LLM generated markdown.
Increases the blast radius needlessly, and can ultimately introduce bugs in our docs too. Yikes! But yea I get it, it's prettier. What they're actually advocating for is a version of markdown with prettification.
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).
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.
Aren’t HTML blocks valid Markdown? Why not just put the stuff you need in HTML and keep the rest simple?
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"?
One layer above html is having Claude produce .jsx or .tsx files.
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.
To each their own but my immediate reaction is that I find text and markdown clearer.
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.
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'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
I am working on https://github.com/livetemplate/tinkerdown to leverage the the two effective outputs of LLMs : html and markdown . Still WIP
I use obsidian MD editor to save important chats I made on Claude or Gemini.
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.
This is why I built https://saasufy.com/ - There are 23 generic HTML components which can be assembled to provide a flexible way to render any kind of data and flexible form elements to flexibly update the data (or show errors when validation fails). It's fully declarative so there is very little room for errors. I find that this helps a lot when working with LLMs. There are no complex bugs. The only kinds of bugs you might encounter are syntax or UX related. No weird race conditions or complex technical issues.
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.
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.
Whenever I read these pro-AI software engineering articles, I skim them first, looking for AI tells.
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."
~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…
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.
HTML and hand written CSS mind as well be legally binding.
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.
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.
This reminds me of some article on HN a while back that XML makes Claude more effective... I guess it makes even more sense to ask for HTML back, since it is XML.
Why does everyone feel the need to reinvent the wheel every few days?
This really is the perfect time for something like MDX to shine.
Each one trades a document you'd skim for one you'd actually read — emdash — or does it really? That entirely depends on your preference of course.
Classical overly confident llm bullshitting.
I use Claude code daily to run and manage various experiments, and then I ask for html reports. Simply put, it’s a joy to use.
> 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.
I'm starting to think HN isn't what it used to be when rubbish like this hits the front page.
I think the problem is that plain text is very easy to read and markdown is essentially plain text.
I posted this same Twitter article about 5-6 hours before this post was made and got only a couple of likes and zero comments. What gives?
Using Claude Code: The Unreasonable Effectiveness of HTML
https://news.ycombinator.com/item?id=48069859
Bad luck but doesn't really matter, does it?
I'm just curious. Also not sure what's the rule regarding submitting dupes.
> Joyful
If that's the goal, use haml and sass
You get human readability + the power of html
YES YES YES and MORE YES
Generating markdown is faster so unlike our friend here, I still do use it for straightforward things.
BUT, in general, I tell Claude, "I think we should starting a project planning folder for this. Put (the stuff we just talked about) into an html doc. while you're at it, make an index.html and put relative link to the page with a little explanation of what we are up to."
Or, just yesterday Claude and I worked out the design for a substantial AI enabled database tool. I had it make an explanatory doc for my team. It was a single html file that navigated through forty scenes that demonstrated it. MAGIC.
If you aren't doing your collaboration with Claude in html, listen to this guy. Your life and work will be better.
I don't see a case for effectiveness on both examples?
The solution is latex
Thanks for this.
It's a very beautiful language, it's quite simple, if you like simple.
hey Siri, make some web pages that extol the virtues of getting my favourite AI to use HTML instead of MD.
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.
Are you just trying to pretend that Markdown is as rich as HTML and that all the use cases that they described are possible with Markdown?
Technically, yes. Markdown was always intended to be used for creating HTML and thus allows you to use HTML inline (with some minor caveats, see: https://daringfireball.net/projects/markdown/syntax#html).
If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.
Markdown was a hype in late 2010s that has cooled down due to chatbots.
In turn, chatbots pump up markdown by making it the default output format.
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.
> has cooled down due to chatbots.
What in the world.
The examples that are asking for UX sketches, design and animations utterly irrelevant -- of course HTML is going to win over plaintext when the requested artifact is a page in a webapp.
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
The unreasonable effectiveness of HtmlX.
After Thariq's infamous "our react TUI is actually a game engine" tweet i can't help but smirk at these headlines and wonder if it's satire or not.
> 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.
Is this another way of saying: HTML will increase revenue by increasing token usage, so let's advocate for it
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.
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.
We need a Rich Text Standard akin to Unicode. It's truly absurd that we can universally read and write emojis with variable skin color across all platforms, but I can't send bold or italic text.
If can use emojis in my terminal text editor - even in a Markdown document itself - why the hell can't I bold or italicize?? We desperately need to fix this insanity.
Markdown by itself is: Headings, bold, italic, lists, blockquote, code, horizontal rule, link and image. That's it. Everything else is some sort of custom addition like tables.
Surely in 2026 we can figure out how to make this a universal standard.
I truly despise Markdown. I'd say about 25% of my posts on HN is me ranting about how much I hate it. This has mostly just lowered my karma, but that's OK. I'm not wrong, it sucks.
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?
you can embed JSON objects in a <script> tag if you need to.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[dead]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[flagged]
[dead]
[dead]
[dead]