POC with PocketBase + Templ, HTMX + hyperscript and Tailwind + daisyUI
templ
with PocketBasetailwind
& daisyUI
with templ
htmx
with templ
and PocketBaseOnce these two requirements are met:
$ make deps
$ make
The .vscode
folder is configured to add a Run and a Debug launch commands.
$ go install github.com/bokwoon95/wgo@latest
$ make live
Live mode profits from Make
's multi-process abilities by running three
commands in parallel:
bun run tailwindcss -m -i ./assets/tailwind.css -o ./assets/dist/styles.min.css --watch
wgo -file .go -xfile=_templ.go go run main.go serve :: wgo -file .css templ generate --notify-proxy
templ generate --watch --proxy="http://127.0.0.1:8090" --open-browser=false
This will start templ's hot reload server that allows to automatically refresh the page whenever a template changes without restarting the server. Modifying the templates also changes the CSS file and triggers a page reload by sending a payload to templ's hot reload server. Whenever a go file that is not a templ generated file is changed, the backend restarts too.
Live mode also disables browser caching by setting the Cache-Control
header to
"no-store"
for assets. This ensures the main CSS file is not cached when templ
hot reloads the page.
$ docker build -t ptht:latest .
$ docker run --rm -p 8080:8080 -v $PWD/dockerdata/pb_data:/pb_data --name ptht ptht:latest
As shown in the build workflow section, this project requires both templ, bun and Go to be run in a sequential order. At first a four stage Dockerfile was created:
golang:alpine
to install templ and generate templ go filesoven/bun:alpine
to build the CSS based on templ go filesgolang:alpine
for the rest of the buildgcr.io/distroless/static
to serveThe main issue was that the whole build directory was copied over from one step to another and the cache was invalidated way too often.
The Dockerfile was switched to using golang:debian
(because Bun can't be
installed on alpine distros without glibc) and the bun setup script was used,
which greatly improved caching but removed the ability to automatically bump
bun's version using Renovate.
In the end the chosen solution was to use the oven/bun:debian
image as a
first step and copy over the bun binary to the build step. This way the bun
version is pinned and can be upgraded using renovate.