Top
Best
New

Posted by pretext 5 hours ago

Using Claude Code: The unreasonable effectiveness of HTML(twitter.com)
Examples: https://thariqs.github.io/html-effectiveness/

Related: https://simonwillison.net/2026/May/8/unreasonable-effectiven...

160 points | 88 comments
utopiah 10 minutes ago|
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?

arianvanp 16 minutes 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

tmhrtly 4 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.

Jakob 3 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 1 hour 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.
laurels-marts 2 hours ago||||
You have been authoring HTML by hand for decades. Not every SWE is a FE dev.
AlecBG 2 hours ago|||
Java engineers write lots of HTML in java docs:)
austin-cheney 1 hour ago|||
Most front end devs can’t get HTML right either.
pydry 1 hour 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 32 minutes ago||
After you a FE webdev that doesn't regularly author HTML by hand?
9dev 3 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 2 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.
9dev 1 hour 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.
dkersten 1 hour 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 34 minutes ago||
MS Word uses HTML under the hood, right? (Or some SGML at least.)
manmal 2 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 2 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 1 hour 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.

elkoan 1 hour ago|||
Valid points, but they address a totally different matter than the one I pointed out.
Computer0 30 minutes 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
eterm 2 hours ago||||
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 2 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.
afro88 2 hours ago|||
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...

4k0hz 3 hours ago|||
Is HTML really that much worse to edit than MD?
sheept 2 hours ago|||
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

psychoslave 3 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 48 minutes 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.

awllau 2 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 3 hours ago|||
Yes, and you can always embed HTML in Markdown for <script>, <style>, <svg>, and other tags that cannot be coded in Markdown.
archpulse 6 minutes ago|||
[flagged]
bigfudge 4 hours ago||
[dead]
momojo 4 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 2 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 4 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 2 hours ago||
Bump
drob518 4 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.
djyde 1 hour ago||
I recommend allowing AI to use TailwindCSS and Alpine in the context, as this would generate great lightweight dynamic web pages.
DeadEye2111 6 minutes ago||
We've circled back to TimBL's original vision of hypertext documents with links. It's beautiful.
apsurd 5 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 2 hours ago|
Wait so when u navigate to a different page/tab the url wouldn’t update?
apsurd 1 hour 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.

alsetmusic 4 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.

0. https://daringfireball.net/projects/markdown/

AndrewSwift 1 hour ago||
Which Quick Look extension? I've been looking for a good one.
walthamstow 3 hours ago|||
While I agree it probably uses more tokens, the author works for Anthropic and has probably never paid for a token
jason1cho 4 hours ago||
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.

PhilippGille 1 hour 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.

[1] https://daringfireball.net/projects/markdown/syntax#html

[2] https://spec.commonmark.org/0.31.2/#html-blocks

the_gipsy 1 hour ago|
You should never have to preview a markdown document, in my opinion. At that point, just make an HTML document.
ryandsilva 4 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.

GreenJacketBoy 2 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.

pbhjpbhj 20 minutes ago|
>But HTML documents are much easier to read, [than markdown]

Presumably you mean rendered HTML rather than the source documents?

More comments...