Live data from Hacker News

Useful patterns for building HTML tools

simonwillison.net

11–20 of 101 posts

Re: Useful patterns for building HTML tools

#11
Great timing - I've taken up vibecoding and picked personal tools with simple HTML/CSS/JS/python stack as the learning ground too.

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.

Re: Useful patterns for building HTML tools

#12
I’ve been making stuff like this for a while (pre-LLM days). They are great little side projects that tend to be useful without getting overly complex. While I’ve vibe coded a couple just to get something done that I needed, I tend to like to write them myself still, as I enjoy the process.

Re: Useful patterns for building HTML tools

#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/public-cdn-risks/

Re: Useful patterns for building HTML tools

#14

I’ve been making stuff like this for a while (pre-LLM days). They are great little side projects that tend to be useful without getting overly complex. While I’ve vibe coded a couple just to get something done that I needed, I tend to like to write them myself still, as I enjoy the process.

Been writing code since the 80's on my C64 and I love it but at this point, I will never write another line of code yet I will produce more code than I ever have! It's just as fun if not more.

Re: Useful patterns for building HTML tools

#18
HTML tools are a good name. I called them something like "a local html file"

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.

Re: Useful patterns for building HTML tools

#19
Unrelated, but I bought a walking pad, and because I often use it at home while working on the laptop, and I wanted a nice UI to track the speed/time etc, I just asked claude to do one:

https://pastebin.com/5HRLh1G6

it does something like this

https://imgur.com/a/888BtpG

and connects through BLE

Re: Useful patterns for building HTML tools

#20
post #10

Really enjoyed this, interesting read as always! It reminded me of Google Labs’ recent GenTabs project [1], and also of a recent ACM paper on user-assembled LLM-mediated tools from web content [2]. Feels like similar concepts are emerging in multiple places, all centered around lightweight intent-driven tools rather than traditional apps, which I think makes a lot of sense. Curious how this will evolve! [1] https://l…

I think UIs will become more "generative" or "on demand". Not necessarily always generated anew, but assembled from pre-generated (reproducible) components, to suit a specific workflow.

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.

Post reply on HN