Personal site. Writing on craft, performance, and the web.https://hasanboy.com/enhttps://hasanboy.com/writing/notes-on-a-slow-website/https://hasanboy.com/writing/notes-on-a-slow-website/Sun, 12 Apr 2026 00:00:00 GMT<p>A friend asked me to look at why their personal site felt sluggish on mobile. Two days, a network throttle, and a lot of receipts later — here's what I found.</p> <h2>What actually matters</h2> <p>The site shipped 480kb of JS for a page that rendered ten paragraphs of text. None of it was used above the fold. The hero image was 3MB and the wrong dimensions for every device tested.</p> <p>Performance is not a vibe. It is the sum of bytes you ship, the number of round-trips you cause, and the work the main thread has to do before paint. Everything else is folklore.</p> <h2>What I changed</h2> <ul> <li>Removed two analytics scripts that competed with each other.</li> <li>Replaced the hero image with three responsive sources at 1x / 2x / 3x.</li> <li>Inlined the critical CSS (~3kb) and lazy-loaded the rest.</li> <li>Killed a 90kb webfont that loaded for a single H1.</li> </ul> <h2>Outcome</h2> <p>First contentful paint dropped from 4.1s to 0.6s on a Moto G4. Lighthouse went from 38 to 96. The site is the same site — it just gets out of its own way now.</p> <p>Owners of fast websites have not made a deal with the devil. They just say no a lot.</p> perfhttps://hasanboy.com/writing/container-queries-one-year-later/https://hasanboy.com/writing/container-queries-one-year-later/Mon, 02 Mar 2026 00:00:00 GMT<p>A year ago container queries shipped in every browser. I've been waiting for an excuse to stop using media queries for component-level layout. Here's what changed in my workflow.</p> <h2>The shift</h2> <p>Before: my Card component had three sizes, each with its own media-query'd breakpoint that assumed it knew what the viewport looked like. It didn't, usually.</p> <p>After: the Card asks its own container how wide it is. It restyles itself based on the room it's actually in. The same component renders differently in a sidebar vs. a full-width grid vs. a modal.</p> <h2>What I learned</h2> <p>Container queries are not a drop-in replacement for media queries. The page-level layout still belongs to viewport breakpoints — that's the right tool for 'is this a phone or a desktop'.</p> <p>Container queries are for components. Use them to make a component robust enough to drop anywhere without rewriting it.</p> <h2>A tip</h2> <p>Set 'container-type: inline-size' on the parent, not the component itself. Otherwise the component can't measure its own children. This took me an embarrassing amount of time to figure out.</p> csshttps://hasanboy.com/writing/on-owning-your-tools/https://hasanboy.com/writing/on-owning-your-tools/Sun, 18 Jan 2026 00:00:00 GMT<p>Every craftsperson I admire has at least one tool they made themselves.</p> <p>Not because the off-the-shelf one was bad. Because the act of making it taught them how the work actually works.</p> <h2>My list</h2> <ul> <li>A markdown notebook that thinks like I think.</li> <li>A color-token system that won't let me typo a hex code.</li> <li>A static-site generator small enough to read in a sitting.</li> </ul> <p>None of these are better than the popular alternatives. All of them are mine. I know every assumption inside them. When something breaks, I can fix it in five minutes instead of opening an issue and waiting six weeks.</p> <h2>Why it matters</h2> <p>When you use somebody else's tool, you absorb their assumptions whether you want to or not. Eventually the tool starts shaping the work instead of the other way around.</p> <p>Build the small thing. Use it for a week. Throw it away if it doesn't help. The point isn't the artifact — it's the seeing.</p> crafthttps://hasanboy.com/writing/view-transitions-in-anger/https://hasanboy.com/writing/view-transitions-in-anger/Sat, 29 Nov 2025 00:00:00 GMT<p>View transitions are the first new animation primitive on the web in a decade that actually changes how I design.</p> <p>I spent a month using them on a real product, not a demo. Here's the unglamorous version.</p> <h2>What they're good for</h2> <ul> <li>Cross-document persistence: an element that exists on two routes can morph between them.</li> <li>Hierarchy reveals: an item in a list becoming the detail view, gracefully.</li> <li>Cheap polish: tasteful crossfades cost two lines of CSS now.</li> </ul> <h2>What they're bad at</h2> <ul> <li>Anything stateful underneath the transition. React doesn't know you're transitioning, so it keeps doing React things and the morph breaks.</li> <li>Long animations. Anything past 400ms starts to feel like waiting.</li> <li>Accessibility. Reduced-motion is respected, but the default API doesn't give you enough hooks to design a graceful fallback.</li> </ul> <h2>My rule</h2> <p>If the transition can't be explained in one sentence — what is changing, and why — it's the wrong tool.</p> webhttps://hasanboy.com/writing/a-type-system-for-color/https://hasanboy.com/writing/a-type-system-for-color/Sat, 04 Oct 2025 00:00:00 GMT<p>Hex codes are an assembly language. They are precise and they are useless for thinking with.</p> <p>I want a color system where the names mean something, where the relationships are explicit, and where I cannot write a contrast bug because the types won't let me.</p> <h2>The shape</h2> <ul> <li>A palette is a set of hues at perceptually-uniform lightness steps.</li> <li>A token is a (palette, role, mode) triple.</li> <li>A theme picks one row from each palette for each mode.</li> </ul> <p>Once that's typed, autocomplete becomes the design system.</p> <h2>What broke</h2> <p>OKLCH made this almost easy. Every step I'd previously eyeballed in HSL became math. The remaining 10% — gamut clipping, browser support, designers who insist on a specific hex — is the boring part.</p> <p>I'd rather fight the boring part with types than fight the interesting part with vibes.</p> designhttps://hasanboy.com/writing/stop-animating-the-wrong-thing/https://hasanboy.com/writing/stop-animating-the-wrong-thing/Sun, 17 Aug 2025 00:00:00 GMT<p>Most UI animation is decorative. Decorative animation is fine. It's also expensive — in attention, in performance, in the cost of getting it wrong.</p> <p>Before animating anything, ask: what is the user supposed to learn from this motion?</p> <p>If the answer is 'nothing, it's just pretty' — leave it out, or make it half as long.</p> <p>If the answer is 'where this element went' or 'that the system heard them' — animate the thing that answers the question and nothing else.</p> <h2>The short version</h2> <p>Motion is a sentence about cause and effect. Most UI animation is a sentence with no verb.</p> motionhttps://hasanboy.com/writing/why-i-write-my-own-components/https://hasanboy.com/writing/why-i-write-my-own-components/Sun, 01 Jun 2025 00:00:00 GMT<p>I have shipped products built on Bootstrap, Material, Chakra, Radix, Headless UI, MUI, Mantine, and a dozen smaller things.</p> <p>For my own work I write the components myself. Here is why.</p> <h2>The library tax</h2> <p>Every component library is an opinion about how UI should work. You inherit the opinions whether you wanted them or not — focus rings, animation curves, ARIA shapes, the bundle size of the framework underneath.</p> <p>Most of the time, the opinions are fine. Sometimes they're great. Occasionally they're a five-day debugging session with no good answer at the end.</p> <h2>What I gain</h2> <ul> <li>Every component I have is one I understand.</li> <li>The bundle is whatever I decided to ship.</li> <li>I can change the focus ring without writing a PR against somebody else's repo.</li> </ul> <h2>What I lose</h2> <p>Speed of the first three days. Accessibility primitives I'd have gotten for free. The comfort of a popular Discord.</p> <p>I still use libraries on client work. For my own things — small, slow, mine — the trade lands the other way.</p> craft