Rendered at 14:14:46 GMT+0000 (Coordinated Universal Time) with Netlify.
nedt 11 minutes ago [-]
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.
tmhrtly 8 hours ago [-]
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.
athrowaway3z 2 hours ago [-]
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.
Jakob 7 hours ago [-]
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.
OJFord 5 hours ago [-]
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.
afavour 54 minutes ago [-]
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.
embedding-shape 3 hours ago [-]
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.
coldtea 52 minutes ago [-]
>Templated though, not manually writing it out for every blog post say.
Both. We manually run HTML just fine back in the day.
F7F7F7 2 hours ago [-]
Oh my sweet summer child…
OJFord 2 hours ago [-]
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.
abanana 1 hours ago [-]
That incredibly condescending phrase should be banned from HN.
coldtea 52 minutes ago [-]
It fits perfectly.
laurels-marts 6 hours ago [-]
You have been authoring HTML by hand for decades. Not every SWE is a FE dev.
radicalbyte 54 minutes ago [-]
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.
ffsm8 3 hours ago [-]
People have been authoring html by hand for a long time before the specialization to Frontend dev even existed...
graemep 1 hours ago [-]
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.
AlecBG 6 hours ago [-]
Java engineers write lots of HTML in java docs:)
Tomte 2 hours ago [-]
Yes so far, but it‘s switching heavily towards Markdown.
F7F7F7 2 hours ago [-]
I learned HTML 20+ years ago in high school.
I did not go to a front end high school.
austin-cheney 5 hours ago [-]
Most front end devs can’t get HTML right either.
embedding-shape 3 hours ago [-]
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.
pydry 5 hours ago [-]
>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.
pbhjpbhj 4 hours ago [-]
After you a FE webdev that doesn't regularly author HTML by hand?
victorbjorklund 2 hours ago [-]
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)
coldtea 50 minutes ago [-]
LLMs aside, when was the last time you wrote React/JSX and didn't write a subset of HTML by hand in them?
F7F7F7 2 hours ago [-]
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.
1 hours ago [-]
edoloughlin 3 hours ago [-]
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.
adamtaylor_13 19 minutes ago [-]
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.
9dev 7 hours ago [-]
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.
teiferer 6 hours ago [-]
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.
IanCal 2 hours ago [-]
HTML is plain text based at the same level as any programming language I can think of.
9dev 5 hours ago [-]
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.
coldtea 49 minutes ago [-]
>with on-demand, purpose-generated ephemeral UI
Nope, it's a fixed, coded and shipped UI: the agent TUI.
dkersten 5 hours ago [-]
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.
pbhjpbhj 4 hours ago [-]
MS Word uses HTML under the hood, right? (Or some SGML at least.)
4k0hz 7 hours ago [-]
Is HTML really that much worse to edit than MD?
rubslopes 20 minutes ago [-]
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
sheept 6 hours ago [-]
Markdown is essentially just syntactic sugar for HTML[0], so yes it was made to be easier to edit than HTML.
It’s a bit easier yeah but there’s not much in it.
psychoslave 7 hours ago [-]
Let’s see…
*No!*
I mean, <b>yes!</b>
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.
abirch 4 hours ago [-]
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.
afavour 49 minutes ago [-]
> 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.
adam_patarino 3 hours ago [-]
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.
manmal 6 hours ago [-]
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.
elkoan 6 hours ago [-]
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!"
chickensong 5 hours ago [-]
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.
solenoid0937 28 minutes ago [-]
At the same time it has gotten WAY better at parsing giant documents due to this.
elkoan 5 hours ago [-]
Valid points, but they address a totally different matter than the one I pointed out.
Computer0 4 hours ago [-]
I completely agree but hadn’t found a way to put it to words. It could be the model too trained on optimized strategies
afro88 6 hours ago [-]
Nah they do. They push Sonnet pretty hard rather than Opus for most tasks.
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.
oefrha 6 hours ago [-]
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.
F7F7F7 2 hours ago [-]
HTML is by far simpler than Markdown.
Zetaphor 26 minutes ago [-]
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".
dheera 2 hours ago [-]
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.
tdeck 19 minutes ago [-]
Oddly enoght those are now called the "bring attention to" element [1], the "idiomatic text" lement [2], and the "unarticulated annotation" element.
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.
awllau 6 hours ago [-]
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.
divbzero 7 hours ago [-]
Yes, and you can always embed HTML in Markdown for <script>, <style>, <svg>, and other tags that cannot be coded in Markdown.
radicalbyte 56 minutes ago [-]
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.
archpulse 4 hours ago [-]
[flagged]
bigfudge 7 hours ago [-]
[dead]
arianvanp 4 hours ago [-]
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
Don't get me started on the "templating" for Twitter Articles, it doesn't even support markdown...
momojo 8 hours ago [-]
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!"
rsolva 6 hours ago [-]
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!
l3x4ur1n 7 hours ago [-]
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.
Hasbaranews 6 hours ago [-]
[flagged]
drob518 8 hours ago [-]
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.
throwatdem12311 2 hours ago [-]
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.
djyde 5 hours ago [-]
I recommend allowing AI to use TailwindCSS and Alpine in the context, as this would generate great lightweight dynamic web pages.
neomantra 29 minutes ago [-]
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.
5 minutes ago [-]
mritchie712 47 minutes ago [-]
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.
PhilippGille 5 hours ago [-]
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.
You should never have to preview a markdown document, in my opinion. At that point, just make an HTML document.
apsurd 9 hours ago [-]
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.
laurels-marts 5 hours ago [-]
Wait so when u navigate to a different page/tab the url wouldn’t update?
apsurd 5 hours ago [-]
it does, it's a nextjs app so there's a bunch of top level pages that work as you'd expect. The issue is that we're trying to be a real company, those pages have nested logic, multiple views, sub navigation, search, filtering, wizards, all of which are in a cascade of react hooks because AI is obsessed with self-contained hooks. none of that state is linkable.
What i learned, by fire, is that nextjs works well with its nested routing and layout-to-hold-context magic. it's quite nifty but it's not free and not obvious, you have to design for it. I can't state enough that AI will ship a billion hooks, it loves hooks for self-contained state. My colleague made a good point that that style is a feature; it limits blast radius of N features all building on top of each other.
Yeah i had to move on from there.
ryandsilva 8 hours ago [-]
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.
IanCal 2 hours ago [-]
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.
alsetmusic 8 hours ago [-]
> I’ve started preferring HTML as an output format instead of Markdown and increasingly see this being used by others on the Claude Code team, this is why.
This is why I read long agent output either by using VIM and MacOS Quicklook (with a markdown extension for rendering) or paste output into MarkEdit (an editor with a preview pane; I think it’s cross platform?). Worst case, have an agent build you a simple local web page that interprets Markdown and renders it. Markdown was invented as a shorthand for web syntax[0]. That’s what it’s for! I bet you spend more tokens and time asking an agent to convert its native markdown to html than any of these.
The unreasonable effectiveness of the most popular "programming" language used by the most people on Earth ever that has been careful crafted by extremely dedicated people for decades and that is use to communicate by, to and from the most people that ever existed (because yes, most "apps", on mobile at least but even more and more on desktop are just HTML pages too).
Is it really unreasonably effective?
SlinkyOnStairs 3 hours ago [-]
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.
40four 2 hours ago [-]
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.
graemep 2 hours ago [-]
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.
readitalready 7 hours ago [-]
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)
yokoprime 4 hours ago [-]
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
danw1979 6 hours ago [-]
you can embed JSON objects in a <script> tag if you need to.
FailMore 6 hours ago [-]
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)
d0gsg0w00f 1 hours ago [-]
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.
FailMore 26 minutes ago [-]
Interesting point. If you have any ideas how SmallDocs could be both let me know…!
bdelmas 55 minutes ago [-]
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.
ar_turnbull 8 hours ago [-]
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. ^_^
estetlinus 7 hours ago [-]
Blog post plz
alt227 4 hours ago [-]
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
Polarity 1 hours ago [-]
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.
GreenJacketBoy 6 hours ago [-]
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.
sverhagen 2 hours ago [-]
>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.
IanCal 2 hours ago [-]
Writing and editing html by hand is very simple, it can be just a few basic tags.
pbhjpbhj 4 hours ago [-]
>But HTML documents are much easier to read, [than markdown]
Presumably you mean rendered HTML rather than the source documents?
jaaron 8 hours ago [-]
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.
DeadEye2111 4 hours ago [-]
We've circled back to TimBL's original vision of hypertext documents with links. It's beautiful.
jwr 6 hours ago [-]
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.
thih9 2 hours ago [-]
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.
steve_adams_86 7 hours ago [-]
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.
BretonForearm 9 hours ago [-]
Many of us had CC routinely generate HTML ever since it became available. Surprised that it's presented as some kind of novelty.
drob518 8 hours ago [-]
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.
2001zhaozhao 8 hours ago [-]
I'm thinking of adding support for GitHub-flavored markdown (including things like Mermaid diagrams) in my agent wrapper tool and then adding something like a skill for Claude Code to always write GitHub-flavored markdown and use its features when communicating with me. Seems a lot better than general Markdown.
Though now I'm wondering: why not just add full HTML embedding support as well? I'm talking not just for specific deliverables, but for any of the agent's responses with the user.
kulikalov 9 hours ago [-]
Md and plotly is all you need. The only thing that is truly missing is some sort of Markdown-based forms
johndreic 2 hours ago [-]
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.
F7F7F7 2 hours ago [-]
HTML and hand written CSS mind as well be legally binding.
ocimbote 7 hours ago [-]
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.
ozim 7 hours ago [-]
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”.
k4rli 7 hours ago [-]
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.
seebeen 3 hours ago [-]
Why does everyone feel the need to reinvent the wheel every few days?
denalii 6 hours ago [-]
> 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.
stuaxo 6 hours ago [-]
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.
estetlinus 7 hours ago [-]
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!
LunicLynx 7 hours ago [-]
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.
htch 8 hours ago [-]
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.
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."
forgotusername6 7 hours ago [-]
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.
Diti 7 hours ago [-]
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.
whatever1 8 hours ago [-]
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
isoprophlex 5 hours ago [-]
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.
postalcoder 8 hours ago [-]
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.
doc_ick 7 hours ago [-]
~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…
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.
Kwpolska 8 hours ago [-]
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.
weird-eye-issue 8 hours ago [-]
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?
If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.
jason1cho 7 hours ago [-]
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.
albedoa 2 hours ago [-]
> has cooled down due to chatbots.
What in the world.
k4rli 7 hours ago [-]
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.
koolala 9 hours ago [-]
The unreasonable effectiveness of HtmlX.
imbnwa 7 hours ago [-]
Feels like markdown is token-efficient since its abbreviating HTML tags. Think about a large table. Also, HTML can't be especially rendered inside, say, Neovim, so now interacting with an LLM interface gravitates towards GUIs. Good for accessibility, I guess, there's that. Maybe the need for token efficiency will finally realize my dream of writing Slim[0], or some such, straight to the browser, full native compat.
> I find it difficult to read a markdown file of more than a hundred lines.
This is the sort of observation that should make you concerned about your own skills, rather than spur you to generate an article (longer than you can read easily) trying to give advice to other people.
The linked article could have been made using Markdown, and yet the author still chose to represent themselves this way; there's no point changing the tool when the problem is the user.
Now of course you could just reprompt your LLM to change the HTML - but when I already have a clear idea of what I want to say in my head, that’s just another roadblock in the way.
If this pattern becomes more common I suspect human/LLM co-creation will further dwindle in favour of just delegating voice, tone and content choice to the LLM. I was surprised not to see this concern in the blog post’s FAQ.
Currently working on a dumb little mobile game with isometric view and sound:
- told codex to write a tool that lets its place blocks in a prepared three.js document and have chromium dev tools take a screenshot. It made up a little JSON structure that defines blocks / colors and some other effects and it outputs 2.5d tilesets.
- told it to create a uv python script that would let it define sounds and music, and it made a yaml format that lets it create noises.
We completely shot past the svg pelican test. Codex has created both perfectly adequate prototype art of soldiers/knights/priests as well as a prototype soundtrack.
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.
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.
Both. We manually run HTML just fine back in the day.
'we have been authoring' is present perfect continuous. Going forwards, and for at least the last two 'decades', HTML blog posts can use CMSs.
I'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.
I did not go to a front end high school.
No, we've been generating it with templates or authoring templates.
Authoring HTML by hand is a very early 2000s thing to do.
Yesterday. Astro components.
3 million people will have seen it as I type this. More next week.
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.
Nope, it's a fixed, coded and shipped UI: the agent TUI.
HTML made by Claude will, by default, be "sleek, modern", with colorful tables, cards, maybe Tailwind for styling. And, of course it will, if you wanted a barebones HTML, you would just have asked for markdown!
So the LLM decided to present some content using 4 cards, and you now want to add new itens. You can't just add new lines of text: you need to copy the whole HTML of the cards. But the LLM used different colors for each card, so now you have the first cards with varying colors and the new cards all the same color as the last card. Now you have to think about colors... etc etc
[0]: https://spec.commonmark.org/0.31.2/#html-blocks
2. One of the limiting factors of LLM is context. An html table takes up way more tokens than a markdown table. Especially if it's a WYSIWYG editor that has all kinds of css and <span> tags just for fun.
That might be the case today but there’s no reason for it to always be true. They are different representations of the same thing, an LLM could (arguably should!) store an internal representation that uses fewer tokens.
I think most of us live somewhere in the middle, using the right tool / output for the job.
"No bread? Let them eat cake!"
To me it feels like a worse experience, and they probably feel it too, but it makes sense from an optimization perspective. I've probably learned some shell tricks, but also going blind from watching Claude try dozens of variations of some multi-line chained and piped wall of bash nightmare, instead of just reading a few files.
Also: https://platform.claude.com/docs/en/agents-and-tools/tool-us...
It also gives tips on reducing context size when you run /context .
Presumably they are actually starting to feel the pinch on inference costs themselves with what still feels like a fairly generous max plan.
It's arguable even more readable.
<b>bold</b> <i>italic</i> <u>underline</u>
I can never remember how many stars and ticks correspond to what in markdown.
1: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
2: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
3: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
I know that it's 2026 and we've spent the last 15 years hiring people into our field who don't understand the hacker mindset but I didn't think that I'd find them here. They would have been ran out pretty quickly.
Arguing for html on a platform with less rich semantics than markdown is just ultimately funny
I guess it’s both
``` In a single index.html, no dependencies, sparse styling, create an app that <idea> ```
Even before AI, it's how I built small tools, and there's something lovely about being able to email my friends the tool, and tell them "If you want to make a change, toss it to your LLM!"
It is incredible how far you get with a single HTML-file, containing styles and JS, when building dashboards, small apps and other utilities that can interact with an API or otherwise fetch data from somwhere.
I just drop it on my personal ~ folder on the shared server at work and voilà, everyone can check it out and use it immediately!
I absolutely hate the absolute rot these tools have caused to people’s brains.
I talk to laypeople about their AI work -- I am constantly doing this, inserting myself into AI conversations on the street like an anthropologist when I encounter them...
HTML artifacts are the new browser URL bar, wherein some users have a mental model that that bar is actually Google.
Many people now talk about their "spreadsheet" or their "presentation" or "marketing tear sheet", or "slide show", "competitive analysis", "hvac system diagram" or whatever the thing they were working on and how lame it was working with ChatGPT or Claude Web.... and how miraculous Claude Code or OpenClaw is with creating these new documents...
I will ask them what the documents actually are and what the difference in experience was. It takes a lot of teasing (because they don't have the computing vocabulary yet) or having them show me, and it will always come down to that the artifact is HTML.
Their pleasant experience is that it is iterating on an HTML file (+CSS +images) living on a filesystem with high quality instant rendering; plus it can sprinkle JavaScript when it needs to. It might even revision control it without them knowing if there's a git system. [I suggest they checkpoint their work if they don't; revision control is the next stage of learning for the laypeople?]
Whereas the Web-embedded experiences are stabbing multiple times on a DOCX/PPTX/XLSX lingering in a context window and a vague notion of local storage (rendered as HTML anyway in a sidebar), etc. The HTML workflow also allows other media to be integrated much more easily.
So really all this presentation work is Vibe-Coding by the masses; they don't need to know about all the turtles underneath them. But if they are willing, they could crack it open and see and edit it; or easily hand it off to another agent.
Go figure that the system created for collaborative multimedia communication ends up being useful for the machine intelligence to help us communicate.
For example, user says "build a report with revenue and orders by month and show 100 most recent orders". The agent would write a spec that would get rendered by our frontend.
This runs fast, but we were drowning in feature requests for what the framework could render (e.g. "I don't want labels here", "I DO want labels there", "can this chart be a heatmap", etc.)
A few months ago, we let the agent just write HTML instead. It takes longer to generate, but you get unlimited customization.
There are a host of issues with the new approach (non-technical users debugging a monstrous app they created), but net-net our customers like it much better.
For the most parts you just write the regular Markdown headers and paragraphs, embed images, insert tables etc without the need for any HTML tags, making it readable in source form. And if you want to embed an SVG file for example, which the author of the article mentions as one use case, you just embed the SVG directly, and people can render the Markdown in their favorite viewer.
Let's say you're viewing a raw Markdown file in VS Code. You come onto an HTML tag, so you hit Cmd+Shift+V to open the preview and that's it.
Of course for full-fledged web pages with interactive buttons and fully customized styling and all of that, which the author shows in some examples, this is not feasible. But you can get very far when you have mostly text/images/tables and just want to add some extras here and there.
[1] https://daringfireball.net/projects/markdown/syntax#html
[2] https://spec.commonmark.org/0.31.2/#html-blocks
I worked with a vibe coded app at my last job (and since quit due to it) and because it was a nextjs SPA frontend with a separate API backend, the user facing urls didn't match the backend endpoints. Because AI uses react hooks for everything, state is in-memory, url-based routing isn't a thing unless you design for it. So links aren't free and thus we have no way for users to link to anything other than top-level entry points. LINKS! Especially for internal tools, everything being linkable is vital to collaboration and problem solving.
The need for uniform resource locations and verbs was so well thought out, 30 or 40 some odd years ago.
What i learned, by fire, is that nextjs works well with its nested routing and layout-to-hold-context magic. it's quite nifty but it's not free and not obvious, you have to design for it. I can't state enough that AI will ship a billion hooks, it loves hooks for self-contained state. My colleague made a good point that that style is a feature; it limits blast radius of N features all building on top of each other.
Yeah i had to move on from there.
Both of these tradeoffs set Anthropic up for success. Using HTML as our medium will increase token usage, and I'd bet they're investing in tools to mark up HTML (part of Claude Design) which will help improve lock-in. Either coincidence or brilliant strategy.
What’s harder than with markdown about precise feedback? You can have ids, sections and more with tags.
This is why I read long agent output either by using VIM and MacOS Quicklook (with a markdown extension for rendering) or paste output into MarkEdit (an editor with a preview pane; I think it’s cross platform?). Worst case, have an agent build you a simple local web page that interprets Markdown and renders it. Markdown was invented as a shorthand for web syntax[0]. That’s what it’s for! I bet you spend more tokens and time asking an agent to convert its native markdown to html than any of these.
0. https://daringfireball.net/projects/markdown/
Using bots has been insane and self-referrential.
Is it really unreasonably effective?
While it has been used in the context of HTML before, it's a bit of a "meme" as several papers used that phrase. Much like the "X is all you need" snowclone.
The HTML version dates from 2021 (https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...) when client side rendering and web apps were still their peak.
I also love how maybe 10% of the posts on here are like "some thing that has existed for 40+ years ,/:/; Claude/chatgpt". So much advertising at the expense of a dead internet it's ridiculous.
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.
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 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 even did a workshop with PartyKit cursors, dot voting, reflection comments, and an individual rating at the end.
Oh, and I can add super lightweight analytics so I know who actually reads my things or interacts with my prototypes. ^_^
I'm also not convinced that it solves meaningful problems :
> I've found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read, In my experience, LLMs are not concise when it comes to documentation, so using an easier file format to read because the text is too large sounds to me like solving the wrong problem
> Markdown files are fairly hard to share since most browsers do not render them natively well. Yes, but developers tools (IDE, Git forge) do. What most/some of them don't render natively IS HTML.
I tend to not actually read more than 100-lines of anything anymore. I've long referred to myself as "the Google generation": only being able to read the summaries in a search result. That, and the typical doomscrolling model of social media have affected my attention span. Reading anything more substantial takes real effort now.
Presumably you mean rendered HTML rather than the source documents?
I hadn't considered HTML and I'm definitely going to try this.
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.
It ended up being a large document but it was infinitely more useful than plain old markdown. I think I’ll do it more often now. Creating interactive specs is a really fascinating way to work. I’ve always verified my work in similar ways, but this was more… Verification-forward, I guess. And it took hours instead of days.
It’s actually really fun to be building and refactoring these days. No idea how long the fun will last, but I’m thoroughly enjoying it right now. I know it will make some people think I’m a hack, but I know that approach enabled me to do a faster, more targeted, ultimately better job of improving state management in the application. It’s not because Claude wrote the code (I still did quite a bit of it), but because Claude helped me establish the right work to do for the right reasons, using tools I couldn’t dream of throwing together 5 years ago.
Though now I'm wondering: why not just add full HTML embedding support as well? I'm talking not just for specific deliverables, but for any of the agent's responses with the user.
The facts that this article needs to list the pros of HTML over MD, like inreraction, visual density, etc, is weird to me. Maybe the ahdience is not tech-savvy people but I read it as an unnecessary word salad.
It is just realization by author that HTML is also useful tool and MD lacks some stuff.
He didn’t write anything about “now we should stop using MD files”.
It is more like: “I see I can do cool stuff with HTML and found cases where it definitely is right tool for the job”.
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.
What happens when my site changes style, I put it back through the LLM I guess and get some bonus hallucinated content.
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!
Surely a html page could do the same but I would see that as the last step, to give to someone else.
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/
Sure enough, this is full of listicles and of a length no human would write for an idea as simple as "Use HTML instead of Markdown."
Classical overly confident llm bullshitting.
I think the reason stuff like this wasn't done earlier was due to fears about context pollution, but post training has gotten so good that you can do virtually anything in the context window and not have it affect the quality of output.
Markdown only makes sense for us meatbags becuse it's easy for us to edit and version control, but if you're sharing anything where the audience is an agent publicly, HTML must be just as interpretable.
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…
If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.
In turn, chatbots pump up markdown by making it the default output format.
What in the world.
[0]https://slim-template.github.io/
This is the sort of observation that should make you concerned about your own skills, rather than spur you to generate an article (longer than you can read easily) trying to give advice to other people.
The linked article could have been made using Markdown, and yet the author still chose to represent themselves this way; there's no point changing the tool when the problem is the user.