Max Leiter

Max Leiter's website ·

6 min read Original article ↗

The cover of Ariana Grande's album Thank U, Next: the title repeated in many fonts on a pink background

If you're wondering about this post's title: https://en.wikipedia.org/wiki/Thank_U,_Next

There's been a lot of talk about custom / personal software and LLMs lately. I've been a huge fan -- I'm writing this in a markdown editor I made for myself. And lately I've been toying with thoughts about the future of frameworks. A nice intersection of the two seemed like a personal framework.

So as of September 1st, this website is no longer running on Next.js. Instead, it's built by a bespoke custom framework that Fable architected and Opus implemented. If this were a commercial project, I'd probably stay on Next1, but it's not, so 🤷

This site is overall pretty simple - it's fully static and compiled to HTML at build time. But it has a lot of React and non-trivial build-time processing like MDX. I gave Fable 5 (in the claude code CLI) the following:

i am curious about on-demand coding with AI -- can claude theroetically make an on-demand bespoke "web framework" that is faster than nextjs specifically for this site? can it support the same features we need? can it still deploy to vercel? scope it out for me here and if its feasible we'll ship it - youll coordinate opus subagents. use opus for anysubagents as you are a fantastic AGI-like-but-expensive model. be thorough withit [sic]

~3 hours of work later I had something to look at.

I'll let the numbers speak for themselves:

Before and after

And here's the session stats (a lot of the walltime/duration was my laptop being asleep):

Total cost:            $669.45
Total duration (API):  8h 27m 17s
Total duration (wall): 1d 1h 34m
Total code changes:    20914 lines added, 2022 lines removed
Usage by model:
    claude-haiku-4-5:  272.7k input, 12.8k output, 0 cache read, 0 cache write, 5 web search ($0.3869)
      claude-fable-5:  57.4k input, 165.3k output, 66.8m cache read, 2.8m cache write ($131.09)
       claude-opus-5:  547.6k input, 2.0m output, 562.9m cache read, 32.5m cache write ($537.98)
Prompt cache (main):   195 requests · 95% of input tokens from cache · 6 misses (last 16s ago, 2.5m tokens re-cached) · warm (1h TTL, last activity 16s ago)

It used ~10% of my Claude Code 20x subscription.

Note that I've made some minor changes/improvements since those stats were recorded, but I'd estimate those stats covered 95% of the work.

You can try the Next.js version of this site at next.maxleiter.com.

How it works

  • It's more of a build script. build.ts reads posts/, renders every route to a static index.html with React (on the server), and writes a Vercel Build Output directory. Build time is ~half a second warm on my M2 MBP.
  • MDX compiled once per file at build with the same remark and rehype plugins as before. Syntax highlighting runs at build with shiki, emitting both themes into the HTML so theme switching needs no JavaScript.
  • Zero JavaScript on blog/content pages except a 2 KB inline script that handles the theme toggle, Cmd+K, and lazy island loading.
  • Islands for interactivity. The desktop window manager and the command palette are Preact components that hydrate over server-rendered markup, loaded only on the pages that use them. The palette loads on first Cmd+K. Preact via its React compatibility layer is 7 KB instead of React's 52 KB.
  • Image optimization, immutable asset caching, redirects, and analytics all come from the Build Output API's config and Vercel.
  • Claude wrote a "parity harness." It snapshotted all 101 routes of the Next site and diffed head tags, visible prose, and code blocks against the new build on every change. It found (and fixed) eight unpublished posts leaking into the RSS feed and a 404ing OG image too.

Why do this?

A bunch of reasons. For one, you could recursively run a loop like this and replace most/all of your dependencies, eliminating a host of supply chain attacks. You vendor exactly what you need and nothing else, which is what this framework is — the parts of Next.js this site actually uses. Two, the framework is 5,000 lines; easily reviewable by human and model alike. Next.js and React are hundreds of thousands.

Now, there's something to be said that this could all be a lot simpler if I chose a simpler static site generator, switched to python, whatever. Those are all (mostly) true but this is just a demonstration of the future of software, not just static sites.

Cons

There are many.

  1. I'm sure there are hundreds-to-thousands of minor optimizations and fixes that Next.js handles that the LLM does not know about / cannot reproduce
  2. There are also many intentionally-omitted features, like no framework MCP for agents. Claude-in-Chrome is good enough for me.
  3. Depending on what you replace, you may have stale security issues that would be fixed upstream. That doesn't apply here since this is a static site.
  4. You own it now. Bugs, security issues, and feature requests are now yours to deal with.

Two browser issues that Claude ran into, which Next presumably handles:

  1. Chrome / cross-document view transitions. Chrome silently skips the inbound half of a cross-document view transition when the destination page has an external <script type="module" src> in its <head>. An inline module script doesn't trigger it. Bisected with a two-page control page; it's the reason the runtime is inlined into every page rather than linked.
  2. WebKit / Speculation Rules. Safari hardcodes HTMLScriptElement.supports('speculationrules') to true while only implementing the prefetch half, and it exposes no document.prerendering. So feature-detecting "this browser can prerender" needs both checks.

What does this mean?

I think its fruitless to try reading tea leaves about software engineering. Who knows where models will be in six months, much less two or three years. But I'll try a bit anyways:

Obviously, we'll see an increase in vendoring and agentic-rewrites ("slop forks"2). We're already seeing this: Bun autonomously rewrote from Zig to Rust and Cloudflare did similar with Vinext.

A more far-out take is that frameworks will die out.

What matters, as is evident from the Chrome and WebKit issues above, is the vast knowledge built into frameworks. And that can be distilled into skills or some future standard - perhaps the successor to the framework.


  1. for now, who knows what my opinion will be/where models will be a year from now

  2. https://web.archive.org/web/20260228224244/https://slopforks.com/

Thanks for reading! If you want to see future content, you can follow me on X or subscribe to my RSS feed.