carlos / todomvc-bakeoff Public

Clone
git clone https://amadan.net/carlos/todomvc-bakeoff

Plain git — no account needed to clone.

Download

Download this file

LIVE https://todo-swift.bfj.oncarlos.com 354c88a

Checked

  • make test: 21 Swift Testing tests pass.
  • Shared suite against dist/app --listen 127.0.0.1:<port>: 67 passed, 3 skipped (the suite's own skips: blur and Escape need JavaScript, and the screenshot is compared with JavaScript on only).
  • scripts/boot-check.sh dist/app-linux-arm64: /healthz and /api/version 200 (354c88a), clean exit on SIGTERM.
  • make deploy: shipped and promoted 354c88a to edge, and /api/version on the live host reports it.
  • Shared suite against https://todo-swift.bfj.oncarlos.com: 67 passed, 3 skipped.

Notes

  • Stack: Hummingbird 2 and SQLiteNIO (which compiles SQLite 3.54 in), built with the Swift 6.2 Static Linux SDK. The arm64 binary is static, stripped, and 22 MB. Turning off Hummingbird's FullFoundation trait and importing only FoundationEssentials took it down from 66 MB.
  • A cold make build-arm64 takes a few minutes here; an incremental one after make bump recompiles one file.
  • Nothing in the contract needed a deviation.

Review round

Both findings are fixed in static/app.js (commit 354c88a):

  1. Typing during an add. The form is read and the new-todo input cleared when the form is submitted, not when the answer arrives. A second Enter while the first add is still pending is queued, not dropped. Each edit is saved once, guarded per item, instead of blocking the whole form.
  2. Stale snapshots. Actions go through one promise queue, so they reach the server and come back in the order they were made, and the last swap is always the newest state.

Checked by hand in Chromium with Playwright, with the first response held back 800 ms. Adding "first", then "second", then typing "third" left both items saved and "third" still in the input. Toggling two items quickly left both completed, with "0 items left". The shared suite passes locally (67 passed, 3 skipped) and against the live host (67 passed, 3 skipped).

The first make deploy was refused with "too many uploads" (a platform-side rate limit). My retry loop then shipped the same 354c88a build several more times, which was harmless.