Porting the legacy applets

A curated transcript of the conversation (with Claude Code) that ported Terence Tao's old Java-1.0 teaching applets — dead in modern browsers — to vanilla JavaScript on tao-web: the six linear-algebra applets (Kim Chi Tran, 2002), the ten complex-analysis applets (Tao, 1998–2000), and several harder one-offs (Besicovitch/Kakeya sets, conformal compactification, honeycombs, an exponent calculator). This is the counterpart to the "making of" transcripts for the original apps — here the work is reconstruction, not invention.

How to read this. As with the making-of transcripts:

• Terence's messages are shown, mostly verbatim (trivial "next one" replies folded into narration).
• Claude's replies — reading the original .java, writing a reimplementation spec, then coding the vanilla-JS port — are replaced by short italic summaries.
• Interleaved unrelated site work (CV, papers, student pages) is left out.

Unlike the original apps, most ports were driven by a spec-first, per-app recipe run partly through background sub-agents; the shared method matters more than any single exchange.

1. The problem, and choosing a target

Now for a more challenging task. In my applets page I have a list of old applets and similar projects. I am not asking to migrate them at this time — because most of them no longer work! For instance, most of the Java applets use Java 1.0 which are not supported any more by modern browsers. So I would like to port (if possible) the old applets to a modern language (Javascript perhaps?). Is this something that is hostable on the github pages?

As a concrete example, one can start with the vector calculator […] Apple1.html whose code is at Apple1.java. What would be a suitable language to refactor to that could run on the github?

Recommended plain vanilla JavaScript + HTML5 Canvas — no build step, no framework, no dependencies — which is exactly what GitHub Pages serves and what the rest of the site already follows. Ported the vector calculator first as a proof of concept: fetch Apple1.java, rebuild its geometry and interaction in JS, drop it in static/apps/ against the shared applet.css.

2. The recipe

The first port set a template that every later one reused:

• Fetch the original source from math.ucla.edu/~tao/... — the graphical applets are split into a controller class plus a *Grid/canvas class, so both are needed.
• Write a precise reimplementation spec from the Java before coding — field-by-field state, exact control labels, the rendering and interaction contract — so the port reproduces behaviour rather than guessing it. Where a source file was missing, its contract was reconstructed from every call site and flagged as inferred.
• Rewrite in vanilla JS, <link>ing the shared CSS, and flip the catalogue entry from to-port to ported with a url. Use each source's Last-Modified year for the catalogue date.

3. Linear algebra first

We can update the descriptions when the time comes to port. Maybe we can port the linear algebra ones first, since you already did the first one.

Ported the remaining five 2002 linear-algebra applets — Gaussian elimination, a matrix calculator, linear transformations in ℝ², eigenvalues/eigenvectors, and Gram–Schmidt — on the same pattern, all sharing applet.css.

4. Complex analysis, and two shared libraries

Apps seem to work fine. Let's start on the complex analysis ones.

The complex-analysis set (1998–2000) shares far more machinery, so two reusable libraries were factored out first and every later port built on them:

• complex.js — a faithful rewrite of the original Complex.java: complex arithmetic with principal branches and a genuine point at infinity on the Riemann sphere, plus Complex.mobius.
• plane.js — a ComplexStage: device-pixel-ratio sizing, one-to-N square panels with optional per-panel views, math↔pixel coordinate maps, grid/axes, and segment/curve/dot/circle/arrow primitives.

The first two ports (The complex plane, The complex integral) exercised the libraries;

Looks good! I think you can handle the next eight.

…and the rest of the family followed — elementary complex maps, Möbius transforms, multi-valued functions, the complex derivative, Taylor/Laurent series, the fundamental theorem, the residue theorem, and the argument principle. The complex integral port kept the original's pedagogical core: the user draws a contour in the z-plane while the running Riemann sum Σ f(zₖ)·Δzₖ traces a trajectory in the w-plane, and the local action of f(z) on the tangent directions dz=1 and dz=i is shown live.

5. The harder one-offs

Looks great! Let's try besicovitch next.

Ported the 1998 Besicovitch/Kakeya applet — the Perron-tree triangle-sprouting figure whose overlapping sub-triangles point in all directions while the painted area shrinks toward a small bound.

Let's do the exponent calculator one, that one is simpler, and you can make a more descriptive title once you read through it (previously you gave a vague description).

This one was a symbolic engine, not a canvas app: three layers — Monomial → Polynomial → Rational — all with integer coefficients. Monomial.java was absent from the sources, so its contract was reconstructed from every use in Rational.java and Polynomial.java and marked inferred.

Yes. It's one of the most mathematically sophisticated ones, could be tricky but hopefully doable.

The honeycomb applet (Knutson–Tao honeycombs). The port preserved the original's key design decision: the honeycomb is never stored directly — the only state is the dual hive (a triangular integer array), and every vertex, edge and hexagon is derived on the fly from hive differences.

6. Fixing what the ports got wrong

Faithful reconstruction still left a few behavioural gaps, caught by testing against the originals:

Port looks good except the shrink max and enlarge max buttons do not seem to be functional. They're supposed to shrink or grow a hexagon as far as is legally possible, I think.

In the "elementary complex maps" app, there is a weird bug when I select the f(z) = z^3 function — once the mouse is dragged off screen, the app stops rendering the range window curve, even if I change the function subsequently. Only a refresh of the entire web page fixes the problem. Can you try to diagnose?

Fixed both: the honeycomb's "shrink/enlarge to the legal maximum" actions, and a stale-state bug where a pointer leaving the canvas left the range-plane render suppressed until reload.

The ported applets are catalogued alongside the site's original apps, each marked ported and linked to its rebuilt page. They aim to reproduce the originals' behaviour on a modern, dependency-free stack — the 1998–2002 mathematics, running again in the browser without Java.