Broadsheet

We’ve spent a lot of time examining the problem of construction productivity in the US — the fact that, across a variety of different metrics, construction never seems to get any more efficient (in terms of how much output you get for a given amount of input), or any cheaper. A paper I wrote about by Goolsbee and Syverson, for instance, titled “The Strange and Awful Path of Productivity in the US Construction Sector,” looked at a variety of different productivity metrics and found that they all show either flat or declining productivity. By contrast, other sectors (such as manufacturing), as well as the economy overall, tend to show increasing productivity.

Much of our investigations have been focused specifically on the issues of construction productivity in the US. But it’s also worth looking at construction productivity trends in other countries — if other countries are showing steadily improving construction productivity, that may give us ideas for ways to improve US construction productivity. If they’re not improving, by contrast, that suggests that US-specific things (such as various regulations) aren’t what’s holding American construction productivity back .

International construction productivity

To look at international construction productivity, we can use KLEMS databases, which aggregate productivity statistics for different industries in countries around the world. (KLEMS stands for capital (K), labor (L), energy (E), materials (M), and services (S).) These KLEMS datasets are a bit scattered and not amazingly well-maintained (I had to retrieve a lot of the data from archive.org), but by pulling them together we can assemble construction productivity datasets for dozens of different countries going back quite far:

The EU KLEMS dataset has productivity data for European nations, as well as a smattering of other countries. The current EU KLEMS release goes from 1995 to 2021, and in addition to European countries also includes the US, the UK, and Japan. Older EU KLEMS releases (I used the 2008 release) go all the way back to 1970, and in addition to the US, UK, and Japan, also include Korea, Canada, and Australia.
Asia KLEMS has productivity data for Korea, Japan, Taiwan, and India, going from 1980 to 2012.
LA KLEMS has productivity data for several latin american countries, going from 1990 to around 2019.
World KLEMS, in addition to links to the above datasets, also has links to Canada, Russia, and China KLEMS data.

To calculate productivity using this data — specifically, labor productivity, or the amount of output we get for a specific amount of labor — we can use the “chain linked gross value add” measure, VA_Q or VA_QI in the database. Gross value-add is the value of the outputs (in this case, the buildings and infrastructure produced) minus the value of “intermediate inputs” — materials, services, energy, and other things purchased from outside the sector in question. In other words, it’s the total value that the industry itself contributes. “Chain linked” is a way of adjusting for inflation, by calculating the growth rate for one year using the previous year’s prices, then “chaining” those growth rates together. To get sector productivity, we just divide chain linked gross value-add by a measure of total labor effort in that sector. For that labor effort variable, we’ll use H_EMP, which is the total number of hours worked by “engaged persons” — employees, business owners, and people who are self-employed.

For a few countries, we’ll need to calculate labor productivity slightly differently. India’s KLEMS data doesn’t include H_EMP, so we’ll use the number of employees instead. China’s KLEMS data doesn’t include VA_Q, but it does include the growth rate of labor productivity by industry, which provides the same information.

Putting all this together, the below chart shows construction labor productivity by country, for 45 different countries. Countries are color-coded by region, and labor productivity has been normalized to equal 100 in the first year for which there’s data.

(Click to embiggen.)

Since this can be a little hard to parse, here’s a smaller graph showing productivity trends in 16 major countries. This figure also shows labor productivity in manufacturing (solid gray line), and across all industries (dotted gray line).

Let’s start by looking at the US. Per KLEMS data, the US had declining construction labor productivity since 1970, which started to flatten out around the mid-1990s. This exact pattern is a bit different from what other measures of US construction labor productivity show — Goolsbee and Syverson show productivity declining up through 2020, whereas Teicholz shows labor productivity that’s closer to flat since the 1960s — but it’s broadly consistent with them.

If we look at other countries, we can see that for the period from 1970 through the early 1990s, the US is an outlier in having declining construction productivity. From 1970 through 1995, US construction productivity declined by about 1.9% per year on average. For other countries where data goes back to the 70s (which is most of Western Europe, Japan, Korea, Australia, and Canada), only one other country shows an average decline over that same period (Greece), and its decline is much smaller. Most other countries show improving construction productivity of around 1-2% per year.

A 1-2% improvement in construction productivity isn’t amazing — as we can see in the figure above, it’s often much less than the rate of improvement in manufacturing, or in the economy overall — but it’s nevertheless a positive trend.

Since roughly the mid-1990s, however, the trends look somewhat different. The US arrested its construction productivity declines, and the industry’s productivity levels have stayed more or less flat. And many countries that previously were showing positive construction labor productivity growth — Germany, France, Italy, Spain, Austria, Japan, the UK — have since had flat or negative productivity growth. Other countries have maintained positive rates of productivity growth — Netherlands, Belgium, Denmark — but at lower levels than it was previously.

Starting in the 1990s (and earlier for some countries), we also have productivity data on a whole new swath of Asian, Eastern European, and South American countries. Many (but by no means all) of these countries — such as Latvia, Lithuania, Costa Rica, Peru — have shown steadily improving construction productivity over time. Typically it’s smaller and/or less wealthy countries that have shown these improvements.

Some of these countries (such as Taiwan) have shown a similar pattern as Western European countries, with construction labor productivity that improves for a while but then flattens out. The data for Taiwan and Korea (which both show this pattern) stops in 2012; I’d be interested to see what the trends since then have been.

Interestingly, despite the enormous amount of effort it put into infrastructure and building construction, and despite how repetitive much of it is, China does not appear to have particularly impressive growth in construction productivity. Productivity has risen, to be sure, but only at around a rate of 1.9% since 1987, and only around 1.4% since 1995. similar to the rates of growth seen in Western European countries in the 70s and 80s. Between 2007 and 2017, productivity growth is close to flat.1

Japan, the US’s former Asian rival, is similarly unimpressive, with nearly flat construction productivity since the 1970s.

Per this KLEMS data, the most impressive country in terms of productivity growth isn’t China, Japan, or Korea but Belgium, of all places. In the 1970s and 80s, Belgium had a construction productivity growth rate of greater than 3% annually, higher than anywhere else. And while most wealthy countries have had flat or marginal construction productivity improvements since the 1990s, Belgium has maintained a growth rate of around 1% per year. Belgium is also one of the only countries where the rate of productivity growth in construction is consistently similar to overall productivity growth.

It’s not clear to me if this is some sort of statistical or accounting artifact, or if Belgium has figured something out about construction that no one else seems to know. However, I’m somewhat inclined to think it’s the former. If you look at Belgium construction cost indexes, they seem to rise at roughly the same rate that US construction cost indexes do. And if you look at the actual cost builders are charging for new homes in Belgium, they appear to be slightly higher than US costs per unit area.

A note on the difficulty of measuring construction productivity

I’ve noted previously that in general I prefer cost as a measure of construction process improvement rather than productivity, and that I’m somewhat suspicious of these sorts of abstract measures of construction productivity. I’ve moderated this view somewhat, but it’s still true that care is required when trying to measure construction productivity, as it’s very easy for distortions to creep in. When I wrote about Goolsbee and Syverson’s paper on construction productivity, I noted that a very large fraction of the supposed decline in construction productivity is due to an unusually large deflator (used to adjust for inflation) used by the Bureau of Economic Analysis. Additionally, the United States’ Bureau of Labor Statistics sector-specific measures of construction productivity have shown implausibly large swings from year to year. The accounting required for sector-wide productivity estimates is just hard to do reliably.

An illustration of this is that a 2017 Mckinsey report on construction productivity, which uses the exact same KLEMS database that we used above, comes up with substantially different estimates of construction productivity growth.

Per this graph, circa 2015 the UK had around 0.5% construction productivity growth since 1995, while per our calculations it would be slightly negative. Sweden and Germany similarly have positive construction productivity growth under this analysis, while per our calculations they were slightly negative. Both calculations show Belgium having positive productivity growth, but McKinsey has a growth rate that’s about twice as high as ours. And where we have a construction productivity growth rate for China of around 1.4-1.9% per year, McKinsey has it as closer to 7%.

What’s the source of this discrepancy? The chief culprit appears to be revisions in the KLEMS data over time. The Mckinsey report used KLEMS data circa 2017, while our post-1995 analysis above uses KLEMS data from 2025. This matters because KLEMS updates don’t merely include data for more recent years, they also revise previous data. Here, for instance, is UK construction productivity across several iterations of KLEMS data:

And here’re some revisions to the Swedish data overtime:

Between 2019 and 2024, Swedish construction productivity was revised upward substantially — changing it from a steady decline to merely mostly flat — whereas UK construction productivity was revised downward substantially.

My broader point is that it’s tricky to use these high-level, sector-wide productivity estimates: slightly different analysis choices (which deflator, measure of labor input, or dataset you use) can result in pretty different conclusions, so they should be used and interpreted with care. In particular, it’s somewhat suspicious that there’s a big change in productivity trends right around the point where we switch from an older (EU KLEMS 2008) to a newer (EU KLEMS 2025) dataset (though for many countries there’s good overlap between the two datasets).

Conclusion

Looking at this international productivity data, here are my main takeaways:

Per KLEMS data, many countries have historically shown construction labor productivity increases. From the 1970s through the 1990s, this was the norm for most Western European countries, as well as Korea and Taiwan.
The US is unusual for having declining construction labor productivity during this period.
Since roughly the 1990s, some (but not all) Eastern European countries, some (but not all) Latin American countries, and China have seen substantial construction labor productivity increases. A few Western European countries — Ireland, Denmark, the Netherlands — have seen more modest increases since the mid-1990s. But most Western European countries, along with Japan and Korea, have had flat or declining labor productivity growth since the 1990s.
The recent US trend in labor productivity — it staying roughly flat — is fairly consistent with trends in other large, wealthy countries. This includes countries whose construction practices the US is often encouraged to emulate. Sweden, for instance, is often praised for its high adoption of prefabricated construction, but since the 1990s Sweden has had roughly flat construction labor productivity, even as it has made more extensive use of prefabrication. Japan similarly makes wider use of prefabrication than the US does, and Japan has proved willing to experiment with technologies like automated skyscraper construction, but has seen virtually no construction productivity improvement since the 1970s. China is held up as an example of an infrastructure-focused nation that the US should emulate, but its construction productivity gains, while positive, don’t appear to be particularly impressive.
The most impressive country for construction productivity is Belgium — it stands alone as a rich country that has had sustained, high levels of construction productivity growth. However, it’s not clear if these are real improvements or some sort of statistical or accounting artifact. Cost data does not appear to indicate that Belgium is building things massively more cheaply than elsewhere. (If you know anything about construction productivity in Belgium, email me.)
All this must be taken with a large grain of salt, because this sort of productivity accounting is hard to do accurately.

Overall, my take when looking at this data is that stagnant construction productivity is an extremely widespread problem. The trends we see in the US — flat or declining construction productivity — are also what we see in other large, wealthy countries over the past 30 years. Most countries that achieved construction productivity growth at one time haven’t maintained it. The countries that currently show improving productivity tend to be small (Ireland, Denmark, Estonia), poor (Colombia, Peru), or both. And construction productivity improvements in these countries tend to severely lag improvements in manufacturing, or what’s observed in the economy overall. Even sustained, large-scale building programs (such as China’s) or widely adopted factory-based construction (such as Sweden’s) don’t appear to have changed this.

This isn’t to say that there’s nothing the US has to learn from other countries. For one, it’s worth understanding what specifically was going on towards the end of the 20th century when so many countries had rising construction productivity, often at or above the levels of productivity improvements in their overall economies. It’s also worth investigating what, specifically, is going on in places like Belgium and Estonia; I’m not amazingly confident there will be lessons that are broadly applicable, but I’m not so pessimistic that I don’t think it’s worth probing further.

The above data also only considers changes in construction productivity, and doesn’t have anything to say about absolute levels, and it seems obvious to me that, in many cases, US construction practices lag behind European ones for things like transit construction. The US has a lot to learn from other countries for how to catch up to the efficient frontier, especially for certain types of construction (ie: transit) and in certain places in the country (ie: expensive coastal metros). But this data suggests that driving that frontier forward is a much thornier problem.

More charitably, there’s a productivity decline starting around 2007, likely as a result of the global financial crisis’ effect on construction, followed by an increase of around 2.2% per year.

The memo, per State Department standards perhaps, uses two spaces after sentences and colons. In the original copy I received, those double-spaces were sometimes in the sequence NON-BREAK-SPACE + SPACE, and other times the other way around: SPACE + NON-BREAK-SPACE. There were also a handful of seemingly random non-breaking space characters between words, mid-sentence. All of them, I suspect, just invisible-to-the-eye detritus from Microsoft Word. I replaced all of them with regular spaces, preserving, in plain text, two spaces wherever two spaces were intended. ↩︎
Do I think it was “fair and informative” to describe all of the Biden State Department’s DEIA initiatives as “illegal, immoral, radical, or wasteful”? No. Did I bother reading any of the documents Rubio referenced as proving such? No. Do I think this particular memorandum, specific to changing State’s font back to Times New Roman, would have been stronger without that line, leaving his defenestration of the Calibri font change to speak for itself? Yes. But that line was just one aside in an otherwise focused, sober, and, yes, fair and informative memo. ↩︎︎

I've started using the term HTML tools to refer to HTML applications that I've been building which combine HTML, JavaScript, and CSS in a single file and use them to provide useful functionality. I have built over 150 of these in the past two years, almost all of them written by LLMs. This article presents a collection of useful patterns I've discovered along the way.

First, some examples to show the kind of thing I'm talking about:

svg-render renders SVG code to downloadable JPEGs or PNGs
pypi-changelog lets you generate (and copy to clipboard) diffs between different PyPI package releases.
bluesky-thread provides a nested view of a discussion thread on Bluesky.

These are some of my recent favorites. I have dozens more like this that I use on a regular basis.

You can explore my collection on tools.simonwillison.net - the by month view is useful for browsing the entire collection.

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.

The anatomy of an HTML tool

These are the characteristics I have found to be most productive in building tools of this nature:

A single file: inline JavaScript and CSS in a single HTML file means the least hassle in hosting or distributing them, and crucially means you can copy and paste them out of an LLM response.
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.
Load dependencies from a CDN. The fewer dependencies the better, but if there's a well known library that helps solve a problem I'm happy to load it from CDNjs or jsdelivr or similar.
Keep them small. A few hundred lines means the maintainability of the code doesn't matter too much: any good LLM can read them and understand what they're doing, and rewriting them from scratch with help from an LLM takes just a few minutes.

The end result is a few hundred lines of code that can be cleanly copied and pasted into a GitHub repository.

Prototype with Artifacts or Canvas

The easiest way to build one of these tools is to start in ChatGPT or Claude or Gemini. All three have features where they can write a simple HTML+JavaScript application and show it to you directly.

Claude calls this "Artifacts", ChatGPT and Gemini both call it "Canvas". Claude has the feature enabled by default, ChatGPT and Gemini may require you to toggle it on in their "tools" menus.

Try this prompt in Gemini or ChatGPT:

Build a canvas that lets me paste in JSON and converts it to YAML. No React.

Or this prompt in Claude:

Build an artifact that lets me paste in JSON and converts it to YAML. No React.

I always add "No React" to these prompts, because otherwise they tend to build with React, resulting in a file that is harder to copy and paste out of the LLM and use elsewhere. I find that attempts which use React take longer to display (since they need to run a build step) and are more likely to contain crashing bugs for some reason, especially in ChatGPT.

All three tools have "share" links that provide a URL to the finished application. Examples:

ChatGPT JSON to YAML Canvas made with GPT-5.1 Thinking - here's the full ChatGPT transcript
Claude JSON to YAML Artifact made with Claude Opus 4.5 - here's the full Claude transcript
Gemini JSON to YAML Canvas made with Gemini 3 Pro - here's the full Gemini transcript

Switch to a coding agent for more complex projects

Coding agents such as Claude Code and Codex CLI have the advantage that they can test the code themselves while they work on it using tools like Playwright. I often upgrade to one of those when I'm working on something more complicated, like my Bluesky thread viewer tool shown above.

I also frequently use asynchronous coding agents like Claude Code for web to make changes to existing tools. I shared a video about that in Building a tool to copy-paste share terminal sessions using Claude Code for web.

Claude Code for web and Codex Cloud run directly against my simonw/tools repo, which means they can publish or upgrade tools via Pull Requests (here are dozens of examples) without me needing to copy and paste anything myself.

Load dependencies from CDNs

Any time I use an additional JavaScript library as part of my tool I like to load it from a CDN.

The three major LLM platforms support specific CDNs as part of their Artifacts or Canvas features, so often if you tell them "Use PDF.js" or similar they'll be able to compose a URL to a CDN that's on their allow-list.

Sometimes you'll need to go and look up the URL on cdnjs or jsDelivr and paste it into the chat.

CDNs like these have been around for long enough that I've grown to trust them, especially for URLs that include the package version.

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.

Host them somewhere else

I don't like leaving my HTML tools hosted by the LLM platforms themselves for a couple of reasons. First, LLM platforms tend to run the tools inside a tight sandbox with a lot of restrictions. They're often unable to load data or images from external URLs, and sometimes even features like linking out to other sites are disabled.

The end-user experience often isn't great either. They show warning messages to new users, often take additional time to load and delight in showing promotions for the platform that was used to create the tool.

They're also not as reliable as other forms of static hosting. If ChatGPT or Claude are having an outage I'd like to still be able to access the tools I've created in the past.

Being able to easily self-host is the main reason I like insisting on "no React" and using CDNs for dependencies - the absence of a build step makes hosting tools elsewhere a simple case of copying and pasting them out to some other provider.

My preferred provider here is GitHub Pages because I can paste a block of HTML into a file on github.com and have it hosted on a permanent URL a few seconds later. Most of my tools end up in my simonw/tools repository which is configured to serve static files at tools.simonwillison.net.

Take advantage of copy and paste

One of the most useful input/output mechanisms for HTML tools comes in the form of copy and paste.

I frequently build tools that accept pasted content, transform it in some way and let the user copy it back to their clipboard to paste somewhere else.

Copy and paste on mobile phones is fiddly, so I frequently include "Copy to clipboard" buttons that populate the clipboard with a single touch.

Most operating system clipboards can carry multiple formats of the same copied data. That's why you can paste content from a word processor in a way that preserves formatting, but if you paste the same thing into a text editor you'll get the content with formatting stripped.

These rich copy operations are available in JavaScript paste events as well, which opens up all sorts of opportunities for HTML tools.

hacker-news-thread-export lets you paste in a URL to a Hacker News thread and gives you a copyable condensed version of the entire thread, suitable for pasting into an LLM to get a useful summary.
paste-rich-text lets you copy from a page and paste to get the HTML - particularly useful on mobile where view-source isn't available.
alt-text-extractor lets you paste in images and then copy out their alt text.

Build debugging tools

The key to building interesting HTML tools is understanding what's possible. Building custom debugging tools is a great way to explore these options.

clipboard-viewer is one of my most useful. You can paste anything into it (text, rich text, images, files) and it will loop through and show you every type of paste data that's available on the clipboard.

Clipboard Format Viewer. Paste anywhere on the page (Ctrl+V or Cmd+V). This shows text/rtf with a bunch of weird code, text/plain with some pasted HTML diff and a Clipboard Event Information panel that says Event type: paste, Formats available: text/rtf, text/plain, 0 files reported and 2 clipboard items reported.

This was key to building many of my other tools, because it showed me the invisible data that I could use to bootstrap other interesting pieces of functionality.

More debugging examples:

keyboard-debug shows the keys (and KeyCode values) currently being held down.
cors-fetch reveals if a URL can be accessed via CORS.
exif displays EXIF data for a selected photo.

Persist state in the URL

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 like this for tools I may want to bookmark or share with other people.

icon-editor is a custom 24x24 icon editor I built to help hack on icons for the GitHub Universe badge. It persists your in-progress icon design in the URL so you can easily bookmark and share it.

Use localStorage for secrets or larger state

The localStorage browser API lets HTML tools store data persistently on the user's device, without exposing that data to the server.

I use this for larger pieces of state that don't fit comfortably in a URL, or for secrets like API keys which I really don't want anywhere near my server - even static hosts might have server logs that are outside of my influence.

word-counter is a simple tool I built to help me write to specific word counts, for things like conference abstract submissions. It uses localStorage to save as you type, so your work isn't lost if you accidentally close the tab.
render-markdown uses the same trick - I sometimes use this one to craft blog posts and I don't want to lose them.
haiku is one of a number of LLM demos I've built that request an API key from the user (via the prompt() function) and then store that in localStorage. This one uses Claude Haiku to write haikus about what it can see through the user's webcam.

Collect CORS-enabled APIs

CORS stands for Cross-origin resource sharing. It's a relatively low-level detail which controls if JavaScript running on one site is able to fetch data from APIs hosted on other domains.

APIs that provide open CORS headers are a goldmine for HTML tools. It's worth building a collection of these over time.

Here are some I like:

iNaturalist for fetching sightings of animals, including URLs to photos
PyPI for fetching details of Python packages
GitHub because anything in a public repository in GitHub has a CORS-enabled anonymous API for fetching that content from the raw.githubusercontent.com domain, which is behind a caching CDN so you don't need to worry too much about rate limits or feel guilty about adding load to their infrastructure.
Bluesky for all sorts of operations
Mastodon has generous CORS policies too, as used by applications like phanpy.social

GitHub Gists are a personal favorite here, because they let you build apps that can persist state to a permanent Gist through making a cross-origin API call.

species-observation-map uses iNaturalist to show a map of recent sightings of a particular species.
zip-wheel-explorer fetches a .whl file for a Python package from PyPI, unzips it (in browser memory) and lets you navigate the files.
github-issue-to-markdown fetches issue details and comments from the GitHub API (including expanding any permanent code links) and turns them into copyable Markdown.
terminal-to-html can optionally save the user's converted terminal session to a Gist.
bluesky-quote-finder displays quotes of a specified Bluesky post, which can then be sorted by likes or by time.

LLMs can be called directly via CORS

All three of OpenAI, Anthropic and Gemini offer JSON APIs that can be accessed via CORS directly from HTML tools.

Unfortunately you still need an API key, and if you bake that key into your visible HTML anyone can steal it and use to rack up charges on your account.

I use the localStorage secrets pattern to store API keys for these services. This sucks from a user experience perspective - telling users to go and create an API key and paste it into a tool is a lot of friction - but it does work.

Some examples:

haiku uses the Claude API to write a haiku about an image from the user's webcam.
openai-audio-output generates audio speech using OpenAI's GPT-4o audio API.
gemini-bbox demonstrates Gemini 2.5's ability to return complex shaped image masks for objects in images, see Image segmentation using Gemini 2.5.

Don't be afraid of opening files

You don't need to upload a file to a server in order to make use of the <input type="file"> element. JavaScript can access the content of that file directly, which opens up a wealth of opportunities for useful functionality.

Some examples:

ocr is the first tool I built for my collection, described in Running OCR against PDFs and images directly in your browser. It uses PDF.js and Tesseract.js to allow users to open a PDF in their browser which it then converts to an image-per-page and runs through OCR.
social-media-cropper lets you open (or paste in) an existing image and then crop it to common dimensions needed for different social media platforms - 2:1 for Twitter and LinkedIn, 1.4:1 for Substack etc.
ffmpeg-crop lets you open and preview a video file in your browser, drag a crop box within it and then copy out the ffmpeg command needed to produce a cropped copy on your own machine.

You can offer downloadable files too

An HTML tool can generate a file for download without needing help from a server.

The JavaScript library ecosystem has a huge range of packages for generating files in all kinds of useful formats.

svg-render lets the user download the PNG or JPEG rendered from an SVG.
social-media-cropper does the same for cropped images.
open-sauce-2025 is my alternative schedule for a conference that includes a downloadable ICS file for adding the schedule to your calendar. See Vibe scraping and vibe coding a schedule app for Open Sauce 2025 entirely on my phone for more on that project.

Pyodide can run Python code in the browser

Pyodide is a distribution of Python that's compiled to WebAssembly and designed to run directly in browsers. It's an engineering marvel and one of the most underrated corners of the Python world.

It also cleanly loads from a CDN, which means there's no reason not to use it in HTML tools!

Even better, the Pyodide project includes micropip - a mechanism that can load extra pure-Python packages from PyPI via CORS.

pyodide-bar-chart demonstrates running Pyodide, Pandas and matplotlib to render a bar chart directly in the browser.
numpy-pyodide-lab is an experimental interactive tutorial for Numpy.
apsw-query demonstrates the APSW SQLite library running in a browser, using it to show EXPLAIN QUERY plans for SQLite queries.

WebAssembly opens more possibilities

Pyodide is possible thanks to WebAssembly. WebAssembly means that a vast collection of software originally written in other languages can now be loaded in HTML tools as well.

Squoosh.app was the first example I saw that convinced me of the power of this pattern - it makes several best-in-class image compression libraries available directly in the browser.

I've used WebAssembly for a few of my own tools:

ocr uses the pre-existing Tesseract.js WebAssembly port of the Tesseract OCR engine.
sloccount is a port of David Wheeler's Perl and C SLOCCount utility to the browser, using a big ball of WebAssembly duct tape. More details here.
micropython is my experiment using @micropython/micropython-webassembly-pyscript from NPM to run Python code with a smaller initial download than Pyodide.

Remix your previous tools

The biggest advantage of having a single public collection of 100+ tools is that it's easy for my LLM assistants to recombine them in interesting ways.

Sometimes I'll copy and paste a previous tool into the context, but when I'm working with a coding agent I can reference them by name - or tell the agent to search for relevant examples before it starts work.

The source code of any working tool doubles as clear documentation of how something can be done, including patterns for using editing libraries. An LLM with one or two existing tools in their context is much more likely to produce working code.

I built pypi-changelog by telling Claude Code:

Look at the pypi package explorer tool

And then, after it had found and read the source code for zip-wheel-explorer:

Build a new tool pypi-changelog.html which uses the PyPI API to get the wheel URLs of all available versions of a package, then it displays them in a list where each pair has a "Show changes" clickable in between them - clicking on that fetches the full contents of the wheels and displays a nicely rendered diff representing the difference between the two, as close to a standard diff format as you can get with JS libraries from CDNs, and when that is displayed there is a "Copy" button which copies that diff to the clipboard

Here's the full transcript.

See Running OCR against PDFs and images directly in your browser for another detailed example of remixing tools to create something new.

Record the prompt and transcript

I like keeping (and publishing) records of everything I do with LLMs, to help me grow my skills at using them over time.

For HTML tools I built by chatting with an LLM platform directly I use the "share" feature for those platforms.

For Claude Code or Codex CLI or other coding agents I copy and paste the full transcript from the terminal into my terminal-to-html tool and share that using a Gist.

In either case I include links to those transcripts in the commit message when I save the finished tool to my repository. You can see those in my tools.simonwillison.net colophon.

Go forth and build

I've had so much fun exploring the capabilities of LLMs in this way over the past year and a half, and building tools in this way has been invaluable in helping me understand both the potential for building tools with HTML and the capabilities of the LLMs that I'm building them with.

If you're interested in starting your own collection I highly recommend it! All you need to get started is a free GitHub repository with GitHub Pages enabled (Settings -> Pages -> Source -> Deploy from a branch -> main) and you can start copying in .html pages generated in whatever manner you like.

Bonus transcript: Here's how I used Claude Code and shot-scraper to add the screenshots to this post.

Tags: definitions, github, html, javascript, projects, tools, ai, webassembly, generative-ai, llms, ai-assisted-programming, vibe-coding, coding-agents, claude-code