Consider dropping Alpine.js and writing its 19 directive uses directly #163

New Issue

2026-08-17T23:01:56+02:00

clawbot commented

2026-08-17 23:01:56 +02:00

Follow-up to #145, which was fixed by taking option 1 (fetch Alpine at build time under a verified sha256) rather than option 3 (drop it). Not a defect: the build-time fetch fully satisfies the hash-pinning policy. This is the optional further step, deliberately deferred out of the 1.0 cycle.

The argument for it: Alpine is 44758 bytes of third-party code in the admin's browser, and the UI's actual use of it is small — 19 directive uses across templates/navbar.html, templates/source_detail.html and templates/source_logs.html. Writing those directly removes the dependency and its supply-chain surface outright, rather than pinning it.

The argument against doing it in 1.0, and the reason it was deferred: it means hand-rewriting working interactive UI in three pages at the end of a release cycle, trading a solved supply-chain problem for an untested regression risk.

If taken up:

Rewrite the 19 directive uses in plain JS in static/js/app.js.
Remove the <script defer src="/s/js/alpine.min.js"> loader from templates/base.html.
Drop the Alpine entry from static/vendor.sha256 and the Alpine block from script/fetch-assets. Both are built to survive that: static/vendor_test.go iterates the manifest, and .gitignore/.dockerignore entries for the artifact would go with it.
Cover each rewritten interaction with a test, since the point of deferring was regression risk.

Follow-up to https://git.eeqj.de/sneak/webhooker/issues/145, which was fixed by taking option 1 (fetch Alpine at build time under a verified sha256) rather than option 3 (drop it). Not a defect: the build-time fetch fully satisfies the hash-pinning policy. This is the optional further step, deliberately deferred out of the 1.0 cycle. The argument for it: Alpine is 44758 bytes of third-party code in the admin's browser, and the UI's actual use of it is small — 19 directive uses across `templates/navbar.html`, `templates/source_detail.html` and `templates/source_logs.html`. Writing those directly removes the dependency and its supply-chain surface outright, rather than pinning it. The argument against doing it in 1.0, and the reason it was deferred: it means hand-rewriting working interactive UI in three pages at the end of a release cycle, trading a solved supply-chain problem for an untested regression risk. If taken up: - Rewrite the 19 directive uses in plain JS in `static/js/app.js`. - Remove the `<script defer src="/s/js/alpine.min.js">` loader from `templates/base.html`. - Drop the Alpine entry from `static/vendor.sha256` and the Alpine block from `script/fetch-assets`. Both are built to survive that: `static/vendor_test.go` iterates the manifest, and `.gitignore`/`.dockerignore` entries for the artifact would go with it. - Cover each rewritten interaction with a test, since the point of deferring was regression risk.

clawbot referenced this issue

2026-08-17 23:02:37 +02:00

Fetch Alpine.js at build time under a verified hash (closes #145) #164

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/webhooker#163