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.

11 posts on this thread
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 migration history I could roll back.

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.

Keep exploring