The problem
The Web Gallery of Art has been online since 1996. Emil Krén and Daniel Marx started it on the early web, and it grew into a virtual museum of European art: more than 52,000 reproductions by more than 5,800 artists, with biographies, commentaries, guided tours, period music and a glossary. Emil Krén is my grandfather.
The site was still built the way sites were built in 1996, with frames, table layouts, images as navigation, static HTML and CGI scripts. Its content, its presentation and the machinery behind them had grown into each other. Keeping it running took decades of experience of how the files fitted together.
The gallery has also called itself a searchable database for most of its life, but there has never been a database behind it. Its source is the image files themselves, each carrying its own catalogue entry in the file’s comment field, and a small tool called jpegcw generates the pages from those comments. The biographies, tours and glossary are hand-written HTML, each with its own conventions.
The rebuild
I am rebuilding the gallery as an open-source application that keeps its content and replaces everything it runs on. The rule I hold to is that nothing disappears because it is inconvenient to migrate. Old links should keep working wherever possible, looking at art should not need an account, and the existing editorial material should not be quietly rewritten.
The new interface works on today’s screens. Artists and artworks have their own records that visitors can browse and filter, and search is becoming the main way around the site. Dual Mode opens two artworks side by side, and a timeline places artists and artworks in time. There is keyboard navigation throughout, with a light and a dark theme. The original features, such as the postcard service, the glossary and the guestbook, are moving into the new structure.
The site also gives language models a route of their own: a plain Markdown version of every artist and artwork, generated every night. An agent that asks for it gets a record in about 2 KB instead of 72 KB of HTML, usually from Cloudflare’s cache.
Architecture
The browser talks to one application, written in Go on PocketBase. PocketBase provides the database layer on SQLite, migrations, an admin interface and the web server. The Go code on top of it serves the public site and runs the scheduled jobs, such as building the sitemap and sending postcards. The image files sit in S3-compatible object storage on Railway, which also hosts the application.
Pages are rendered on the server with templ, which gives Go typed HTML templates. htmx swaps server-rendered fragments into the page for pagination, search, filters and forms, so nearly everything still works with JavaScript switched off. In October 2026 the browser received about 655 KB of JavaScript in total, and more than half of it is libraries such as htmx.
The data migration is a deterministic parser, so the same source always gives the same database. It keeps every date as written, such as “c. 1670”, and stores a start year, an end year and an approximate flag beside the text. A location becomes a record only through a reviewed list of 957 places; the 8,215 artworks the list cannot match keep their location text and go into a report for a person to review. Artist names keep their historical shape, so Leonardo da Vinci is never forced into a first and a last name.
Decisions and trade-offs
The gallery is a catalogue that got around 723,000 requests a day in October 2026, and almost all of them are reads. That let me leave out what it does not need: a single-page application, a separate frontend and backend, and a Kubernetes cluster. Server-rendered HTML also suits screen readers and search engines, and every page is a real URL that people can bookmark.
SQLite means no sharding and no conventional redundancy. I accepted that because nothing in the gallery needs distributed writes, and I added OpenTelemetry tracing early so that a database problem would show up in the traces. PocketBase is pre-1.0, and a large architectural change around version 0.20 cost me extra work. Static HTML was attractive, but the study boards, itineraries and dual-pane browsing would have needed an application bolted awkwardly on top.
Language models touch the dataset in one place. A model running locally writes image descriptions for screen readers, sees only the pixels, and its output is kept apart from the curators’ text.
Where it stands
The rebuild is public at beta.wga.hu as a pre-alpha. Some pages are incomplete, features are missing and data still needs checking. The guided tours, for example, stay in their original form until a person approves the file that curates them. Deployments to Railway are reproducible, and Sentry sponsors the project through its open-source programme.
I started the rebuild in 2024, then left it for a long time before picking it up again. There is no date for a first production release: it ships once it is fit for use. No feedback has come in from the public yet, and bot traffic hides how many real visitors the pre-alpha has.
