I have a soft spot for interesting design systems. That love traces back to two distinct moments of delight, when I had the privilege of witnessing the birth of what I consider the two greatest design systems ever made: the original Material Design and the original Fluent Design. Note that I am strictly specifying the first iteration here, and by Material Design, I definitely do not mean the version Luke Wroblewski later butchered. What made those two systems stand out back then was their brilliant balance of playfulness, visual richness, and accessibility, all while leaving plenty of expressive room for skilled designers, without turning every piece of software on the market into the exact same flavor of instant ramen.

Behind both was a genuinely sublime fusion of technology and the liberal arts.

By contrast, I have very little love for what followed: Material Design 2, Material You, Apple's Liquid Glass, or Microsoft's current Fluent Design 2. If you will indulge a bit of candid observation, visual design standards across the tech industry are in freefall. The original Material Design documentation was so exquisitely crafted that you wanted to print it out, bind it into a hardcover book, and study it every single day. Today, Google has somehow adopted Microsoft's standards for design documentation, explaining practically zero first principles. Fluent Design 2, meanwhile, reeks of Apple envy so intensely that I genuinely wonder if Microsoft designers carry MacBooks to work every day and never touch their own creations. It has become conservative, sterile, and boring; drop it directly into macOS or iOS, and it would practically blend right in. As for Liquid Glass, it is pure visual gimmickry where novelty and eye candy steamroll every foundational design value, including basic accessibility, leaving users bewildered.

Material Design 2 was a tragic misstep. While it maintained lineage with the original Material, its core flaw was reading too much like an abstract textbook, offering virtually no actionable constraints for engineers. A great design system raises the floor for visual quality without lowering the ceiling. It needs to provide sturdy guardrails for developers building interfaces while leaving enough creative latitude for designers. Thorough, well-considered rules should never completely straightjacket a talented designer (every designer has their pride, after all). Material Design 2 clearly failed to provide that safety net: follow the specification to the letter, and you could still easily end up with an eyesore (just look at Google's own Material Studies). Rather than a practical design system, Material Design 2 felt like an unexecutable philosophy.

To be fair, nearly every one of these systems, old and new, has brilliant moments. The layered shadows of original Material Design, the shape system of Material You (which genuinely rescued us from monotonous card hell), and the light effects, materials, and spatial metaphors of original Fluent Design. These are the kinds of design decisions that spark real joy, the kind you cannot resist fidgeting with and admiring repeatedly once built.

What if you plucked out the finest pieces from each and mashed them together? Could you cook up a brand new Powerpuff Girl? Sugar, spice, and everything nice!

With that wild idea in mind, I ran endless thought experiments. That was my exact motivation when I started writing the Axiom Design System seven years ago.

Frankenstein Components

Extracting the best parts of different design systems and forging them into a unified whole sounds wonderful on paper. Take one step deeper, though, and you run straight into nasty contradictions.

From a pragmatic perspective, the spatial metaphor of original Material Design mapped far better to day-to-day product design. In particular, its shadow system modeled real-world lighting by layering multiple ambient and key light casts with varying blur radii and opacities. The resulting softness gave interfaces the sensation of basking in warm, gentle sunlight, an expression that felt deeply humanistic.

From the standpoint of brand identity and interactive feedback, however, original Fluent Design's Reveal Highlight was unmatched. Beyond injecting playfulness into cold UI chrome, it carried serious accessibility value. When Microsoft's design team discussed the cognitive science and inclusive design behind Reveal, they explained that human retinas and neural pathways have evolved an instinctive sensitivity to light and motion. Painting borders on every single button permanently litters the screen with visual noise and spikes cognitive load. Reveal hides non-essential borders by default, using a gentle glow to illuminate the active focal point while quietly sketching the contours of nearby interactive elements as the pointer nears. This progressive disclosure of boundaries eases information overload, offering immense benefits to neurodivergent users, such as those with ADHD or on the autism spectrum.

The trouble is that marrying these two requires thoughtful reconciliation. Both original Material and Fluent relied on pronounced spatial metaphors, but to my understanding, their Z-axes pointed in opposite directions. Material stacked layers outward toward the user, like sheets of paper piling higher off a desk. Fluent, heavily shaped by Microsoft's ambitions for HoloLens at the time, pushed depth inward into the screen, where acrylic frosted panels functioned like windows peering into a deeper virtual realm.

If you paste these ideas together without digesting their underlying spatial logic and rendering pipelines, you end up with a grotesque Frankenstein's monster, a pile of severed limbs rather than a cohesive design system.

In our current AI-saturated climate, the web is flooded with flashy "effects-driven UI libraries." Virtually none of their components share a visual grammar. Each widget looks completely disconnected from the next, half-copied from one place and half-invented in another, leaving you wondering how anyone could ever assemble them into a coherent design narrative.

Back in the early 2000s, there were these CD-ROMs packed with electronic compilations of "Amazing Web Effects." Just describing them will jog your memory: mouse cursors trailing stars or rainbow text, backgrounds cycling through neon colors, falling digital snowflakes, floating bubbles, scrolling marquee titles, and status bar text trickling by.

They were amusing, but hardly tasteful, exactly like today's stitched-together component dumps. At least those vintage DHTML scripts had engineers obsessing over raw details; today's AI-generated component piles are so crude that basic design principles are violated at first glance. Add in atrocious underlying implementations and abysmal frame rates, and well, that is textbook AI slop.

Unfortunately, the first iteration of Axiom Design System that I wrote seven years ago, despite obsessing over individual effects down to the pixel, fell into that exact same trap: a collection of isolated, fighting Frankenstein parts.

Seven Years

Seven years ago, AI didn't exist. Writing code meant squeezing out hours during grad school and pulling all-nighters alone in my room after clocking out from work. I still remember jogging around the campus track, my head spinning with ways to shave off microsecond rendering bottlenecks and wondering what component to build next.

Using the most straightforward brute-force methods, I hand-rolled the core ingredients of my Powerpuff Girl recipe one by one.

To recreate Fluent Design's Reveal Highlight with tight cursor tracking and zero layout reflows, we drew it directly onto Canvas. To replicate original Material's sunlight-soaked soft shadows, we built the Elevation component; because I hated the rigid integer elevation steps in standard CSS, I extracted all of Google's raw elevation parameters and ran a linear regression fit on them, turning elevation into a continuous, infinitely scalable design token that could smoothly interpolate from zero upward.

I have always insisted on my blog that shadows must not be abused. When you express the physical metaphor of occlusion, a shadow can only ever be black (if you want to express glow, that is another matter). To prevent people from dialing in grotesque configurations that ruin accessibility like Liquid Glass later did, I provided zero color options and locked down light direction completely, exposing only depth under tight constraints.

Combine that with Acrylic, where Microsoft's design docs actually laid out every rendering layer clearly and I reproduced it on the web using client-side pre-baked noise maps; the springy Navigation indicator from the Windows 10 Store that stretched and snapped into place; and the 3D-tilting Pressure component on pressed tiles, and a foundational set of Design Essentials began to take shape.

Yet after frantically churning out this mountain of widgets, everything stalled. Without a unified graphics infrastructure, stitching these parts into an integrated system was an architectural nightmare.

The first head-on collision happened over geometry. When I first built Reveal Highlight, it only supported sharp rectangles, mirroring the square tiles of Windows 10. Later, people kept asking for rounded corners, so I gritted my teeth and calculated rounded rectangles inside Canvas (sitting in front of my desk at 3 AM with pen and paper deriving coordinate formulas with tears in my eyes, more intensely than I ever studied geometry in high school). Later still, following an early CSS Border Decoration proposal, I hand-calculated inverted concave corners, producing postage-stamp-like borders. Just calculating sharp rectangles on Canvas was painful enough; getting rounded and scalloped corners to work was an ordeal I shudder to remember.

You can draw paths on Canvas, but what about Acrylic? Canvas cannot reproduce a live CSS backdrop-filter background blur. I considered migrating the entire pipeline to SVG, but SVG suffered from worse performance and spotty cross-browser quirks, so progress ground to a halt.

Then we tried layering 3D press tilt on top, and things grew truly hopeless. For one, the moment a component tilts in 3D space, the 2D mouse coordinates fall out of alignment with the Canvas surface; you have to compute an inverse affine transform in 3D space just to keep the spotlight centered. On top of that, Firefox harbored an ancient rendering bug: whenever you applied a 3D transform onto a container stacking context with backdrop-filter blur, its framebuffer completely corrupted. Hovering or clicking caused the screen to flicker violently. That bug lingered unpatched for years (while Mozilla focused its energy on redesigning Firefox into something progressively harder on the eyes).

Engineering architecture was the only way out. I envisioned a unified graphics substrate under all components: light effects, shadows, acrylic blur, and 3D tilt all sitting atop a shared geometric foundation and render scheduler.

The theory was simple enough, but the sheer scope was overwhelming. During the years I stepped away from coding, I constantly turned the architecture over in my head. But my math skills were mediocre, and in the pre-AI era, every line had to be written and debugged by hand. The maintenance burden and cognitive overhead were crushing. Thinking about re-deriving the geometric algorithms across every component, aligning Canvas and SVG primitives, and fighting esoteric browser quirks (Chromium's Web Component implementation of CSS Typed OM used to drop value updates under certain race conditions), my passion ran dry. So the idea remained suspended in limbo for seven years.

Recently, while preparing job applications, I needed to showcase a real design system, and this was the only one I had. I figured that since I had to overhaul it anyway, I might as well summon Claude Opus to finally bring this dream over the finish line.

The Infrastructure

Turning isolated components into an orderly design system required shared standards: unified render scheduling (Surface), a unified geometry engine (Shape), and a typed design token parser (Typed OM).

Claude Lending a Hand

To kick things off, I handed the old Reveal Highlight codebase over to Claude Opus and asked it to audit my rendering pipeline for performance leaks.

Remember, I had poured weeks into squeezing out every drop of performance back then, consulting game engine developers and convincing myself every pixel path was fully optimized. Opus looked at it and, within five minutes, delivered its verdict: "Something is off here. Your task scheduling has layout thrashing; you are interleaving reads and writes unnecessarily."

In what felt like seconds, it handed me a refactored implementation alongside benchmarks, boosting render throughput by over 20x.

I was stunned.

I felt like an absolute idiot. What on earth was I doing burning the midnight oil back then? Turns out time really does fix everything.

To push performance even further, the library incorporated techniques from my earlier work on web infrastructure, taking control over component rendering lifecycles, establishing a frame budget, and introducing prioritized scheduling so canvas rendering never stalls other tasks and remains perceptually fluid.

The Geometry Engine and Dual Renders

As mentioned earlier, the first priority was isolating geometry into a dedicated infrastructure package so every module could share identical drawing logic. That became the Shape package. Axiom Design System is built on Web Components, so design tokens naturally map to CSS custom properties. As a rule of thumb, the fewer imperative JavaScript APIs you expose, the better. I had specific opinions on token naming: border-radius feels like an inadequate descriptor for corners, especially when corners and borders each support distinct decorative treatments.

Specifically, borders can scoop inward or jut outward as semicircles, rectangles, or triangles. Corners can be rounded, chamfered, scalloped, or notched. These decorations feature configurable "shoulders." For instance, an inverted concave corner naturally produces a sharp vertex where it meets the edge; you can independently round off that shoulder. This allows you to compose an endless variety of shapes. Carve a V-notch or a protruding spike into a border, and you have a speech bubble or a Material Shape bun effect.

I had pondered this geometry system for years, but my math was far too rusty to implement it from scratch. Now I finally could.

I walked Opus through my design ideas, and it offered several sharp corrections. For example, it pointed out that applying independent 2D offsets to the four corner vertices could produce parallelograms cleanly without having to contrive an overly complex border-skewing decoration. Its suggestion made total sense, so I had it draft the API schema. I supplied the mental models and the formal spec outline, and it translated them into a production-grade implementation.

When it came to parity between the Canvas and SVG implementations, Opus's multimodal capabilities shone. I fed it the requirements, and it churned out code with terrifying speed, rendering both outputs on top of each other and pixel-peeping to verify sub-pixel alignment. It made the entire process effortless.

My feelings at that moment were complicated. The geometric dilemmas that had plagued me for years were flattened in thirty minutes as if by a diesel bulldozer.

The project was still mine, yet it no longer felt entirely mine. The sheer velocity of Opus made me feel small, like an ordinary mortal staring up at a titan.

Regardless, we had working code.

System Integration

With the Shape engine and Typed OM tokens in place, rolling them across our remaining components became straightforward.

Once the foundation was laid, complex geometric contours previously confined to lighting effects instantly unlocked for shadows, acrylic blur, and navigation indicators alike.

Navigation Indicators

Plugging the geometry engine into our indicator bar was delightful. What used to be a mundane rectangular strip could now take on rounded corners, morph into parallelograms, and execute expressive motion.

Here is an example feature we added: as the indicator glides between tabs, the leading edge dynamically extrudes an arrow-shaped tip, darting forward like an arrow before smoothly retracting into a clean edge the instant it settles at its destination.

To protect developer experience, we carefully drew token boundaries. Static geometry inherits directly from the Shape system, fulfilling our promise of universal shape reuse across the library. But for the morphing arrow animation, we took a more opinionated route.

Our reasoning was practical: on a slender bar only a few pixels tall, minor edge morphing is a subtle flourish. Designers rarely want to hand-tune esoteric motion curves or duration timings for such micro-interactions. Dialing in those timing curves is notoriously fiddly; after hours of tweaking, I found that even slight missteps caused jarring, jittery twitches. Rather than burdening developers with that friction, I exercised a bit of design tyranny: I locked down the morph timing internally, powered it with linear interpolation (Lerp), and exposed only a damping factor to govern convergence speed. You pick your shapes and morph intent; the mathematical execution remains safely encapsulated.

On the indicator, I collaborated with DeepSeek to address a small interaction detail Microsoft overlooked back in the day: animation interruption.

Original Fluent navigation indicators felt delightfully snappy, snapping forward like an elastic band. That tactile pop came from driving the leading and trailing edges along independent cubic Bezier curves, elongating the strip before snapping it back into shape. But Bezier curves have an architectural weakness: they assume fixed start and end points. Redirecting an in-flight Bezier curve midway to a new target is messy and often looks unnatural.

Microsoft's solution back then was unapologetically blunt: give up and snap. If a user clicked another tab midway through an animation, the indicator simply jumped to the new position. You cannot call it broken, but it felt unpolished. Direct positional snapping felt clumsy, so I implemented a dual-mode system: uninterrupted clicks follow the precomputed Bezier path (Mode A) to preserve that crisp kinetic snap; the moment an interruption is detected mid-flight, the engine transitions instantly to linear interpolation (Mode B). Because Lerp computes incremental motion toward the target on every frame, it gracefully accommodates changing destinations on the fly.

A charming detail here: under Lerp mode, we preserved the asymmetric expansion and retraction by offsetting the leading and trailing edges slightly. Even though the underlying math changes and the tactile feel shifts subtly, this ensures that no matter how frantically you click between tabs, the animation remains uninterrupted and smooth.

Pressure (and Firefox's Spiritual Pressure)

The rest was relatively smooth sailing, but right before wrapping up the project, I ran into the final boss: the 3D pressed tile effect, Pressure.

The main reason I failed to unify press-tilt, acrylic blur, and lighting seven years ago was that Firefox and 3D coordinate transforms had me completely pinned against the wall. This involved a vintage bug inside Firefox's rendering engine. It was alive and well when I wrote version one seven years ago, and to my disbelief, seven years later it remained untouched (Mozilla, could you please do something useful for once instead of constantly redesigning browser chrome and making it worse every single time?).

Specifically, within the same 2D coordinate space (whether nested or stacked), if you apply a CSS 3D transform on top of an element with backdrop-filter acrylic blur, any mouse movement or press that triggers a repaint causes Firefox's framebuffer to completely corrupt. The entire viewport starts flickering violently.

Back then, I smelled trouble and shelved the whole feature, which meant Tile never truly shipped. This time, with deadline pressure mounting, I had to see it through. I teamed up with Kimi and Claude and pulled a grueling all-nighter, burning through over 150 RMB in API tokens alone. This is not work you can delegate to lightweight models; even Opus had moments where its reasoning grew hazy.

Claude delivered half the puzzle: if handling CSS-level 3D transforms was this fraught, bypass CSS container transforms entirely. Push the 3D tilt calculations directly down into the graphics layer. In other words, recalculate the 2D anchor coordinates mathematically so the resulting flat polygon produces the optical illusion of 3D perspective.

As for the remaining half, lacking insight into Firefox's C++ internals, we had to brute-force permutations, CSS configurations, and nesting hierarchies. For frontend engineers, debugging a browser engine bug often feels like talking to Cthulhu. Only once in my life have I diagnosed an engine bug by reading browser source code; every other time has been grueling trial and error. In the pre-AI era, it was pure agony.

I will spare you the excruciating trial-and-error details. The eventual fix: under Firefox, keep the text content container completely flat, applying the calculated perspective tilt solely to the acrylic backdrop, border glow, and shadow paths (computed via coordinate math, not CSS 3D). Because the press tilt angle is intentionally restrained, watching the outer contours deform according to perspective rules is more than enough to fool the human brain into perceiving genuine physical depression.

Either way, we hacked our way through it (apologies to purists).

Shadows

Elevation is another component where I deliberately traded performance for visual fidelity.

In this iteration, we switched shadow rendering over to Canvas. The primary motivation was eliminating edge jitter under fractional display scaling. When your operating system runs at fractional scale factors like 125% or 150%, native CSS box-shadows produce discontinuous edges during animation. Watch closely, and you will see the blurred edges flickering and twitching. By painting our own shadows onto Canvas, we exert pixel-level control over alignment, ensuring that shadows animate continuously across any display scaling factor and eliminating that annoying artifact for good.

Considering that original Windows 10 tiles never featured drop shadows in the first place, I consider the modest rendering overhead a worthwhile trade-off.

The Horizontal Scroll Reel

Websites featuring horizontal layouts invariably run into the same headache: mapping vertical scroll input to horizontal viewport movement. The devil is in the details: standard mouse wheels are manageable, but how do you handle trackpads? What about inertia and smooth scrolling? We packaged those messy edge cases into our Scroll component.

Translating vertical wheel input into a naturally unwinding horizontal reel was something we had wanted for years, but never found the bandwidth to componentize. Recently, horizontal scrolling has become a quiet trend across a niche circle of indie bloggers. I share the view that horizontal presentations offer higher information density and better spatial efficiency with less cognitive friction. To ride that wave, I previously went out of my way to hack it into my own blog (quietly tucked inside a sidebar widget). Back then, it remained just that: a one-off blog widget. If not for the pressure of overhauling Axiom Design System, I probably would never have extracted it into a reusable component in this lifetime.

The Start Menu

The other piece was recreating Windows' beloved live tile layout, Tile Group. When it came to prompting this component into existence (yes, Claude wrote it, not me), Claude Opus displayed an eerie level of capability.

Years ago, I attempted multiple implementations of the Start Menu's layout and drag-and-drop mechanics, all ending in defeat. Packing heterogeneous tile sizes across multi-column grids while calculating real-time collision avoidance during drag operations is notoriously difficult. No matter how I tackled it, the spatial permutations broke my brain, and searching online yielded virtually zero actionable references.

When I presented Claude with the specification, it casually responded: "I cannot find existing references either, but from what I recall, it should be approached like this." And based purely on this supposed "recollection," it wrote the entire packing layout and real-time collision avoidance engine from scratch. It worked on the very first try without a flaw.

From what it recalled? In an area where not even technical documentation exists, where on earth was it recalling this from?

Damn it, that is just spooky.

Postscript

After ironing out all these intricate mechanics, I barely slept for two straight days, constantly polishing details and patching boundary edge cases. Seeing the complete system come alive was deeply rewarding. You can compose an incredible variety of seriously slick designs with this geometry engine, and real-world benchmarks show performance is comfortably within acceptable margins. A long-standing debt has finally been repaid.

Yet after walking this road, I cannot help but reflect on human insignificance.

Back in the day, achieving full parity on a plain square Reveal Highlight took months of sleepless nights, with several community friends helping debug race conditions and tune bundler configurations just to ship an MVP. Today, a bug that took months of human suffering gets squashed by Claude in a single glance. Pulling a two-day sprint was exhausting, but manual parameter grid searches would have taken a human weeks. With modern multimodal models, debugging is remarkably low-friction: the model spins up a browser, edits code, captures screenshots, and iterates autonomously, while I sit back, review, and inject domain intuition.

Fairness demands acknowledging that if we had not spent months seven years ago pixel-peeping, fitting regressions, and deriving coordinate math, or if I had not clearly deconstructed the graphics architecture in my head, handing raw prompts to an LLM today would never have yielded such precision.

As I argued earlier: half-baked Frankenstein effects are the worst thing imaginable.

Still, even understanding all of that rationally, you occasionally cannot help but feel an existential shudder, without even knowing what you are despairing about.

That wraps up today's technical dispatch. If you are curious about the overhauled graphics engine and component suite, feel free to explore the Axiom Design System site or poke around the GitHub repository.

Thank you for reading this far. May your tests pass on the first try and everyday life treat you kindly.