[HN Gopher] Useful patterns for building HTML tools
___________________________________________________________________
Useful patterns for building HTML tools
Author : simonw
Score : 335 points
Date : 2025-12-10 21:08 UTC (3 days ago)
(HTM) web link (simonwillison.net)
(TXT) w3m dump (simonwillison.net)
| wiseowise wrote:
| Amazing article with lots of useful info. Big kudos, Simon.
|
| 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.
| simonw wrote:
| It really is wild how quickly these things pop out - this one
| here took a couple of prompts, probably ten minutes from idea
| to shipping a working implementation:
| https://tools.simonwillison.net/pypi-changelog?package=llm&c...
| TomasBM wrote:
| Pretty nice. I've been using LLMs to generate different Python
| and JS tools for wrangling data for ontology engineering
| purposes.
|
| 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/
| NotMichaelBay wrote:
| Nice, I do this often enough that I created a bookmarklet to
| download an HTML file from clipboard after copying ChatGPT's code
| block.
|
| 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.
| lewisjoe wrote:
| I also find that sticking to a single file makes coding agents
| perform better (fewer surgical edits, faster outputs, sensible
| changes, etc).
|
| 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!
| dave1010uk wrote:
| Thanks Simon!
|
| 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/
|
| [1] https://github.com/dave1010/tools/tree/main/functions
|
| [2] https://dave.engineer/blog/2025/11/skills-to-agents/
| TheTaytay wrote:
| Thanks for showing this! It's cool, and I enjoyed reading
| through some of the code. Note that I tried to use some of the
| regex tools that needed LLMs and got a rate limit error.
| sails wrote:
| These are great. Something you might find interesting is that
| you can expose a google sheet to have an interactive database.
| I have a map similar to yours, but with surf spots. Maybe
| defeats the point, but I find it handy
|
| Edit: come to think of it, I should revisit it now that
| everyone can vibe code. The sheet was to allow people to add to
| it, now maybe easier for me to take a message and ask an agent
| to update the html directly
| jddj wrote:
| Awesome.
|
| Couple of unsolicited comments: first is that on mobile, the
| featured badge sits on top of the right facing arrow. Second is
| that the bubble level seems to be upside down? The bubble sinks
| rather than floats at least on my pixel
| abbadadda wrote:
| > "I'm only at 53 tools at the moment."
|
| Sorry if this sounds overly critical, but what do you mean
| "only at 53 tools?" Was there a memo I missed about a
| competition to host LLM-built tools?
| jabbywocker wrote:
| Maybe you're ignoring the context that he's replying to the
| author and saying "only" because he's comparing his 53 with
| the author's 150+
| abbadadda wrote:
| I read the article, and I saw Simon's note about the 150+
| HTML apps, I just don't get it.
| jabbywocker wrote:
| There's nothing to really get. There's no deep meaning to
| the numbers or the comparison
| nels wrote:
| 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://labs.google/disco
|
| [2] https://dl.acm.org/doi/10.1145/3706598.3713285
| btbuildem wrote:
| 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.
| girvo wrote:
| A lot of investment at some very large companies you know are
| trying to achieve this right now, and betting big on it. So
| far the lack of determinism when it _is_ required gets in the
| way, but we'll see: it feels surmountable.
| Havoc wrote:
| 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.
| girvo wrote:
| > 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)
| al_borland wrote:
| 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.
| mattkdev wrote:
| 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.
| toastal wrote:
| > 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/
| chrisweekly wrote:
| Great link.
| simonw wrote:
| 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.
| toastal wrote:
| > 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 <!-- WARNING ... -->
| around the code just in case someone were to run with it,
| along with adding the integrity attribute.
| xnx wrote:
| If HTML tools could make network calls (CORS be damned), they
| could replace a huge portion of hosted apps.
| simonw wrote:
| 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...
| born-jre wrote:
| I am building platform which makes it easy to host this kind of
| app but it has own set of idiosyncrasy u have to adhere to.
|
| https://github.com/blue-monads/potatoverse
| btbuildem wrote:
| I really like the simplicity here (maybe because it mirrors my
| own approach). No build chain, no node_packages, no frameworks.
|
| I wonder if packaging the results as web components would be the
| next logical step.
| valbaca wrote:
| 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.
| oulipo2 wrote:
| 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
| fud101 wrote:
| This does bluetooth? wow.
| fallinditch wrote:
| 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.
| fallinditch wrote:
| 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.
| simonw wrote:
| 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
| dotancohen wrote:
| Serious question. How do you "try out" a library if somebody
| else (or something else) is writing the code?
|
| Thank you.
| simonw wrote:
| The thing that matters for me when considering a new library
| is what it can _do_. Once I know that I can decide if it 's
| worth learning how to use it at a code level.
|
| 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.
| dotancohen wrote:
| I see, thank you.
|
| 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.
| mirekrusin wrote:
| You can use react with jsx without any build step in single
| html file as well.
| simonw wrote:
| Yeah I used it for this one via Babel from a CDN but it felt
| pretty crufty: https://tools.simonwillison.net/box-shadow
| mirekrusin wrote:
| Yes, I guess it would start showing advantage for complex
| ones.
|
| The idea is interesting, shame there is nothing for full
| stack like this, something like opinionated fossil-scm
| setup - which already has project management built in (for
| llm to use for its dev progress); together with backend and
| runtime state squashed inside single sqlite so you can
| create/delete them independently without a fuss.
| pseudosavant wrote:
| I love this pattern. I've been using it myself here:
| https://pseudosavant.github.io/ps-web-tools/
|
| Create PDFs from images, a Wordle hint/solver, or a classic DVD
| screensaver. Lots of stuff.
| chrisweekly wrote:
| > _" 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.
| gaigalas wrote:
| 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 <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.
| simonw wrote:
| 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 nice.
| gaigalas wrote:
| 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 <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.
| eliben wrote:
| 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.
| simonw wrote:
| 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 iPhone app):
| https://tools.simonwillison.net/transparent-png
| indigodaddy wrote:
| Dude, you are amazing. Maybe you should make a suggestion
| box. Then while you are sleeping, the AI could evaluate the
| suggestions, and if they are good, it could prototype the
| tool, and then you could review the prototypes in your waking
| hours before clicking the tool to production. :)
|
| (I'm not actually kidding)
| eliben wrote:
| 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!
| singpolyma3 wrote:
| The best thing to say to an image model IME is "use a
| colour/chroma key background" and then it gives you green
| or blue or whatever depending on colours used in the image.
| throwaway7783 wrote:
| In the same spirit I have started building single page nanodjango
| +htmx apps hosted on railway, starting with, you guessed it, a
| Todo list app. No login needed.
|
| https://web-production-1fc69.up.railway.app/
| bilater wrote:
| Have been doing the same except I do use React because its my
| hammer haha. But I agree if you're not used to it then pure
| html/cs/js make sense.
|
| https://www.hackyexperiments.com/micro
| soared wrote:
| 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 :)
| simonw wrote:
| 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!
| soared wrote:
| 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!)
| indigodaddy wrote:
| I was displeased as well with the share url requiring login
| for AI studio.
| jackfranklyn wrote:
| The barcode font trick from valbaca is brilliant. I've done
| similar things with base64-encoded data URIs to make tools
| completely standalone - no network calls, no CDN dependencies.
|
| 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.
| ulrischa wrote:
| This was the first submission:
| https://news.ycombinator.com/item?id=46236333
| christophilus wrote:
| Nice. I do something similar, but with Bun + Preact, since I love
| that stack. I've found it very productive after the hurdle of the
| initial project setup (in which I wasted time crafting an RPC
| layer, etc, because I wanted to.)
| mettamage wrote:
| > 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.
| binsquare wrote:
| Yep - the author is very opinionated and it's good because it
| works really well for his workflows/usecase.
|
| 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.
| cooljoseph wrote:
| 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.
| mettamage wrote:
| > HTML tools may not have access to server-side databases for
| storage but it turns out you can store a lot of state directly in
| the URL.
|
| I use indexedDB for it and will use sqlite if I start to get more
| serious data needs.
| calebm wrote:
| I've been calling these Single-File Web Apps. I've written a
| couple myself:
|
| [?] https://fuzzygraph.com [?] https://hypervault.github.io/
| calebm wrote:
| Slight correction: I'd only refer to it as a "Single-File Web
| App" if it has no external dependencies (where as the "HTML
| Tool" definition allows for external dependencies loaded from
| CDNs).
| cxr wrote:
| I wouldn't call either of these tools that either. Using View
| Source reveals that there's a pretty obvious build step and
| confronts you with massive minified blobs. There's no way a
| person is going to be able open that HTML as a "single file"
| in their text editor to pick up development where it was left
| off. (In that regard, the HTML tools in the linked post are
| closer to the definition, even when they're written to load a
| module from a CDN.)
| blixt wrote:
| One thing I tend to do myself is use https://generator.jspm.io/
| to produce an import map once for all base dependencies I need
| (there's also a CLI), then I can easily copy/paste this template
| and get a self-contained single-file app that still supports JSX,
| React, and everything else. Some people may think it's overkill,
| but for me it's much more productive than
| document.getElementById("...") everywhere.
|
| 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
| singpolyma3 wrote:
| I wondered how you got JSX but it seems you don't quite and the
| true magic here is the htm library.
| rossant wrote:
| Awesome. This is the way.
| steren wrote:
| I've also been creating HTML tools over the years when I couldn't
| find client-side only websites for PDF to SVG, CSV to Sheet,
| Audio to Video, Video to MP4.
|
| I list them at https://client-side.app/
| meistertigran wrote:
| I was also heavy on these single-file HTML tools. My problem was
| not being able to sync the localstorage data between PC and
| smartphone. I made a paid service which did that automatically.
| It didn't take off unfortunately, and I am keeping it on
| maintenance mode because it has some amount of free users that
| rely on it.
|
| For anyone interested, to achieve synchronization I basically
| just use the https://github.com/google/diff-match-patch lib and
| save the patches in a db for each version with a version id. Then
| there's a generic JS file that I inject to uploaded HTML files
| that monkey patches the localstorage methods and optimistically
| updates the localstorage at the same time sending the diff to the
| server to save to the db.
| dansjots wrote:
| I wonder if you can hack a LocalStorage sync feature via
| ATProto PDS, since you can put arbitrary JSON records via
| /xrpc/com.atproto.repo.putRecord and not just Bluesky posts.
|
| The only drawback I can think of is that all of your commits
| are broadcast on a megaphone to the network firehose, but
| encryption can alleviate that somewhat.
| meistertigran wrote:
| I am not familiar with it, but I was thinking about making an
| open source version of this, but using webRTC, to just
| directly allow peer-to-peer synchronization without a
| centralized server.
|
| In this type of scenario there are a lot considerations to be
| made though, specifically since you can't use CRDT's to
| handle concurrent updates on the data you have to either 1)
| not allow offline use of the apps, 2) create a merge conflict
| resolving interface or 3) just overwrite all changes with the
| latest one.
|
| Idk if people would be interested in this and I haven't been
| using my HTML tools for a while now, so it's just an idea,
| maybe someone else wants to work on.
| cxr wrote:
| > My problem was not being able to sync the localstorage data
| between PC and smartphone
|
| That's what remoteStorage is for.
|
| <https://remotestorage.org/>
| aag wrote:
| I can't get that page to respond. Did you mean
| <https://remotestorage.io/>?
| i_love_retros wrote:
| Endlessly churning out tools with vibe coding sounds quite boring
| to me. The world went and changed I guess.
| maegul wrote:
| Indeed, likely a useful lens on the current moment I'd say.
|
| For better/worse, and whether completely so or not, the time of
| the professional keyboard-driven mechanical logic problem
| solver may simply have just come and gone in ~4 generations (70
| years?).
|
| By 2050 it may be more or less as niche as it was in 1950??
|
| Personally, I find the relative lack of awareness and attention
| on the human aspect of it all a bit disappointing. Being caught
| in the tides of history is a thing, and can be a tough
| experience, worthy of discourse. And causing and even forcing
| these tides isn't necessarily a desirable thing, maybe?
|
| Beyond that, mapping out the different spaces that are brought
| to light with such movements (eg, the various sets of values
| that may drive one and the various ways that may be applied to
| different realities) would also certainly be valuable.
|
| But alas, "productivity" rules I guess.
| naet wrote:
| Building little toy projects like some of these is one of my
| favorite ways to learn and play. Sometimes the value isn't in
| the initial finished product but in the concepts it exposed and
| knowledge or inspiration gained from that.
|
| I guess if what you really want is only the finished product
| and nothing else, churning it out as quickly as possible with
| AI and not caring about the implementation could work for you.
| But it would take the fun out of it for me.
|
| Sadly my career may eventually head in that direction. At least
| I'll always have a hobby to enjoy.
| simonw wrote:
| > Building little toy projects like some of these is one of
| my favorite ways to learn and play.
|
| Same here! That's why I'm having so much fun building nearly
| 100 of them in a year.
|
| The difference here is that I didn't have to type out all of
| the code by hand.
| johnrob wrote:
| Next evolution: UX should allow end users to build the prompt,
| and then the tool is generated and deployed at a random URL. Tool
| also keeps original prompt, so any user can customize into a new
| (random URL) tool page.
| tkclough wrote:
| I'm a big fan of using this kind of thing at work. Rather than
| setting up a web server or packaging something into an installer,
| I just pop the bundled HTML file on a shared drive.
|
| The CDN approach works, but I don't love depending on some third-
| party service just so your app continues working. Instead, I like
| using vite with vite-plugin-singlefile. This lets you package
| your JS and CSS into a single HTML:
| https://www.npmjs.com/package/vite-plugin-singlefile
| sallveburrpi wrote:
| How does the camera mode work? I tried it and it jumps wildly
| between 60 and 100 oO
| TheGoodBarn wrote:
| I've been building these for years. I think its a great
| entrypoint for new developers and can be incredibly useful at
| work for solving short term inconveniences or scripts that help
| automate some tasks.
|
| I have a Vue3 started template I host at https://http://vue-
| template.spaghet.me/ and all I have to do is curl and I'm ready
| to go.
|
| Showcase:
|
| https://timer.spaghet.me/ https://colors.spaghet.me/
| https://box.spaghet.me/ https://talk.spaghet.me/
| https://farming.ope.cool https://stitch.ope.cool
| https://draw.ope.cool https://walz.ope.cool
| insin wrote:
| Makes me wish there was a cross-platform equivalent to HTML
| Applications [1]. They were hell to develop at the time, but
| being able to create single-text-file tools with a browser UI,
| file system and network access, and app automation via COM was
| amazing
|
| [1] https://en.wikipedia.org/wiki/HTML_Application
| 01HNNWZ0MV43FF wrote:
| That would be neat. So instead of having to write a whole
| Electron or Tauri app and package it, you just target some
| shell program.
|
| You could definitely build such a shell with Electron or Tauri,
| it punches a big hole in their security model, but you could do
| it.
| didip wrote:
| To make it extra useful, they should come with REST API and
| swagger docs on how to use the API.
| GeneralMaximus wrote:
| I love this idea! I've also been using LLMs to build tiny
| utilities and automations for myself, but instead of using HTML,
| I'm building them as:
|
| - Shell scripts, AppleScripts, etc. that I trigger from Alfred
|
| - Obsidian plugins
|
| - The occasional Emacs Lisp function
|
| They serve a similar purpose for me as OP's HTML Tools, in the
| sense that they let me automate a small part of my workflow that
| I wouldn't otherwise have automated. If I have to choose between
| writing AppleScript and just doing something manually, I'll pick
| doing something manually 100% of the time. But if I can just ask
| an LLM to write the automation for me and then test it in a bunch
| of different scenarios, the choice becomes much easier.
|
| After reading this post, I really want to try moving some of my
| automations to the web. Using HTML/JS/CSS for some of these tools
| will let me solve a whole different set of problems. E.g. I could
| more easily build automations for the non-techy folks in my
| family instead of just keeping them to myself.
| simonw wrote:
| I've written a bunch of shell scripts like this too, but I've
| been focusing increasingly on web tech mainly because that way
| the same tools work on both my laptop and my phone.
| regus wrote:
| I used to dislike AppleScript but now I enjoy using it. The
| turning point for me was when I finally bit the bullet and read
| a book on the subject.
|
| AppleScript's human readable language lulls you in this false
| sense of security that you can wing it and everything will just
| work out. This is simply not the case, it is a very quirky
| language and it helps to read a book to get the right mental
| model.
|
| The second thing that helped was getting AppleScript debugger
| from Late Night Software. They recently decided to no longer
| develop it and release it for free on their site. It's worth
| getting if you haven't done so already.
| shekhargulati wrote:
| I also started building similar tools in early 2025 and have
| built around 80 of them so far: https://tools.o14.ai/. Recently,
| I built a data viewer app (https://tools.o14.ai/excel-qa-
| review.html) where I can upload an Excel or CSV file containing
| chat queries and answers for quick manual review.
|
| Reviewing data in Excel is painful, especially when answers are
| in HTML or Markdown, because you don't get proper rendering.
| Building small, custom tools that reduce the friction of
| reviewing data makes life much easier and more pleasant. These
| days, I use Claude Code for Web to build most of these apps, and
| they are deployed on Vercel.
| smusamashah wrote:
| I made a heart monitor for very high heart rate
| https://github.com/SMUsamaShah/heart-rate which can be installed
| on phone as a PWA too. It could use some more polish, more
| features which I could do with an LLM again.
|
| LLMs are generating app for an idea that can fit in few hundred
| lines of html/js. Had an idea that what if brushes were dithered
| in a painting tool and made a dithered painting tool.
| https://github.com/SMUsamaShah/dither-painter
|
| These tools and code are ephemeral though. You don't need to use
| mine for example. Just ask the LLM of the time to implement the
| idea and in most cases it will work fine.
| deknos wrote:
| It's so sad that there's no wysiwyg editor besides seamonkey
| which is truly opensource and no electron stuff.. sigh :(
|
| also sad, that XHTML was abandoned.
| yawnxyz wrote:
| I've found a lot of success building in Alpine.js but I'm
| surprised that most people don't do this / don't like it. It
| makes managing reactivity a bit easier than full vanilla JS
___________________________________________________________________
(page generated 2025-12-14 20:01 UTC)