Why I Built Hyper-Dank

I didn't set out to build a framework. I mostly wanted my own small web projects to be less annoying.

This blog is now one of those projects. It is built with Hyper-Dank: the name I gave to the set of patterns and libraries that grew out of my experiments with HTMX, Hono, JSX and Bun. The name comes from Hypermedia and HyperText, the core foundations of the framework, and DanK¹, which is me. It's also, conveniently, a good excuse to explain why I built it in the first place.

How I Got Here

I'm not from a software engineering background. I got a thoroughly practical degree in philosophy and, naturally, ended up in customer service.

I stumbled upon programming in my 30s when I learnt a little as a hobby, mostly to help me run my D&D games with software instead of spreadsheets. I didn't start my consultancy career with the foundations that come from studying computer science, so I had to learn a lot on the job. Sometimes that meant breaking something in production and having a senior dev, admirably calm in the circumstances, explain what I had borked, how to fix it, and how to avoid doing it again.

In my five years as a developer, I've learnt many things:

• to value clarity over cleverness; let the code be so simple that when I come back to it in a year, having forgotten all about it, I'll be able to take a quick look and understand how it works.
• the value of simple contracts, mostly by having to wrangle multiple repositories creating a multitude of apps and leaving a sadly unappetising tangle of connections in their wake.
• software keeps changing, and if you're going to work in it, you have to keep updating your skills, learning new ones and, most importantly, using them.

I've ended up working across the stack, but the front end is where I have the most fun. My main joy in coding is building web apps with the unholy trinity of HTML, CSS and JS, though I also know how to deploy, structure and maintain back-end services. Jack of all trades, master-in-training of a few.

That has usually meant working with cumbersome frameworks like Angular and messy-but-powerful libraries like React.² They're capable tools, and I've learnt a lot from them, but they can also make simple things feel like they require a committee, a build graph and three new tabs of documentation.

The API Fog

When I became a software developer, APIs confused the heck out of me.

Not the idea in the abstract. I could understand that one system asked another system for something. You type in a URL with some path parameters, hit enter, and you are making a request to a server somewhere hosting that API. Simple enough. In practice, however, it often felt like the simple act of pressing a button had become a tiny diplomatic incident between the browser, the server, a JSON payload, a client state tree, some hydration logic and whatever mood the front-end framework was in that morning.

Then I heard about HTMX.³

The pitch landed immediately: bake requests into your HTML, send them to the server and get HTML back. Not JSON that you then use to rebuild some element. Not a client-side reconstruction of a thing the server already knew how to render. Just HTML, returned to the browser, swapped into place.

I loved that idea. I loved it enough to try convincing people at work that it would suit some small production clients. Alas, professional life contains the phrase "interesting, but not for this one" in many different hats. So HTMX became something I used in my own private projects instead.

Finding the Pattern

At some point I read Hypermedia Systems.⁴ That gave a name and shape to things I already liked: server-driven applications, progressive enhancement, HTML as an application medium rather than a decorative transport for JavaScript.

I also read Server-Driven Web Apps with HTMX.⁵ That book gave me another piece of the puzzle. The examples in Hypermedia Systems helped the concepts click, but they used Python, and I knew JavaScript and JSX much better. Server-Driven Web Apps with HTMX showed me a route into the same territory with Bun and JSX, which made the pattern feel close enough to use.

After that, my small projects started to rhyme.

HTMX for interactions. Hono for routes. JSX for server-rendered components. Bun for the runtime and tooling.⁶ A route would own the request. A component would own the markup. HTMX would ask for the smallest practical fragment. The browser would do browser things, the server would do server things, and nobody needed to pretend that a click was an existential crisis.

The idea of turning that pattern into a proper framework, or at least a small suite of reusable libraries, sat in the back of my mind for a while. It was one of those 'this would be rad, but who has the time?' ideas.

Along came a Codex

With Codex, everything changed.⁷

I shifted, at least some of the time, from developer to project manager. Not in the bleak meeting-room sense. More in the sense that I was suddenly wrangling agents on my local machine: asking them to write patches, run tests, tighten rough edges, check regressions and keep moving through the boring middle stretch of implementation. I was orchestrating a team of programmers, letting them go off and work on tickets while I worked on my own, and coming back to review and guide their work when I had the time.

The important bit is that Codex arrived after the experiments. I fed it the tricks, lessons, pain points and patterns I had picked up from Bun, JSX, HTMX and Hono, plus software development and life in general. Every small frustration became a prompt. Every repeated route helper became a candidate for extraction. Every little 'I keep doing this again' became evidence that there was a library-shaped space waiting to be named.

I started with a walking pace experiment app. Then I started thinking about building my own D&D campaign tracker. Those projects had the same bones. The same little route helpers. The same component shapes. The same need for local verification scripts. The same recurring question: why am I copying this again?

That was the moment Hyper-Dank stopped being a someday idea.

Codex made it realistic to extract the repeated pieces into libraries I could use across any hypermedia app built with Hono. It didn't remove the need for taste or judgement. If anything, it made those more important. It did, however, change the cost of doing the careful, unglamorous work.

I set up a whole Hyper-Dank workflow, getting Codex to create epics and tickets, fleshing them out with my input and feedback, and then working from those Markdown files for implementation. All that time cursing Jira and Confluence had, irritatingly, paid off.⁸

I had learnt the process not just of writing code, but of how software gets developed: several people working together from a set of plans to create a viable product. All that knowledge fed into a system for working with AI as a tool I could use to realise my ideas, rather than replace my imagination.

What Hyper-Dank Is

Hyper-Dank is a small set of libraries and conventions for building server-rendered, hypermedia-first apps.

It is not trying to hide the web. It is trying to make the repeatable parts easier to reuse.

At the moment, the core pieces are:

• @macavitymadcap/hyper-dank-ui, for reusable server-rendered JSX components.
• @macavitymadcap/hyper-dank-transport, for Hono and HTMX request helpers.
• @macavitymadcap/hyper-dank-automation, for repeatable scripts, verification, local server checks and static-site support.
• @macavitymadcap/hyper-dank-data, where an app genuinely needs shared data or provider lifecycle helpers.

The important bit is the boundary. Hyper-Dank should own repeated mechanics. The app should still own its domain, routes, copy, content, permissions and taste.

This blog is a concrete example. It uses the Hyper-Dank app shape, components, transport helpers and automation scripts. But the posts are still just posts. The voice is still mine. The content model is deliberately small. GitHub Pages still gets a static export because a personal blog does not need a server sitting around feeling important.⁹

The Problems It Solves

Hyper-Dank solves the problems I kept meeting in my own projects.

It gives me a familiar app shape: createApp() builds the route tree, the runtime entry point wires dependencies, and tests use the same app factory as production.

It gives me reusable components without making every app look or sound the same.

It gives me HTMX helpers so routes can choose between full pages and fragments without re-writing the same detection logic.

It gives me automation for the bits that should not depend on my mood: verification gates, static export checks, local server readiness and accessibility testing.

Most of all, it gives me a way to build small and medium web apps that remain visible. When I'm working in Angular, I often feel the weight of the framework before I get to the feature. When I'm working in React, I often feel the sprawl of the surrounding ecosystem before I get to the page.¹⁰ Hyper-Dank is my attempt to keep the practical parts of modern web development without dragging a full enterprise toolchain into every side project.

I can see the request. I can see the response. I can read the HTML. I can test the route. Everything a growing dev needs.

Still Very Much in Motion

Hyper-Dank is live, but it is still in motion.

I don't think frameworks arrive fully formed unless they've been focus-grouped into paste. This one will get better by being used. I'll build more apps with it, find the rough parts, change the libraries, sharpen the docs and probably regret at least one name.¹¹

This blog is part of that process. It is both a place to write about the work and another test of the system itself. If Hyper-Dank starts turning into the kind of cumbersome framework I was trying to escape, or the kind of messy library ecosystem where the answer to every problem is another package with a logo, I want this blog and the apps built with it to make that obvious early.

If you want to follow along, the Hyper-Dank docs, source and package pages are now public.¹² I'll write more about the individual libraries, the app patterns and the bits that turn out to be either clever or embarrassing once they've survived contact with real projects.

TL;DR: I built Hyper-Dank because I wanted web development to feel direct again.

HTML asks. The server answers. The page changes.

Sometimes that is enough magic.