From Waku to Next.js to Phoenix

I’ve rebuilt this site a few times. Waku was a fun way to prototype, Next.js was a safe harbor for a while, and Phoenix ended up being the calm, boring foundation I wanted.

Why move at all? I wanted fewer knobs, faster pages, and a single place to run everything - routing, templates, tiny background jobs - without gluing together a bunch of services.

Waku

• Fast to build and iterate.
• Drifted under me as things changed; a few SSR edges made simple pages feel fiddly.

Next.js

• Rock solid, great docs and deploy story.
• For a mostly‑static site, the build/pipeline felt heavier than I needed.

Phoenix

• One runtime. Simple HEEx templates. No mystery.
• Easy to sprinkle in small realtime bits and background tasks without turning the site into a SPA.

What I shipped

• Markdown posts in priv/blog with a tiny frontmatter.
• A small reader that parses Markdown and renders HTML.
• A view counter backed by Redis.
• A very small sitemap endpoint.

What got better

• Fewer moving parts and fewer surprises.
• Deploys are predictable and cold starts are consistent.
• Writing is just “open a .md file and commit”.

Trade‑offs

• If you want React everywhere, you’ll miss it. I still use JS where it helps, but the default is server‑rendered templates.

What’s next

• Maybe an RSS feed, a drafts flow, and a couple of tiny realtime widgets.

That’s it. If you’re deciding between frameworks for a simple site: pick the one that makes you want to write. For me, that’s Phoenix right now.