Live data from Hacker News

Useful patterns for building HTML tools

simonwillison.net

21–30 of 101 posts

Re: Useful patterns for building HTML tools

#22
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…

Great link.

Re: Useful patterns for building HTML tools

#23
I just shipped a new one of these a few minutes ago (from my phone).

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

Re: Useful patterns for building HTML tools

#24
post #15

If HTML tools could make network calls (CORS be damned), they could replace a huge portion of hosted apps.

I'm tempted to run a CORS proxy somewhere - maybe on Cloudflare Workers - but I'm nervous that any open proxy is liable to be abused.

I could do an authentication protected one that only I could access though...

Re: Useful patterns for building HTML tools

#26
> "If you want to see the code and prompts, almost all of the examples in this post include a link in their footer to “view source” on GitHub. The GitHub commits usually contain either the prompt itself or a link to the transcript used to create the tool."

As if your steady stream of learning-in-public experiments and insights weren't generous enough. Seriously, massive kudos for sharing all the details.

Re: Useful patterns for building HTML tools

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

Re: Useful patterns for building HTML tools

#28
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 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 , 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.

Re: Useful patterns for building HTML tools

#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, though.

Re: Useful patterns for building HTML tools

#30

Another useful pattern for certain types of app is to include a function that saves the HTML file to your local drive/memory as a new file - for example, if the app features user inputs like writing or drawing.

It's a little problematic to share an HTML file that you made or saved on your phone with other phone users directly, for example by sending via a messaging app: Android it's ok, but iOS won't open or save an HTML file sent in this way. Apparently there is a workaround to long press on the file to save it to your Files folder first.

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.

Post reply on HN