react-brainCurated reading
123 deep-dives, every one fetch-verified and annotated with why it matters — organized by the decision it informs, not by publish date. The annotations are our editorial take; the articles are the originals — read them there. A piece lands here only if it's the canonical explanation for its topic; how-to content routes to depth skills instead.
React & language foundations
react-core — React core — version, Compiler, RSC, concurrent features
The hidden cost of React.Activity
The when-NOT-to caveat behind this entry's <Activity> row: hiding preserves STATE but destroys and re-creates EFFECTS on every toggle — so effect-shaped work (keyboard subscriptions, analytics, listeners) piles up subscription/setState waves each time a hidden RN screen is shown again.
Pair <Activity> with disciplined effect cleanup or don't use it for effect-heavy subtrees.
How to Build the Fastest Apps: Break the Rules (App.js Conf 2026)
Reframes rendering cost as the dominant hidden bottleneck: React's `render` doesn't just paint — it passes state down, updates context consumers, fires effects, and re-subscribes queries, so ordinary patterns (lift-state-up, effects-for-coordination, `useContext` on a whole value, deps-array callbacks) cascade renders top-down (measured ~10x CPU top-vs-leaf).
The React Compiler can't save you when a prop *actually* changes. The prescribed toolkit — `useEffectEvent`/stable event callbacks (no deps-array cascades), imperative APIs over hooks (get-a-value + subscribe instead of re-render), `use-context-selector`, and providing *stable* objects through Context — extends the Erikson rendering guide below into a 'render once' discipline. Vendor angle (pitches Legend State), but the render-model reasoning is framework-agnostic. See RB-E-STATE for the state-architecture half.
A (Mostly) Complete Guide to React Rendering Behavior
The end-to-end explanation of when and why React renders — render vs commit, reconciliation, the cascade to children, memo/useMemo/useCallback, Context behavior.
The mental model that makes the React Compiler's auto-memoization comprehensible rather than magic.
Writing Custom Renderers for React
How React's reconciler connects to a host environment (the renderer interface), and why React Native Testing Library needed its own renderer.
The canonical explanation of React's renderer architecture.
Component Architecture for React Server Components
Traces the move from useEffect/React-Query/route-loaders to component-level RSC data fetching, with durable principles: component autonomy, deliberate Suspense boundaries, skeleton co-location.
RSC architecture from a recognized educator.
Building Bulletproof React Components
Ten component-design patterns for SSR/hydration, multiple instances, concurrent rendering, portals, view transitions, and tainting (useId, React.cache, taintUniqueValue).
A durable component-API mental model from an authoritative author.
Understanding why React Fiber exists
Traces React 15's non-interruptible recursive reconciliation to Fiber's linked-list + time-slicing design — the 'why it exists' explainer for concurrent React.
First in a React-internals series (key-prop, state-updates, out-of-order streaming also available).
How does React Fiber render your UI
A first-principles walk through Fiber's four phases (trigger/schedule/render/commit), the fiber-node shape, time-slicing, and the bitmask lane-priority system.
Durable internals knowledge that survives version churn.
Two React design choices developers don't like (but can't avoid)
A competing-framework author argues deferred state commits and effect dependency arrays are forced by async UI, not arbitrary — even signal-based frameworks hit the same wall.
An unusually credible mental model for React's most-griped-about choices.
React Compiler at Eighteen Months
You ship the React Compiler — know the bail-out patterns and keep existing useMemo/useCallback in place (removal can change compiler output); this retrospective is the staged-adoption map.
An 18-month retrospective: how auto-memoization retired the missing-dependency bug class, the five patterns where the compiler bails out, and a staged adoption path. The mental model for the compiler era (complements the official release post in sources).
rn-versions — React Native release timeline — what each version changed
React Native Architecture: From Bridge to Fabric
Traces RN's architecture from the old async JSON bridge to the New Architecture (JSI, Fabric's immutable C++ shadow tree, Turbo Modules, Codegen), explaining why each piece exists.
The 'why it changed' narrative behind the 0.76→0.82 version arc — not a release note.
typescript — TypeScript rigor & public API typing
Why does tsgo use so much memory?
A heap-level investigation of the Go TypeScript compiler — per-thread Checker duplication, never-freed types, symbol duplication, AST at 45% of heap, plus a fix.
A durable deep-dive on TS7/tsgo internals and its concurrency model's cost.
TypeScript Performance in TanStack Table V9
Concrete techniques to cut type-instantiation cost 62-86% (feature maps, materialized interfaces, in/out variance annotations, explicit type args), with measurements.
The reference for heavy-generics library authors.
Iterating Faster with TypeScript 7
You ship TypeScript — TS 7 (Go-native tsc, ~10x) is stable; migrate incrementally through the TS 6 bridge, then run 6 and 7 side-by-side in CI (VS Code cut type-checking 36s→5s; the blocker was formatter diffs, not type errors).
The production adoption case the tsgo-internals piece lacks: VS Code's ~50-extension codebase cut type-checking 36s→5s (~7x) and editor project-load 60s→10s by migrating INCREMENTALLY — TS 6.0 as a low-churn bridge, then TS 6-and-7 side-by-side in CI (TS 6 still emitting), then esbuild + TS 7 as the default. The surprising blocker wasn't type errors but formatter differences failing pre-commit checks. Evidence that TS 7 (Go-native tsc) is trustworthy for daily use on a large real codebase — if you bridge through TS 6 first.
App architecture — state, data, routing, frameworks
state — Client & server state management
Structural sharing, selectAtom, and why your Jotai atoms re-render too much
You ship Jotai — selectAtom is a trap; decompose objects into primitive atoms and use write-layer structural sharing so atomic state is actually fine-grained (Object.is propagation decides what re-renders).
The first Jotai-specific deep-dive here, for the entry's 'fine-grained atoms → Jotai' clause: Object.is propagation mechanics, why selectAtom is a trap (decompose into primitive atoms instead), and write-layer structural sharing à la React Query. The re-render discipline that makes atomic state actually fine-grained.
How to Build the Fastest Apps: Break the Rules (App.js Conf 2026)
The performance case for signal/observable state.
React's `render` over-orchestrates: `useState`/`useContext` couple state *ownership* with *subscription*, so lifting state up and over-subscribed context cascade re-renders top-down — measured ~10x CPU vs updating one leaf node. The fix ('render once'): create state without subscribing (observables / Reanimated shared values), own it high in the tree, push subscription down so only leaf nodes re-render themselves; provide stable objects through Context so the provider never re-renders; subscribe to derived values, not raw ids. Vendor talk (his own Legend State), but the ownership-vs-subscription principle is framework-agnostic and transfers to Jotai atoms, TanStack Store/Signals, and use-context-selector.
React Query as a State Manager
You ship a client store but no server cache — server state (stale-while-revalidate, invalidation, retries) is a different problem; replicating it in the store is the classic mistake this piece dismantles.
The canonical case for treating server state as its own thing (stale-while-revalidate, staleTime, query-key sharing) so you stop replicating it in a client store. The source of the server-state-vs-client-state split.
Why React Context is Not a State Management Tool
You ship no client store — Context is dependency injection, not state management; every consumer re-renders on any value change, so frequently-changing shared state belongs in a selector-based store.
Draws the precise line between dependency injection (Context), client-state stores (Redux/Zustand), and async/server state — the vocabulary that justifies splitting the problem instead of forcing one tool to do all three.
How is Linear so fast? A technical breakdown
Breakdown of Linear's local-first architecture — IndexedDB as the primary store, optimistic updates, granular observables, aggressive code-splitting, GPU-only animation.
The reference for building instant-feeling client-state apps.
Component Communication Patterns in React Applications
A decision framework for WHERE state should live, keyed by component proximity × data type: props/callbacks for adjacent components, lifted state or composition for siblings, context for slow-changing globals, Zustand for frequently-updated client state, TanStack Query for server data, URL params for view state, events for fire-and-forget.
'Reach for the closest tool that can actually reach the problem, and only move outward when it stops working.' The how-to-choose guide that operationalizes this entry's server-vs-client-vs-view split.
data — Data fetching & caching
You ship TanStack Query — the maintainer's guidance is to structure around queryOptions objects, not per-query custom hooks (composable across useQuery/prefetch/suspense).
Maintainer-authored architecture guidance: queryOptions objects (not custom hooks) are THE abstraction layer for queries — composable, framework-portable, and reusable across useQuery/prefetch/suspense call sites. The how-to-structure companion to 'Why You Want React Query'.
You ship TanStack Router — its loader cache is per-route while Query's is global; the maintainer maps when route-loader caching alone suffices and how to layer both without double-fetching.
The selection question this entry's TanStack rows raise: Router's cache is per-route, Query's is global — when route-loader caching alone suffices, when you want the full query cache, and how to layer them without double-fetching. Maintainer-authored.
You ship an HTTP client but no server cache — hand-rolled fetching hides race conditions, StrictMode double-fires, and stale error states; a server cache (TanStack Query) fixes the class.
Takes a naive fetch-in-useEffect and exposes the five real bugs it hides (race conditions, missing loading/empty states, stale data+error pairs, StrictMode double-fire), then shows how a server cache fixes them. The durable answer to why-not-just-useEffect.
From latency to instant: modernizing GitHub Issues navigation performance
Engineering case study on local-first caching, stale-while-revalidate, service-worker hard-navigation, and preheating vs naive prefetch, with measured percentile gains.
Durable client-side data-caching patterns at scale.
The Best Loading States Are No Loading States
Argues loading UI belongs at the app/route level (transitions + preload-on-hover/intersection) rather than scattered component spinners, using blank regions as a preload diagnostic.
Durable, framework-agnostic data-loading-UX thinking.
use(): the hook that breaks the rules (on purpose)
Deep-dive on the use() hook — unwrapping promises/context at render under Suspense, the promise-identity caching requirement, and why it can legally run conditionally unlike other hooks.
The modern data-fetching primitive explained.
Real-time cache invalidation (SSE + tRPC + Redis + BullMQ)
A full architecture for pushing invalidation EVENTS (not data) over SSE to drive TanStack Query cache updates, with reference-counted subscriptions and horizontal-scaling guidance.
The real-time dimension the other DATA readings don't cover.
p2p — Peer-to-peer / local-first backend (Holepunch · Pear)
Pear by Holepunch — building blocks & architecture (docs)
You ship the Hypercore stack — data is a local append-only log merged by Autobase, indexed in Hyperbee, synced over Hyperswarm; a conventional client cache/REST layer is N/A by design, and these docs are the canonical reference.
The canonical reference for the Holepunch stack — Hypercore (append-only log), Autobase (multiwriter), Hyperbee (B-tree index), Hyperswarm/HyperDHT (discovery), Hyperdrive (files), Corestore, and the Pear runtime. The 'why' behind P2P/local-first; pair with the holepunch-p2p-systems skill for build/review depth.
nav — Navigation & routing
Reverse Engineering ChatGPT Web: How OpenAI Built for a Billion Users
You ship React Router — it runs ChatGPT's web app at billion-user scale (framework mode + streaming SSR), so the stack choice is production-proven; the teardown shows what a tuned RR7 deployment looks like.
Production evidence for React Router 7 framework mode at billion-user scale: ChatGPT migrated Next.js Pages Router → Remix (2024) → RR7 with streaming SSR, TanStack Query seeded from server render, Tailwind 4 tokens, ProseMirror composer — 84KB HTML document, 50-65ms TTFB. The concrete counterweight to 'serious apps need Next.js', and the highest-profile data point behind this entry's React Router when-clause. (4 independent newsletter signals in one week.)
TanStack Router's New Reactive Core: A Signal Graph
The primary source behind this entry's 'signal-based core' claim: the monolithic router.state was decomposed into a graph of independent stores so route changes update only affected subscribers (React navigation 7ms→4.5ms in their measurements).
The architecture under TanStack Router's fine-grained reactivity.
Exploring Inlined Requires: does Expo Router give you screen-level lazy loading?
You ship Expo Router — screens are lazy-loaded by construction, but layouts and the initial route load eagerly and it's sync require, not bundle-splitting; know the mechanism before optimizing startup.
Instrumented proof that Expo Router defers screen loading by construction via require.context() getters wrapped in getComponent thunks — with the precise caveats (layouts/initial route load eagerly; sync require, not bundle-splitting). The canonical explanation of Expo Router's lazy-loading mechanism.
React Router loaders and actions as integration points
You ship React Router — treat loaders/actions as the HTTP-to-domain seam: keep business logic in testable services and reserve loaders/actions for the integration layer, tested E2E.
Frames loaders/actions as the HTTP-to-domain seam — keep business logic in testable services, reserve loaders/actions for the integration layer (E2E). A durable testing/architecture philosophy for React Router.
Deep Links With Authentication in React Navigation
You ship React Navigation — if deep links can land behind auth, the maintainer's routeNamesChangeBehavior 'lastUnhandled' pattern replaces hand-rolled redirect-after-login plumbing.
The redirect-after-login problem: a deep link that lands on the login screen should still deliver the user to the intended screen afterwards. Walks the manual approaches in older React Navigation and the new API that handles it (routeNamesChangeBehavior 'lastUnhandled' re-dispatching the unhandled link when auth state flips). From the library's own maintainer.
Untangling Dialogs in React Router
You ship React Router — model modal dialogs as nested routes instead of local useState/useEffect; revalidation, view transitions, flash sessions, and exit animations then ride the router.
Models modal dialogs as nested routes in React Router 7 instead of local useState/useEffect — covering revalidation, view transitions, flash sessions, and exit animations. A durable routing pattern that generalizes beyond the example.
meta-frameworks — Meta-frameworks (full-stack React)
Who Owns the Tree? RSC as a Protocol, Not an Architecture
Argues RSC is a serialization protocol that enables both server-owned and client-owned trees, contrasting TanStack Start's inversion-of-control with Next.js's server-owned model.
The durable mental model for reasoning about RSC across frameworks.
React Server Components in TanStack
You ship TanStack Start — its RSC model is explicit (createServerFn, renderServerComponent) and still EXPERIMENTAL into early v1; this grounds what Start's RSC actually buys (use-case scoping, bundle-size results) before you lean on it.
First-principles RSC tutorial grounded in TanStack Start's explicit API (createServerFn, renderServerComponent), contrasted with Next.js's implicit model, with honest use-case scoping and bundle-size results.
Moving Railway's frontend off Next.js
You ship Next.js — Railway's 200+-route migration to Vite + TanStack Start (10min→<2min builds) is the concrete decision case for when a client-centric app outgrows a server-first meta-framework.
Migration postmortem — 200+ routes off Next.js onto Vite + TanStack Start (10min→<2min builds), with the reasoning for when a client-centric app outgrows a server-first meta-framework. A concrete decision case study.
You ship Next.js — 'use client' does NOT disable SSR; its real costs are bundle, hydration, and fetch waterfalls, and the server-component-as-prop technique keeps subtrees on the server.
The mental model for the use-client boundary — it does NOT disable SSR — plus its three real costs (bundle, hydration, fetch waterfalls), with measured comparisons and the server-component-as-prop technique. Durable RSC fundamentals.
Next.js 16.3: Instant Navigations (16.3 Preview)
How Next.js closes RSC's biggest UX gap — slow navigations — with Cache Components + a per-route Stream/Cache/Block choice and Partial Prefetching (one reusable per-route shell instead of a prefetch per link).
The durable mental model for server-driven-but-instant navigation; covers a facet the other RSC readings don't. Gated behind cacheComponents/partialPrefetching flags (16.3 Preview, not yet stable — verify before quoting as GA).
Different Hydration and Rendering Strategies
A systematic map of the whole rendering spectrum — CSR, SSG, ISR, SSR, streaming SSR + Suspense, RSC, islands, signal-based fine-grained reactivity, Qwik resumability, and Next 16.3 instant navigations — organized around ONE durable question: the gap between when a page LOOKS ready (HTML painted) and when it WORKS (JS hydrated/executing).
Each strategy is a different trade on that window — ship less JS (islands/RSC), execute it faster (signals), or skip execution (resumability). The mental model that turns 'which meta-framework / rendering mode' into a reasoned choice instead of a checklist; the framing behind this entry's context-keys.
forms — Forms & validation
You ship no form library — often right: React 19 native actions + Zod handle simple forms; a library earns its keep at multi-step wizards, async validation, and field-level re-render isolation. This walks the decision.
The decision arc of this entry in interactive form: a four-jobs mental model (capture, verify, recover, commit), then three archetypes — a React 19 useActionState + server-action + Zod form with no client form lib, a TanStack Form multi-step wizard (schema composition, AbortController async checks), and a field-array editable table with row-level re-render isolation — closing with when native React 19 suffices vs when a client library earns its keep. Covers the native-actions end of the spectrum the other reading here doesn't.
One core, six frameworks, zero runtime abstraction
Shows build-time framework abstraction (a tiny core swapped by a bundler plugin) instead of a runtime adapter layer, so form state uses each framework's native signals.
A generalizable library-design pattern reframing portability vs integration.
networking — Networking & HTTP client layer
react-native-nitro-fetch — architecture & benchmarks
You ship react-native-nitro-fetch — it swaps the fetch engine (Cronet/URLSession: HTTP/3+QUIC, Brotli, disk cache, prefetch, worklet parsing) behind the same API; benchmarks are vendor-run (~23% on their harness), so measure your own hot path.
The README doubles as the layer's best explainer: what actually backs fetch on each platform (Cronet vs URLSession), what HTTP/3+QUIC/Brotli/disk-cache buy you, prefetch-before-navigation, and worklet-side parsing — with their benchmark methodology. Read it to understand the layer even if you keep built-in fetch.
crossplatform — Sharing code across React (web) & React Native
use dom — incrementally migrating web UI to native with React
You ship react-native-web — it's in maintenance mode (2026); don't expand the bet. For incremental web-UI reuse inside native, Expo DOM Components (`use dom`) are the maintained migration path.
Deep-dive on Expo DOM Components and the `use dom` directive — run real web UI inside a native app and migrate to native views component-by-component; covers the Metro bundling, offline support, and honest WebView trade-offs. The primary source for the incremental-reuse path.
AI-Assisted React Native Migration for TV: Lessons From Zattoo
TV/cross-platform RN case study: share until a platform gives a reason to split, telemetry-driven perf, team reorg, and a deflated, realistic account of AI's role.
A concrete companion to this entry's share-by-layer thesis.
desktop — Desktop apps & web-to-native shells (packaging a React web app)
The Conductor Rewrite: what they changed to make it fast
You ship React in a Tauri shell — the Conductor postmortem's wins were structural (SQLite local-first, stable refs killing re-render cascades, virtualization), not memoization patches; fix root causes.
A React + Tauri desktop performance postmortem — SQLite local-first, TanStack Router structural sharing (stable refs killing re-render cascades), virtualization — fixing root causes instead of papering over with useMemo. Directly relevant to React-on-desktop.
A Technical Deep Dive Into the New Raycast
How Raycast ships one React + TypeScript codebase to both macOS and Windows via native shells (Swift/C#) plus WebKit — IPC design, memory breakdown, and concrete WebKit workarounds.
A durable model for cross-platform desktop on React without Electron.
UI — styling, components, animation, lists, a11y, i18n, charts
styling — Styling & theming
Why We're Breaking Up with CSS-in-JS
You ship runtime CSS-in-JS — per-render style serialization has a measured cost (~48% faster renders after dropping Emotion in this benchmark); compile-time styling (Tailwind/StyleX) moves that cost to build.
The canonical runtime-cost argument against runtime CSS-in-JS, from an Emotion maintainer: per-render style serialization is slow (a benchmark shows ~48% faster renders after dropping Emotion). Motivates the move to compile-time / zero-runtime styling.
StyleX: A Styling Library for CSS at Scale
You ship StyleX — its Babel compiler extracts deterministic atomic CSS at build time (no runtime injection), resolving specificity/shorthands at compile time so CSS size stays flat at scale.
Architecture explainer for the leading zero-runtime approach: a Babel compiler extracts styles into deterministic atomic CSS at build time (no runtime injection), resolving specificity/shorthands at compile time so CSS size stays flat at scale.
Moving Linear from styled-components to StyleX
You ship styled-components — Linear's production migration to StyleX is the playbook: build-time vs runtime styling, ~30% nav improvement, agent-driven codemods at 100k-line scale.
First-hand account of a large production CSS-in-JS to StyleX migration: build-time vs runtime styling, ~30% nav improvement, and agent-driven codemods at 100k-line scale. The migration companion to the runtime-cost argument above.
component-libs — Component & headless-UI libraries (web)
Building an LLM-safe design system
Argues a design system should become the only expressible decisions for LLM-authored code — token-only props, a polymorphic Box, StyleX compile-time enforcement.
A durable take on component libraries in the AI-coding era.
Building design components with action props using async React
A pattern for design-system components that accept action props and run them in internal transitions (useTransition/useOptimistic) for built-in pending/optimistic UI.
A durable component-API pattern for the async-React era.
animation — Animation & gestures
First-principles explainer on the real distinction (main-thread contention, compositor-friendly properties, WAAPI) rather than the CSS-is-always-faster myth.
A durable animation mental model that applies to web and RN reasoning alike.
How react-native-ease runs animations with no JavaScript loop
You ship react-native-ease — animations run entirely via Core Animation/ObjectAnimator with no per-frame JS or UI-thread worklet work; the mental model is iOS model vs presentation layers plus cross-platform spring physics.
Deep dive on driving animations entirely via Core Animation / ObjectAnimator with no per-frame JS, incl. iOS model vs presentation layers and cross-platform spring physics. The mental model for truly native-driven RN animation.
Chasing a Phantom Jump: making Skia + Reanimated smooth on low-end Android
You ship Skia — on low-end Android the dominant smoothness fix is SurfaceView over TextureView (no per-frame texture upload, ~50-65% less RenderThread CPU); smoothness is frame-cadence timing, not curve math.
A low-end-Android profiling deep-dive: smoothness is frame-cadence timing, not curve math; the dominant fix is SurfaceView over TextureView (no per-frame texture upload, ~50-65% less RenderThread CPU), plus stable-reference buffer mutation and quantizing per-frame values. With profiler-triangulation methodology (gfxinfo/Perfetto/Hermes).
The real cost of React Native animations: benchmarking every approach
You ship Reanimated — the only cross-library per-frame benchmark measured its shared values at ~36ms/frame at ~500 animating views; only the fully native-driven approach stayed under budget (vendor-run by the Ease author — re-measure).
The only cross-library per-frame benchmark: UI-thread cost of core Animated vs Reanimated (shared values AND the CSS API) vs Ease on real devices — at ~500 animating views only the fully native-driven approach stays under frame budget (Reanimated SVs measured ~36ms/frame). CAVEAT: the author created Ease, the approach that wins — treat the numbers as vendor-run and re-measure on your own screens; the methodology and the per-frame cost model are the durable part.
A React trick to improve exit animations
Uses Suspense to freeze exiting content during animations; explains Fragment refs, useInsertionEffect, and Suspense DOM-update behavior.
A durable web exit-animation technique grounded in React internals.
Rewriting Rive React Native with Nitro Modules: up to 94× Faster Multi-View Loads
You ship Rive — the Nitro line (@rive-app/react-native, 0.4.x early) makes files/view-models shared typed objects: parse once, render many views (94× multi-view loads, ~4.7× lower memory in the authors' benchmark); the legacy unscoped package is quiet.
Why the Rive RN SDK's wins came from MODELING, not micro-optimization: the legacy module flattened files/view-models into a per-view God object, so every view re-parsed state; Nitro HybridObjects make them shared typed objects (parse once, render many) — 94× on a 24-view load, ~4.7× lower memory, ~0.3-0.4µs calls vs ~1.5µs TurboModule / ~21µs legacy bridge (iPhone 13 mini, release; the rewrite authors' own benchmark). A general lesson for native-module design: model objects, not modules.
lists — Lists & virtualization
How to Build the Fastest Apps: Break the Rules (App.js Conf 2026)
You ship Legend List — it mounts a fixed pool of absolutely-positioned containers once and signals individual containers to re-render at new positions, so scrolling never re-renders the list array (v3.0 stable covers RN + web; vendor talk).
Why Legend List is fast, from its author: it mounts a fixed pool of absolutely-positioned containers once and never re-renders that array again — instead it *signals* individual containers to re-render themselves at a new position/item as you scroll, and turns frequent size changes into animated-style updates rather than list re-renders. The generalizable lesson ('render once'): keep each render tiny by pushing it to the leaf that actually changed. Complements the peterp.me engine walkthrough with the same-source mechanism; announces v3.0 stable (RN + web). Vendor talk.
FlashList v2: a ground-up rewrite for React Native's New Architecture
You ship FlashList — v2 is New-Architecture-ONLY (old arch → pin v1.x), and the v2 rewrite changes the recycling machinery (progressive rendering, pre-paint correction).
The maintainer's architecture deep-dive on FlashList's New-Architecture rewrite — view recycling, progressive rendering, layout prediction, and pre-paint correction via synchronous measurement — explaining the recycling machinery from first principles, not just the API.
React windowing vs. component recycling
Cleanly separates the two long-list strategies — windowing (render only the viewport, mount/unmount on scroll) vs recycling (reuse nodes by reassigning keys) — and when to escalate.
Bridges web (react-window) and RN (FlashList).
What's actually happening inside Legend List
You ship Legend List — its tuning surface is the virtualization formula: estimated item size, draw distance, container-pool ratio, and asymmetric 1.5x/0.5x buffering.
Explains Legend List's virtualization formula — estimated item size, draw distance, container-pool ratio, asymmetric 1.5x/0.5x buffering. A concrete mental model for list recycling performance (complements the FlashList piece).
Virtual scrolling for billions of rows (techniques from HighTable)
You ship TanStack Table — for huge web tables (100k+ rows) HighTable's techniques apply: lazy slicing, the ~17M-px canvas-height ceiling with downscaled scrollbars, dual local/global scroll modes, decoupled axes.
The five techniques behind HighTable — lazy slicing, the ~17M-px canvas-height ceiling with downscaled scrollbars, dual local/global scroll modes, decoupled axes. The web huge-table counterpart to the RN list pieces above (HighTable is a listed option here).
a11y — Accessibility across web & native
Accessibility in React: Common Mistakes and How to Fix Them
A durable React a11y reference from a recognized expert: semantic HTML, labeling, focus management on route/modal changes, ARIA live regions, with concrete useId/useRef patterns and a WCAG-cited checklist.
AI-Generated UI Is Inaccessible by Default
Why LLM-generated components ship empty accessibility trees, and a five-layer enforcement system (prompt constraints, jsx-a11y lint, axe-core runtime tests, CI gates, headless primitives).
Durable guidance as AI codegen becomes the default.
i18n — Internationalization (i18n)
Ahead-of-time compilation for next-intl
You ship next-intl — v4.8 precompiles ICU messages at build time into minified ASTs evaluated by a ~650-byte runtime, trading runtime message parsing for smaller bundles.
Why and how ICU messages are precompiled at build time into minified ASTs evaluated by a ~650-byte runtime, weighing function-based vs AST strategies against bundle size. Teaches the compile-time-vs-runtime and bundle-size tradeoffs from first principles.
ICU Message Syntax (core concepts)
You ship an ICU-based i18n layer (react-intl/next-intl/Lingui) — your message strings are ICU syntax (interpolation, plurals/selectordinal, select, number/date skeletons); ICU is a stable Unicode standard, so this reference doesn't go stale.
The canonical, example-driven explanation of the ICU message format — interpolation, plurals/selectordinal, select, number/date skeletons, rich text. ICU is a stable Unicode standard, so this foundational reference doesn't go stale.
charts — Charting & data visualization
You ship a D3+React chart stack — the durable division of labor is D3 for math/layout while React owns the DOM, composing low-level primitives instead of opinionated chart components (applies to visx, Recharts, any D3+React stack).
The architecture of web React charting — use D3 for math/layout while React owns the DOM, and compose low-level primitives instead of opinionated chart components. First-principles framing that applies to visx, Recharts, and any D3+React stack.
The Future of React Native Graphics: WebGPU, Skia, and Beyond
You ship Skia-backed RN charts (Victory Native XL or raw react-native-skia) — the rendering model underneath: JSI, immutable display lists, a unified WebGPU backend, and the canonical high-density line-chart-as-GPU-texture pattern.
How RN Skia renders graphics — incl. the canonical high-density line-chart-as-GPU-texture example, JSI, immutable display lists, a unified WebGPU backend. The rendering model under Victory Native XL and build-your-own Skia charts.
editors — Rich-text & content editors
The Unreasonable Effectiveness of the ProseMirror Model in Rich Text Transformation
You ship a ProseMirror-family editor (TipTap/BlockNote/ProseMirror) — nodes, marks, positions, and mappings are the document model under your editor; this teaches them through a real parse→transform→serialize pipeline.
Teaches ProseMirror's core abstractions (nodes, marks, positions, mappings) through a real parse→transform→serialize pipeline. Durable conceptual grounding for the document model under most React editors.
svg — SVG, vector graphics & icons (React Native)
Introduces Redraw — 2D primitives on WebGPU where shaders are TypeScript functions that receive geometry (tangent, arc length) to compute stroke width / feathering / material per-point, enabling physically-based 2D rendering.
The Skia author's bet on WebGPU as the unified graphics runtime; experimental, but the direction RN GPU graphics is heading.
How to import SVG files in React Native using react-native-svg
You ship react-native-svg — the canonical workflow how-to: inline SVG, importing designer .svg files as components via react-native-svg-transformer, SvgUri/SvgXml, and animating SVGs.
Practical deep-dive on inline SVG, importing .svg as components via react-native-svg-transformer, SvgUri/SvgXml, and animating SVGs — the canonical how-to for the react-native-svg workflow.
maps — Maps & geolocation UI
react-native-maps vs Mapbox RN vs MapLibre RN (2026)
You ship an RN map library — the decision table: Google ~$7/1k mobile loads vs Mapbox $0.50/1k after free tier vs MapLibre free-but-BYO-tiles; only Mapbox/MapLibre expose offline region-download APIs (react-native-maps does not).
The concrete three-way comparison behind this entry's axes: per-load pricing math (Google ~$7/1k mobile loads vs Mapbox $0.50/1k after free tier vs MapLibre free-but-BYO-tiles), which libraries actually expose offline region-download APIs (Mapbox/MapLibre yes, react-native-maps no), GL style customization, API-key requirements, and New-Architecture status — with code for each. Team-authored (no individual byline) but sourced and measured; use for the decision table, not authority.
calendars — Calendars, date pickers & event grids
Super Calendar — docs (views, gestures & architecture)
You ship Super Calendar — the native renderer requires Reanimated 4 + Gesture Handler + Legend List; views are virtualized and snap-paged (month/week/day/3-day/schedule), and @super-calendar/dom renders the same core on web.
The reference for the new event-grid approach: a platform-free core with native (Reanimated 4 + Gesture Handler + Legend List) and DOM renderers, virtualized snap-paged views (month/week/day/3-day/schedule), and gesture semantics (pinch-to-zoom time grid, long-press drag, grip resize, drag-empty-space-to-create). Documents the stack a modern RN event grid actually requires — useful even if you pick something else.
polish — UX polish primitives — toasts, haptics, splash screens, image viewers (React Native)
You ship sonner-native — the design rationale it imports: interruptible transitions over keyframes, index-scaled stacking, pause-on-hidden, momentum swiping, gap-filling hover pseudo-elements.
The design rationale under sonner (and thus sonner-native): interruptible transitions over keyframes, index-scaled stacking, pause-on-hidden, momentum swiping, gap-filling hover pseudo-elements. Web-authored, but it is the canonical 'why good toasts feel good' — the taste this entry's toast pick imports.
Platform & native (RN)
native — Native modules & the New Architecture
How to Make Pure JSI Code Faster in React Native (Part 1)
You ship Nitro Modules — the runtime mechanics it compiles down to: HostFunction vs HostObject, the Object+NativeState pattern, stack vs heap, and minimizing JS-to-native crossings, with reproducible Hermes benchmarks.
How JSI bindings actually work at the C++/Hermes boundary — HostFunction vs HostObject, the Object+NativeState pattern Nitro compiles down to, stack vs heap, minimizing JS-to-native crossings — with reproducible Hermes benchmarks. The runtime mechanics under Turbo/Nitro Modules.
Making JSI Faster with More Efficient Data Structures (Part 2)
You ship Nitro Modules — data representation across the JSI boundary (array-of-objects vs flat array vs ArrayBuffer, numeric vs string contracts) can swing performance up to ~30x with no algorithmic change.
How data representation across the JSI boundary (array-of-objects vs flat array vs ArrayBuffer, numeric vs string contracts) can swing performance up to ~30x with no algorithmic change. First-principles guidance for New-Architecture native modules.
How Margelo Helped Discord Improve React Native's New Architecture Performance
You ship Reanimated on the New Architecture — the canonical Fabric jank postmortem: cloneShadowTreeWithNewProps over-cloning the shadow tree plus redundant layout passes for non-layout props, with fixes upstreamed.
Low-level New-Architecture jank postmortem: Reanimated's cloneShadowTreeWithNewProps over-cloning the Fabric shadow tree plus redundant layout passes for non-layout props, with fixes upstreamed. Canonical Fabric / New-Arch internals.
Four Years of React Native Quick Crypto: From Wallets to Node Parity
A four-year native-library architecture case study: wrapping OpenSSL for Node behavior-parity, a sync-first threading model with async escape hatches, the hand-written-JSI to Nitro codegen migration, and security audit as architecture validation.
Generalizable lessons for native-module authors.
media — Camera, video & real-time media (WebRTC, frame processing, filters)
Building a video call app with filters
You ship WebRTC calling (LiveKit / react-native-webrtc) — don't fork the stack for filters: segment off the hot path, GPU-composite, and inject processed VisionCamera frames into the existing VideoSource; mind YUV conversion and monotonic timestamps.
Architecture deep-dive: real-time RN video-call filters (background blur, virtual backgrounds, Center Stage auto-zoom, live drawing) by injecting processed VisionCamera frames into LiveKit's WebRTC VideoSource without touching encoder/transport/signaling. Covers off-thread segmentation (MediaPipe/Vision), Metal/Skia compositing, YUV↔I420/NV12 conversion, and the monotonic-timestamp + buffer-pooling gotchas.
MoQKit: a native mobile SDK for MoQ on iOS and Android
Architectural intro to Media over QUIC for mobile — the session/namespace/track model, why moq-lite over moq-transport, and where it sits between WebRTC and HLS.
A durable real-time-media transport reference.
What's New in VisionCamera V5?
You ship VisionCamera — v5 is a full Nitro rewrite (Constraints API replaces Formats, ~15x lower call latency) but still stabilizing: adopt pinned-patch with a device-matrix pass; don't linger on frozen v4.
The canonical v5 reference for this entry's default camera pick: the full Nitro rewrite (−3k LOC of hand-written JSI, ~15x lower call latency vs Turbo Modules), the Constraints API replacing Formats, in-memory photo capture, depth/RAW/multi-cam, and modular frame-processor plugins. Read before betting real-time work on v5.
QR and Barcode Scanning in React Native with VisionCamera V5
You ship VisionCamera and scan codes — three APIs (CodeScanner / useBarcodeScannerOutput / frame processors); narrow barcodeFormats and outputResolution for latency, and mind the frame-vs-preview coordinate gotcha.
By VisionCamera's creator: three scanning APIs (CodeScanner / useBarcodeScannerOutput / frame processors), narrowing barcodeFormats and outputResolution for latency, the frame-vs-preview coordinate gotcha, and MLKit vs Apple's native AVCaptureMetadataOutput vs commercial SDKs. The reference for RN code scanning.
storage — On-device storage & persistence
SQLite for React Native, but 5x faster and 5x less memory
The library author walks the JSI/C++ internals that make op-sqlite fast and memory-light — lazy HostObject conversion, std::variant over a custom struct, key-sharing across result rows — with benchmarks.
The mechanics of high-performance JSI SQLite, not API usage.
An Interactive Guide to TanStack DB
Builds the local-first reactive-persistence mental model from first principles — Collections, live queries via differential dataflow, optimistic transactional mutations — contrasting it with request/response fetching.
The shift to sync-engine thinking.
native-ui — Native UI extensions — Live Activities, widgets, App Clips, portals
Apple Home Screen Widgets with Expo (Continuous Native Generation)
Generating native Apple widget targets from Expo via CNG — pbxproj manipulation to keep SwiftUI targets editable yet outside /ios, App Group / NSUserDefaults data sharing, CSS-to-colorset conversion.
The foundational mechanism behind Expo Targets / expo-widgets.
Using Live Activities in a React Native App
End-to-end Live Activities in RN — the ActivityKit Attributes/ContentState model, a separate widget-extension target for Lock Screen + Dynamic Island, a native module bridging JS↔Swift, and the HTTP-refresh vs APNs-push tradeoff.
Platform constraints that outlast any single library.
How we built the v0 iOS app (React Native + Expo)
Production case study of making RN feel truly native on iOS: Liquid Glass via @callstack/liquid-glass, native menus via Zeego/UIMenu, patching RCTUITextView for platform-correct text behavior, ~1,000 lines of keyboard logic on react-native-keyboard-controller (see RB-E-KEYBOARD), synchronous New-Arch measurements, LegendList — and the share-types-and-logic-not-UI lesson.
What 'native feel' actually costs and where the wins come from.
keyboard — Keyboard handling & avoidance (React Native)
The Go-To Guide for Understanding Keyboards in React Native (Part 1)
You ship no keyboard library — core KeyboardAvoidingView snaps on Android (no per-frame insets) and breaks under Android-15 edge-to-edge; react-native-keyboard-controller is the modern parity fix.
Why keyboards behave differently per platform — iOS scheduled animation vs Android per-frame WindowInsetsAnimationCallback insets, why core KeyboardAvoidingView snaps on Android, Android-15 edge-to-edge breakage, and when to reach for KeyboardAvoidingView / KeyboardAwareScrollView / KeyboardStickyView.
payments — In-app purchases & payments
Cross-platform subscription state: sharing entitlements between Android and iOS
Why unifying subscription entitlements across iOS/Android is hard — Apple signed-JWS vs Google purchase-token REST, HTTPS notifications vs Cloud Pub/Sub, subscription groups vs base plans/offers — and the four-part DIY architecture.
The root reason IAP libraries/services exist.
Building the RC Fortress: protecting payments against outages
A resilience case study for keeping purchases working when subscription backends fail — cached paywall snapshots, temporary offline entitlements, buffered request log/replay — with tradeoffs made explicit.
The realities of subscription infra regardless of library.
brownfield — Brownfield integration & micro-frontends
Rebuilding the Doctolib Homepage from Webview to Native
Production case study migrating a 115M-hits/month homepage from WebView to native RN with a BFF-driven section architecture (~50% TTI improvement, measurable conversion gains).
Durable brownfield-integration lessons.
Unlocking Expo Updates in an Isolated Brownfield Architecture with SDK 55
The capability-flip walkthrough behind this entry's note: running EAS/Expo Updates inside an isolated brownfield embed (XCFramework packaging via `npx brownfield package:ios`), which had been a hard limitation of embedded-RN architectures.
Read when you need OTA on brownfield screens.
React Native production lessons from React Universe Meetup x Zalando
Four hard-won production patterns — brownfield-handoff metrics (Meaningful Render), video-feed jank sequencing, native API bridging, on-device LLM hardware variance.
Real-world scale-stage RN guidance.
games — Games, 3D & AR/VR — interactive / real-time rendering
React Native Skia — For Us, For You, and For Fun
The foundational architecture of react-native-skia: JSI for direct C++/JS communication, a custom React reconciler powering the declarative API, and Reanimated-driven animation.
The enduring design under RN's 2D GPU drawing — the base for RN games and interactive visuals.
alt-frameworks — Alternatives to React Native (cross-platform frameworks)
We Built the Same App in KMP and React Native — Here's What We Found
The controlled comparison this entry needed: identical unoptimized apps on 6 devices measuring size/startup/RAM/CPU/frames.
KMP wins Android decisively (8x smaller, 2-4x startup, ~50% less RAM — no JS runtime); iOS converges, with RN using 3-4x LESS memory (UIKit rendering vs KMP's resident Skia). Credible precisely because an RN consultancy published the unflattering Android numbers; ends on the right frame — performance is one input, DX and ecosystem are others.
Under the hood of MDN's new frontend
Architecture case study replacing a React SPA with server-side templating + Lit web components (per-component CSS, Declarative Shadow DOM, Rspack).
An authoritative counter-perspective on when NOT to ship a React SPA.
From React to native web with nanotags: a migration that saved 100 KB
When a marketing/content site doesn't need React — migrating to Web Components (Custom Elements + Astro + nanostores, ~3KB vs ~63KB), with the boilerplate/accessibility trade-offs nanotags addresses.
Durable do-you-even-need-React reasoning.
How We Rewrote 130K Lines from React to Svelte in Two Weeks
A migration case study contrasting React's virtual-DOM overhead with Svelte's compiled reactivity for an AI-driven browser UI, including the LLM-migration ruleset that kept the Svelte idiomatic.
A concrete framework-tradeoff data point for teams weighing leaving React.
Build, test, observe, secure
build — Build tooling, bundlers & monorepo
The first-principles explainer for WHY the JS toolchain is going Rust — memory safety, no GC, real parallelism, the redundant-parsing problem — mapping the whole landscape (esbuild, SWC, Oxc/Biome, Rspack, Rolldown).
Durable cross-cutting context, not a single release.
You ship Vite — v8 unifies dev and prod on Rolldown (one Rust bundler, 10-30x faster) instead of the unsustainable esbuild+Rollup pair, with Oxc semantic analysis driving better tree-shaking.
Why maintaining two pipelines (esbuild + Rollup) was unsustainable and how Rolldown unifies dev/prod on one Rust bundler (10-30x faster), with Oxc semantic analysis driving better tree-shaking. The primary source for the Vite+Rolldown+Oxc consolidation.
Exploring Inlined Requires: how they really work
You bundle with Metro — inlineRequires mechanics: why React/RN stay hoisted, why default imports aren't inlined, and how rnx-kit's esbuild path differs (real tree-shaking vs startup-only).
Exactly what Metro's inlineRequires Babel transform does, why React/RN stay hoisted, why default imports aren't inlined, and how rnx-kit's esbuild path differs (real tree-shaking vs startup-only). The canonical Metro startup-mechanics reference.
The Complete Guide to React Native Build Optimization
Why RN Android builds are slow (conservative Gradle/Metro/C++ defaults) and how parallel Gradle, dynamic Metro workers, ccache, and single-architecture builds cut times from 20+ min to 2-5 min, with benchmarks.
The RN-CI build-perf dimension the other readings here don't cover.
testing — Testing strategy & tooling
You ship Testing Library — query by role/label, not data-testid: accessible queries are both the stronger test and a free a11y audit; testid queries silently hide inaccessible markup.
The bridge between this entry and RB-E-A11Y: querying by data-testid silently hides inaccessible markup, while role/label queries fail exactly when a real assistive-tech user would — so accessible queries are both the better test AND a free a11y audit. Sharpens the Testing-Library philosophy the two Dodds pieces establish.
Write tests. Not too many. Mostly integration.
You have a test runner — spend it on integration tests over mock-heavy unit suites: confidence per effort is the metric, not coverage.
The foundational testing-strategy essay: maximize confidence per effort by favoring integration tests over mock-heavy unit suites and coverage-chasing. The origin of the Testing-Trophy mindset.
Testing Implementation Details
Why tests coupled to internals are brittle (false failures on refactor, false passes on breakage) and why to test behavior the way users use it.
The mental model behind Testing Library.
dx — Developer experience — CI, lint/format, hooks, monorepo, onboarding
Best CI/CD for mobile apps in 2026: a practical comparison
The only structured selection matrix for mobile CI platforms (EAS Workflows vs Bitrise vs Codemagic vs GitHub Actions): fingerprint-based repack turning 10–15min builds into ~2min JS-only builds, and GHA macOS runners measured ~2.4x slower than Codemagic M4s.
READ AS A VENDOR DOC — Expo wins its own comparison; the evaluation axes (runner hardware, cache strategy, fingerprint/repack) are the durable part.
Expo without EAS: scaling the React Native DX of an app with 90M+ users
You ship Expo at scale — Doctolib's blueprint runs the bare workflow without EAS: fingerprint caching + JS patching halved CI builds while contributors grew 9→105.
Large-scale case study adopting Expo's bare workflow (not EAS) with fingerprint caching + JS patching to halve CI builds and grow contributors 9→105. A durable enterprise RN build/CI-DX blueprint.
observability — Crash reporting, monitoring & observability
Bringing Lighthouse to the App: Core Web Vitals for React Native
You run RN in production — crash reporting alone isn't performance observability: Indeed's blueprint adapts Core Web Vitals (TTFF/TTI/FID) into an RN perf hook with composite scoring.
Adapts web Core Web Vitals (TTFF/TTI/FID) into a React Native performance hook with composite scoring, from a real ViewJob rollout. A durable blueprint for measuring (not just crash-reporting) RN performance in production.
The Hidden Cost of Hydration Mismatches
You server-render — one hydration mismatch makes React recreate the DOM and re-trigger LCP at hydration time; mismatches are a measurable LCP tax, not a cosmetic console warning.
Web-side production-perf diagnosis from real consulting: a single hydration mismatch makes React recreate the DOM, and because LCP only tracks NEW elements, the remounted (font-swapped, larger) text re-triggers LCP at hydration time — green→red with no obvious cause. Durable lessons: keep server/client renders identical, scope unavoidable mismatches with Suspense, and know how the metric itself measures (the metric mechanics are the observability half — the rendering-strategy background lives in RB-E-META-FRAMEWORKS's readings). The web counterpart to the Indeed RN piece above.
security — App security — device trust, secrets, dependency risk
An RCE postmortem on CVE-2025-55182 in React's Flight protocol (thenable abuse, prototype-chain exploitation), with durable lessons on runtime-vs-build-time type safety and lenient-parsing attack surface.
Canonical RSC security case study.
The Flight Protocol Made Your DoS My Problem
A DoS deep-dive (CVE-2026-23870) in the RSC Flight deserializer, with the generalizable lesson that dissolving a network boundary into developer ergonomics still owes a threat model (applies to tRPC/GraphQL/WebSockets too).
Shai-Hulud Postmortem (npm supply-chain worm)
You run a production pipeline — supply-chain is the real React-ecosystem risk: disable npm install scripts, use OIDC publishing, and layer defenses (the Shai-Hulud mitigations apply to every delivery pipeline).
A first-party postmortem of the Shai-Hulud worm (preinstall-script credential exfiltration) with concrete mitigations — disable npm install scripts, pnpm 10, OIDC publishing. The supply-chain reading this entry's own note calls for; applies to any React/RN delivery pipeline.
Postmortem: TanStack npm supply-chain compromise
First-party postmortem of the incident this entry's note cites: 84 versions across 42 @tanstack/* packages, via a pull_request_target 'Pwn Request' → pnpm store-cache poisoning → OIDC token extraction from the runner.
The CI/CD-side attack chain — a different door than the install-script family covered by the Shai-Hulud and NodeSource readings.
RSC Server Functions Are Not An API Boundary
You ship an RSC framework — server functions are reachable via direct POST regardless of UI: auth/authz must live INSIDE every server function, and deploy skew breaks old clients.
The architectural half of this entry's RSC stance: compiler-generated server references are reachable via direct POST, so auth/authz must live INSIDE every server function — plus the rolling-deploy skew failure mode (generated function IDs drift across deploys and break old clients). Treat stable server functions as formal API boundaries. (Site is a JS shell; content verified via its RSS feed.)
Blocking Install Scripts Is Not a Silver Bullet
The nuance behind this entry's supply-chain note: npm v12's default block on preinstall/install/postinstall closes the INSTALL-TIME door but leaves the EXECUTION-TIME door open.
Attackers already moved the payload into the module body as a top-level side effect (runs on first require), or ship a binding.gyp so npm's implicit node-gyp rebuild fires anyway (the June-2026 Miasma campaign). Removing a trigger isn't removing the capability — so layer defenses: Node's --permission model (--allow-net / --allow-child-process / --allow-fs-write to cap what running code may DO), CI egress allow-listing (Harden-Runner), and container/seccomp isolation. Install-script blocking raises the floor; it is not the ceiling.
ota — Over-the-air (OTA) JS updates & release channels (React Native)
The production playbook for OTA updates
You ship OTA updates — run them like releases: staged percentage rollouts, a monitored bake period, and know abort vs republish-rollback as distinct mitigations before you need one.
The operational canon for this entry: staged percentage rollouts as exposure control, what to monitor while an update bakes, and aborts vs republish-rollbacks as distinct mitigations — 'sometimes it helps to go a little slower.' Vendor-authored but the staged-rollout discipline is platform-agnostic. (Body verified via the page's embedded content JSON — the blog is a JS shell.)
EAS Update introduction (docs)
The reference for the hosted-default choice: how updates map to channels, phased rollouts to a percentage of users, and rollback-by-republish ('much like a new commit').
Read before designing a release-channel scheme.
AI in React apps
ondevice-ai — On-device AI / ML
On-Device AI Beats Cloud for TTS — Here's Why
You ship react-native-executorch — the on-device-vs-cloud TTS case (Kokoro): cost, latency and privacy favor on-device, with the tradeoffs being voice/language coverage and a custom C++ phonemizer.
A reasoned cost/latency/privacy case for on-device TTS (Kokoro via react-native-executorch), with the economics and the tradeoffs (voice/language coverage, a custom C++ phonemizer). A durable framing for the on-device-vs-cloud decision.
ai-ui — Generative UI & in-app AI
Generative User Interfaces — rendering UI with language models
You ship the Vercel AI SDK — the generative-UI model: tools return structured JSON mapped to React component props; the client-side switch statement doesn't scale, so stream components during generation via createStreamableUI/RSC.
The core generative-UI mental model: tools return structured JSON that maps to React component props; the client-side switch-statement scaling problem; and the server-side createStreamableUI/RSC solution for streaming components during generation.
How to Build a Performant AI Markdown Renderer
You ship streaming LLM output — render markdown the Streamdown way: repair incomplete markdown before parsing, memoize at block level so every token doesn't re-parse, cache the processor, and wrap updates in startTransition.
The architecture behind streaming-markdown rendering (the Streamdown problem): repairing incomplete markdown before parsing, block-level memoization to avoid re-parsing every token, processor caching, and startTransition for smooth streaming.
ai-devtools — AI-assisted development — agent skills, MCP tooling & device automation
How Expensify Uses Agent-Device for Mobile Bug Evidence and Profiling
The first named production-adopter case study for agent-device: agents run Sentry-span measurement loops across branches and drive the React profiler mid-session via react-devtools integration, returning named components and render counts as bug evidence.
What agent-in-the-debug-loop looks like at a real company, beyond vendor demos.
Meet Argent: Agentic Toolkit to Control, Debug and Profile iOS applications
The clearest articulation of the closed loop this entry is about: the agent that writes the code also boots the simulator, drives the UI, attaches a debugger, and profiles React+iOS in the same session — with production numbers (~50% re-render reduction in a banking app) rather than demos.