I list them at https://client-side.app/
I don't have a lot of public examples of this, but here's a larger project where I used this strategy for a relatively large app that has TypeScript annotations for easy VSCode use, Tailwind for design, and it even loads in huge libraries like the Monaco code editor etc, and it all just works quite well 100% statically:
HTML file: https://github.com/blixt/go-gittyup/blob/main/static/index.h...
Main entrypoint file: https://github.com/blixt/go-gittyup/blob/main/static/main.js
Personal tools seem like a reasonable place for happy path vibecoding given small blast radius and LLMs can do that sort of static page in front of python backend really well.
I've also been surprised how much active learning I'm doing despite specifically not look at code. Between the need to spec things out carefully (plan.md) and fast iteration loop it's been a huge boost. Having the LLM look at a plan.md and suggest improvements has lead to a lot of "oh I didn't think about that" learning on architecture and user requirements link.
Presumably much of that learning boost is because I'm a hobbyist tier programmer, guessing professionals wouldn't experience the same since they learned this via manual coding trial & error over years.
I can only speak for myself and my not-quite two decades of professional experience, but yes pretty much!
It’s neat to see that sped up for others though with lower stakes, though it’s not quite the same unless you prompt your agent to question you back a lot (Claude is much better at this in my experience)
My tool collection [0] is inspired by yours, with a handful of differences. I'm only at 53 tools at the moment.
What I did differently:
Hosted on Cloudflare Pages. This gives you preview URLs for pull requests out the box. This might be possible with Github Pages but I haven't checked. I've used Vercel for similar projects in the past. Cloudflare seems to have the odd failed build that needs a kick from their dashboard.
Some tools can make use of Workers/Functions for backend processing and secrets. I try to keep these to a minimum but they're occasionally useful.
I have an AGENTS.md that's updated with a Github action to automatically pull in Claude-style Skills from the .skills directory. I blogged about this pattern and am still waiting for a standard to evolve [2].
I have a base stylesheet that I instruct agents to pull in. This gives a bit of consistency and also let's them use Tailwind, which they'd seem to love.
[0] https://tools.dave.engineer/
I found out about a new Python HTML parsing library - https://github.com/EmilStenstrom/justhtml - and wanted to try it out but I'm out without my laptop. So I had Claude Code for web build me a playground interface for trying it out: https://tools.simonwillison.net/justhtml
It loads the Python library using Pyodide and lets you try it out with a simple HTML UI.
The prompts I used are in this PR: https://github.com/simonw/tools/pull/156
Thank you.
In the case of JustHTML I've now been able to try it against a few different HTML documents, seen it do good pretty-printing, played with its CSS selector implementation and got a feel for its event-based streaming parser. I'm very impressed! I think I'll be using it in the future next time I need an HTML parser.
Until vibe coding came along, the ergonomics of a library were no less important than its functionality. But I understand how LLM assisted coding changes that perspective.
I'll go tend to my empty lawn now.
One problem I solved with this was a packer needed to scan a few (10-40) ids into his barcode scanner. It was not enough where pulling up their bulk-id-uploader program but also too tedious to go to some "number to barcode" website.
Turns out, barcodes can be made from a google font!
https://fonts.google.com/specimen/Libre+Barcode+39
You can just display a number using that font. Then hooked up a for-loop that's progressed by pressing the space bar: paste in IDs, scan first, space, scan next, repeat.
I think especially in context of software that is complex and takes a long time to master, this could be the next breakthrough. Instead of paths-to-goal being buried in sequences of menus and config panels, workflow pathways would be invocable with plain language.
I haven’t found too many issues with loading React and Babel from a CDN. I find React easier to read than straight HTML/JS. I find it more annoying to code in but seeing what state is needed in what components is a pleasant reading experience for me with single file tools.
I'm with you though, personally react is a acceleration mechanism for me because I often find existing well built components already. I don't built the same thing as the author though.
More recently, I've found a lot of benefit from using the extended thinking mode in GPT-5 and -5.1. It tends to provide a fully functional and complete result from a zero-shot prompt. It's as close as I've gotten to pair programming with a (significantly) more experienced coder.
One functional example of that (with 30-50% of my own coding, reprompting and reviews) is my OntoGSN [1] research prototype. After a couple of weeks of work, it can handle different integration, reasoning and extension needs of people working in assurance, at least based on how I understood them. It's an example of a human-AI collab that I'm particularly proud of.
[1] Playground at w3id.org/OntoGSN/
One pattern I've settled into: keeping tools under ~200 lines of JS total. Past that threshold I start losing the ability to hold the whole thing in my head, and the main benefit of these tools is that you can open them in a text editor and understand everything immediately.
The CORS limitation that xnx mentions is real though. I've worked around it a few times by having tools accept paste-from-clipboard instead of fetching URLs directly. Less elegant but it keeps the tool self-contained and avoids the proxy problem simonw mentioned.
I use indexedDB for it and will use sqlite if I start to get more serious data needs.
This really showcases the power of the single page apps and why web will be always ahead of native for this kind of Swiss Army Knife tools.
With LLMs, it gets ridiculously easy to “develop” (generate) those too.
They have a library of sample apps you can edit but I wish they included the prompts and history to build each since I generally can’t get large apps to work - after a while the I’ll just produces more bugs as complexity grows. But I’m also a bad vibe coder and never read the code so entirely my fault :)
It may well do that, but it's not earned my trust yet!
One tool I'd really like to see in this format is a simple "turn the background of this PNG to transparent". Models still refuse to follow the instruction to create transparent backgrounds for logos they create, and I often have to look for other tools doing this as post-processing.
It's possible that this is too complicated for the "few hundred lines of js" code envelope, though.
Build transparent-png.html - a tool that lets you open any image and then click on colors within that image to make them transparent - showing a preview of the resulting PNG against a checkerboard pattern and optional against other selected background colors below, plus a download PNG option
It should also accept pasted images
Here's what I got (from Opus 4.5 in Claude Code for web via the Claude iPhone app): https://tools.simonwillison.net/transparent-pngSeriously, though, I think this solves a nicely framed simpler problem. I was thinking about a more general tool, but that's genuinely hard (you'll need heavy CV algorithms or a special ML model to detect what is background what what isn't).
To be honest, what you built here is probably sufficient anyway, because the models are better at obeying "create a white background" or "create a 0xffffff background" than "transparent", so this tool can post-process to what's needed.
When asked for "transparent", I've had a model generate a fake checkerboard pattern of gray colors to imitate how viewers render transparent areas :-) For this kind of nonsense, the transparent-png tool wouldn't do!
(I’m not actually kidding)
I wonder if packaging the results as web components would be the next logical step.
As if your steady stream of learning-in-public experiments and insights weren't generous enough. Seriously, massive kudos for sharing all the details.
I've also been using LLMs to create and maintain a "work assist" Chrome extension that I load unpacked from a local directory. Whenever I notice a minor pain point, I get the LLM to quickly implement a remedy. For example, I usually have several browser tabs open for Jira, and they all have the same company logo as the favicon, so my Chrome extension changes the favicon to be the issue type icon (e.g. Bug, Story, etc) when the page loads. It saves a little time when I'm looking for a specific ticket I've already opened.
Create PDFs from images, a Wordle hint/solver, or a classic DVD screensaver. Lots of stuff.
Not sure why, but the moment the file is split into files and subfolders, coding agents tend to do a lot more changes that what is absolutely necessary. That way a single html file wins!
I tend to make them as Python servers which serve plain html/js/css with web components. I know this is a bit more complicated than just having a single html file with inline js and css, but the tools I made were a bit too complicated for the LLMs to get just right, and separating out the logic into separate js files as web components made it easy for me to fix the logic myself. I also deliberately prompted the LLMs to avoid React because adding I didn't want to need a build step.
The only one I actually still use is the TODO app I made: https://github.com/cooljoseph1/todo-app It stores everything in a JSON file, and you can have multiple TODO lists at once by specifying that JSON file when you launch it.
I could do an authentication protected one that only I could access though...
No. You can vendor these scripts & host them 1st party so you aren’t leaking data to these CDNs or risk users not actually getting the scripts. It isn’t like CDNs give you a performance boost anymore.
I'll vendor and self-host for my professional projects, but for these small experimental utilities I've stopped caring.
This is what CDNs should be used for at this time—or for fetching the scripts to vendor. That’s fine, but recommending I don’t think is the best call since one folk’s experimental utility will inevitably get released into production—often not even at fault of the utility’s maker. When I use CDNs like this, there are <!-- WARNING … --> around the code just in case someone were to run with it, along with adding the integrity attribute.
This issue is relevant if your app's functionality includes the user changing the contents of the file and re-saving as a new file.
Things like styling buttons, responsiveness, and so on are better solved once.
A good rule of thumb is: if the shared CSS fails to load, page still fully works but it might be uglier (weird fonts, etc). That's a reasonable rule for proper isolation (tools remain simple to understand, code remains reusable, etc).
I love the idea of self-contained tools, but you're already using CDNs. Having a shared CSS wouldn't hurt and actually make the tools better.
I would go as far as having a shared JS too (same idea, works if it doesn't load).
That's essentially what I did in https://alganet.github.io/spiral/ (also vibe coded).
Each spiral is mostly independent. You can go ahead and delete the shared CSS from the <head>, they still work and don't break funcionality. However, by having the shared CSS I made them consistent, made them friendly to phone users and so on.
It's been fun collecting a bunch of inconsistent tool designs just to see how the different models behave, plus occasionally I go for something with a topical theme like https://tools.simonwillison.net/terminal-to-html or https://tools.simonwillison.net/new-yorker-style - but a little more consistency could be nice.
Not only for the user, but it makes sense for the process of making the tools as well.
If I left the agent for itself, it often come up with outrageous styles and I need to prompt it for something more sober.
---
You can do a lot with just CSS. I restored this 2009 project of mine just now:
https://alganet.github.io/ghiaweb/
It still works (minor misalignments though), all HTML is pure (no class=, no css=, no <div>). The global CSS does everything: the forms, the drop-down menus, etc.
Nowadays, we can do even better, no build step or anything like that.
it does something like this
and connects through BLE