I've been using TanStack Start for a mid-size hobby webapp since its early alpha stage—over a year now. I'm starting to feel I have enough experience, and since Start just entered a release candidate stage, it's time to share my insights with you.

I will present Start by comparing it to Next.js.

This post is about a bad code pattern I see quite often. It’s about state management, particularly state synchronization. Often it is a source of bugs, glitches, and performance problems.

Usually it is solvable by adjusting the state shape. More precisely, splitting the state into pieces and merging the pieces later in selectors, render functions, or custom hooks. An interesting fact is that one of those states is empty or undefined, but the UI renders desired items anyway. It might seem unintuitive, but bear with me.

In the front-end world, there's an ongoing war over performance. RSC (React Server Components), currently implemented in the Next.js App router, serve as the official weapon aimed at improving startup performance. However, it seems that in the midst of this battle, we've forgotten about some fundamentals, resulting in a degraded DX (Developer Experience). This article aims to provide examples of such DX issues in the current Next.js API. Towards the end, I outline a better proposal.

Building web apps is a complex problem. We need simple high-level mental structures to support such a heavy load. These structures allow us to offload unnecessary details from our brains, so we can focus on the important parts of our code. UI = f(state) is one of them. Every one of us knows this formula. But do you know what it reflects in the real world? What is UI? What is state? What the f* is f? And how is it affected by RSC (React Server Components)? Here is my view.

While ago, I started using React hooks. The simplicity, homogenity and composability sounded great. Both components and hooks are simple functions. I can easily react on state changes from memory, local storage, location URL and server the same way - with hooks. Mental model stays simple. My app is just a big function which consumes state and produces DOM. This big function is composed of a smaller functions which are composed of smaller functions and so on. But there were obstacles I've started to encounter and in the end I hit the hard limit of React hooks.