Live data from Hacker News

Useful patterns for building HTML tools

simonwillison.net

41–50 of 101 posts

Re: Useful patterns for building HTML tools

#41
post #39
post #37

Surprised AI studio isn’t recommended here - you can go from prompt->preview->deploy in like a couple seconds. 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 :)

I don't trust it to give me share URLs that anyone can access without a Google account and that will work forever into the future. It may well do that, but it's not earned my trust yet!

Ah I’ve only used that feature once actually I’ll have to try it, I was talking about the deploy on gcp button (but pointlessly not free compared to your github pages recco!)

Re: Useful patterns for building HTML tools

#44
post #39
post #37

Surprised AI studio isn’t recommended here - you can go from prompt->preview->deploy in like a couple seconds. 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 :)

I don't trust it to give me share URLs that anyone can access without a Google account and that will work forever into the future. It may well do that, but it's not earned my trust yet!

I was displeased as well with the share url requiring login for AI studio.

Re: Useful patterns for building HTML tools

#45
post #33

Why not introduce a single shared CSS for style consistency? Not full CSS separation, each tool could still have its local CSS. 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 re…

Yeah, I've been thinking some kind of reusable styles or style guide might be a good idea at this point. 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 nic…

Definitely!

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

Re: Useful patterns for building HTML tools

#47
post #31
post #29

Great work, Simon -- thanks for sharing! 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, tho…

Running this now... 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…

Nice, I'm proud I managed to nerd-snipe you :-) Thanks for taking the time.

Seriously, 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!

Re: Useful patterns for building HTML tools

#48
post #27
post #13

> The alternative to CDNs is to use npm and have a build step for your projects. I find this reduces my productivity at hacking on individual tools and makes it harder to self-host them. 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. https://httptoolkit.com/blog/pub…

I wish vendoring was less of a hassle. I'll vendor and self-host for my professional projects, but for these small experimental utilities I've stopped caring.

> small experimental utilities

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 around the code just in case someone were to run with it, along with adding the integrity attribute.

Re: Useful patterns for building HTML tools

#49
> Avoid React, or anything with a build step. The problem with React is that JSX requires a build step, which makes everything massively less convenient. I prompt “no react” and skip that whole rabbit hole entirely.

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.

Re: Useful patterns for building HTML tools

#50
I've done something similar for a couple tools.

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.

Post reply on HN