Live data from Hacker News

Using Claude Code: The unreasonable effectiveness of HTML

twitter.com

271–280 of 308 posts

Re: Using Claude Code: The unreasonable effectiveness of HTML

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

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 ;)

Re: Using Claude Code: The unreasonable effectiveness of HTML

#273
post #15

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

Re: Using Claude Code: The unreasonable effectiveness of HTML

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

Re: Using Claude Code: The unreasonable effectiveness of HTML

#276
post #126
post #61

Earlier quoted context omitted.

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.

HTML is by far simpler than Markdown.

Markdown covers only a very small subset of HTML. By definition you are wrong.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#277
post #3

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 l…

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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#278

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…

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.

Re: Using Claude Code: The unreasonable effectiveness of HTML

#280
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.
Post reply on HN