Template engines exist so designers can edit HTML. Designers haven't touched your Jinja files in two years. You're running an interpreter inside your server for an audience that left.
~/ 20 posts
The renderNode function is the most complex piece in the pipeline. It walks the component tree, decides what to re-render and what to skip, and orchestrates the entire frame. I extracted it from minified JavaScript, and the architecture is beautiful.
Your /health endpoint runs through 12 middleware functions to return {ok: true}. Your architecture is doing a pull-up, a squat, and a mile run before it's allowed to say I'm fine.
Claude Code doesn't render directly. It records what it wants to do, then replays the recording. This decoupling is what makes blit, clip, and scroll optimizations possible — and it's the reason 95% of the screen costs zero work per frame.
Your framework didn't remove complexity. It hid it somewhere you can't find at 3am when everything is on fire.
The moment you intern a style, comparison becomes integer equality. The moment you cache the transition between two styles, rendering becomes a hash table lookup. This is where Claude Code's renderer goes from fast to unreasonably fast.
How do you fit a character, a style, a width, and type safety into exactly 8 bytes? Claude Code uses bitfield surgery. We use phantom-tagged IDs and static_assert. Both compile to one cmp instruction.
Every terminal UI, no matter how complex, reduces to filling a 2D grid of cells and diffing it against the previous frame. Claude Code uses a dual-view memory trick to make this fast. In C++, we don't need the trick.
Two threads. One stdout. Total corruption. This is the bug that sent me reverse-engineering Claude Code's binary — and the fundamental reason every serious TUI needs a rendering engine.
I decompiled Claude Code's binary, reverse-engineered its terminal rendering pipeline, and rebuilt the whole thing in C++23. This is the story of what I found inside — and how to build a flicker-free, 60fps terminal UI from scratch.
Major improvements to the markdown parser — proper fenced code block handling, heading IDs with anchor links, lazy image loading, and performance tuning across the board.
Twelve posts of theory. Now we build. A complete, type-safe, zero-overhead domain-specific language — using every tool the compile-time language has taught us.
The compile-time language has been blind — it can compute with types but can't look inside them. C++26 reflection changes that. The compiler is about to hand you the keys to the AST.
Concepts aren't just prettier SFINAE. They're the type system of the compile-time language — named, composable interfaces that tell the compiler (and the reader) what a type must be.
constexpr started as a way to mark simple constants. Then it grew. And grew. Now it's an entire execution engine inside the compiler, running real algorithms with loops, branches, allocations, and exceptions.
The compile-time language's error messages are notoriously awful. But you can control them — static_assert, concepts, and careful design turn compiler vomit into helpful diagnostics.
String literals live at compile time. With the right tools, you can parse them, validate them, and turn them into optimized code — all before your program runs.
Runtime C++ has std::function and lambdas. Compile-time C++ has metafunctions and template template parameters. Same idea, alien syntax. Welcome to functional programming with angle brackets.
An honest side-by-side of three blog engines — what each does well, where each falls short, and why they exist.
Template specialization isn't just an override mechanism. It's the compile-time language's pattern matching — it takes types apart, examines their bones, and lets you react to their shape.