Live data from Hacker News

Using Claude Code: The unreasonable effectiveness of HTML

twitter.com

141–150 of 308 posts

Re: Using Claude Code: The unreasonable effectiveness of HTML

#141
post #34

Earlier quoted context omitted.

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.

You have been authoring HTML by hand for decades. Not every SWE is a FE dev.

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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#142
post #78
post #34

Earlier quoted context omitted.

We have been authoring HTML by hand for decades with ease. Text editors are very good at it, and many have commands to auto-wrap, auto-close etc. Reading and writing is simple.

Templated though, not manually writing it out for every blog post say. I think GP means it just has more friction as a writing format than markdown for example.

>Templated though, not manually writing it out for every blog post say.

Both. We manually run HTML just fine back in the day.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#144

Earlier quoted context omitted.

After you a FE webdev that doesn't regularly author HTML by hand?

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)

LLMs aside, when was the last time you wrote React/JSX and didn't write a subset of HTML by hand in them?

Re: Using Claude Code: The unreasonable effectiveness of HTML

#145
post #86

Earlier quoted context omitted.

Let’s see… *No!* I mean, yes! 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 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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#146
post #75

Earlier quoted context omitted.

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.

>with on-demand, purpose-generated ephemeral UI

Nope, it's a fixed, coded and shipped UI: the agent TUI.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#147
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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#148
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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#149
post #62

Earlier quoted context omitted.

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. T…

At the same time it has gotten WAY better at parsing giant documents due to this.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#150

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

Post reply on HN