Optimizing Cubbly After Moving Away from SSR
Removing SSR simplified Cubbly but delayed useful inventory. I compared four client-loading compositions and kept the one that made real route content 31–42% faster.
Writing on React, newest first.
Removing SSR simplified Cubbly but delayed useful inventory. I compared four client-loading compositions and kept the one that made real route content 31–42% faster.
I removed React SSR from Cubbly because maintaining Lingui across the Worker and browser was not worth the speed it bought on a private application.
I wanted to keep a shared table component current without accepting migration work on faith. A side-by-side benchmark made the trade-off much easier to judge.
Six months with React Router loaders changed my default. I add React Query only when repeated fetching, shared data, or polling gives me a reason.
React Compiler 1.0 moved routine rendering memoization into the build. React.memo, useCallback, and useMemo now need a specific reason.
How I deployed the React Router application with Fly.io, Cloudflare, Neon, Docker, and reviewable database migration history.
The React Router, TypeScript, PostgreSQL, and authentication stack I chose after using LLMs to prototype the alternatives.
The migration took two focused sessions: dependencies first, then 40 files of imports and route types. Typegen was the part worth keeping.
My Remix-to-React Router v7 migration touched 40 files and removed 591 net lines. Imports were easy; TypeScript took the time.
Leaving Next.js for Remix taught me why the annoying-looking use client boundary exists—and what Remix gives up without it.
A new data-model entity touched several old pages. Rebuilding those UI components was faster than carrying their Flow types and old assumptions forward.
Related subjects
Topics that appear alongside React in these articles.
Back to the index