291–300 of 308 posts
I'd still want the LLM using markdown, its a much better fit than HTML for loading context. I'd want to consume it in a nicer visual representation. It writes something like `` and it builds to a styled HTML table for me.
Earlier quoted context omitted.
Next up after HTML: someone rediscovers programming languages and comes up with the idea to use them to prompt agents.
Maybe with some kind of plugin for more deterministic output from those languages?
Generating markdown is faster so unlike our friend here, I still do use it for straightforward things.
BUT, in general, I tell Claude, "I think we should starting a project planning folder for this. Put (the stuff we just talked about) into an html doc. while you're at it, make an index.html and put relative link to the page with a little explanation of what we are up to."
Or, just yesterday Claude and I worked out the design for a substantial AI enabled database tool. I had it make an explanatory doc for my team. It was a single html file that navigated through forty scenes that demonstrated it. MAGIC.
If you aren't doing your collaboration with Claude in html, listen to this guy. Your life and work will be better.
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 rep…
BUT, I only do this as an easy way of referencing specific ideas and text in notes to instruct Claude. I say, "I have added notes. Read them and adjust the doc accordingly." Or, "Read the notes I added. Turn them into html."
It's an insanely productive pattern.
I run a web server on my Mac. Consequently, I have an HTTP process available. I keep intending to make an endpoint that Claude can use. I would tell it to make a document for commenting (or put a list of options or whatever) and post it to, I guess, the planning folder we are working in. The endpoint would know how to do this because I wrote it.
When it gets there, I would, I wanted to keep it, tell Claude to integrate the results into the file as static HTML. Or, if I don't care about that, just read it and do whatever I said and leave it disconnected.. The goal isn't to make a website.
This supports interactive conversations with Claude via HTML.
Earlier quoted context omitted.
Hand on heart. When was the last time you built a serious production system for a real business that was 100% built from HTML without using any build step? Just editing the footer and header in every file when it updates (or using iframes)
Maybe not in your corner of the internet, but businesses used server side includes (SSI) for that, not iframes. You add “include” tags to your HTML file and your web server like nginx or varnish would replace it with the fragment at runtime. I saw this was quite popular for big publishing houses with millions of articles still relatively recently 10 years ago. They would only write the HTML body of a new article and…
This makes me think of a thing I have been planning to do. Maybe one of you will do it and tell me some cool refinements. I run a web server on my Mac. Consequently, I have an HTTP process available. I keep intending to make an endpoint that Claude can use. I would tell it to make a document for commenting (or put a list of options or whatever) and post it to, I guess, the planning folder we are working in. The endpo…
The endpoint verifies that the destination specified by the POST is in my project folder. If it points at an existing file, it creates a version. It does not overwrite.
I added a CLI, watchFile, that blocks Claude until the file shows up.
And made a skill that tells Claude to respond nicely to "Make an interactive document that...".
Claude Code has basically made software functionality, "Your wishes come true".
This makes me think of a thing I have been planning to do. Maybe one of you will do it and tell me some cool refinements. I run a web server on my Mac. Consequently, I have an HTTP process available. I keep intending to make an endpoint that Claude can use. I would tell it to make a document for commenting (or put a list of options or whatever) and post it to, I guess, the planning folder we are working in. The endpo…
Now I have a favorite in my bookmark bar for each project I am working on that shows me the docs.
I'm so happy.
Many of us had CC routinely generate HTML ever since it became available. Surprised that it's presented as some kind of novelty.
I don’t think the idea of generating HTML is a novelty. Anyone using an LLM to create a web app has done that. Any “novelty” here is the idea of favoring HTML rather than Markdown for internal docs like specs, design docs, etc. Maybe you were already doing that. I sure haven’t been. In hindsight it’s obvious that it would be useful in some circumstances. Previously, I’ve had a bias against HTML because it’s annoying…