In his conversation with Silver.dev founder Gabriel Benmergui, Dax Raad makes the case for a frontend with much less to do. Get the sync engine right as the data layer, and most of the coordination work disappears from the interface. That leaves more attention for making something beautiful.
Dax, creator of OpenCode at Anomaly, the team behind SST and terminal.shop, arrived at this through the experience of using Linear. He couldn't reconcile how good it felt with the things the industry spent its time discussing:
"How is a whole industry just going about their day when this thing exists?"
Linear gave him a different target
Dax remembers years of attention going into SSR and edge rendering. Developers were absorbed in what he calls "these stupid little incremental optimizations," while Linear delivered an "out-of-the-world experience" with a "basic React SPA with like styled-components".
The contrast frustrated him because he wanted to build an application that felt that good. The React stack itself wasn't the exciting part. He wanted to understand the sync engine underneath the experience and how to build with that model himself.
Dax wanted the data layer to support the experience he admired, without making frontend developers choreograph every interaction with the server.
Orbit, urql, Replicache, then Zero
Dax worked through several approaches to get there. He connected a JSON API to Orbit to sync data locally, then ran into issues. He moved into the GraphQL space and tried urql, which could also replicate data locally. Each attempt got a little better, but he still felt something was missing.
Replicache was where the mental model started to feel right. He credits the team's experience working on synchronization across companies and understanding the problems developers encounter. He then describes the progression from Replicache to Zero, which he says he now uses across the board.
He describes a search for a data layer he could rely on across his projects. The payoff comes after that choice: the screen can work with local data.
The frontend becomes the easy part
Gabriel asks about the developer experience, speaking as a founder who no longer codes every day but can still make technical decisions. Dax answers:
"Uh, on the plus side, it makes front end the dumbest work ever."
He gets specific about what makes frontend work annoying: mutating data, keeping it coordinated with the server, making calls in the right order, and managing loading states. Those tasks consume attention before a developer gets to the interface itself.
With the sync layer handling that coordination, his description of the remaining work is almost mundane:
"So your front end is just assembling markup, styling it, and the data is just always there and you can query it locally."
That's the sense in which the work becomes dumb. The screen can query local data and render it. Developers spend less of their time managing the machinery around that screen.
More attention for the interface
The payoff is room to care about how the product looks and feels. If your team spends less effort wiring up server calls and loading states, it has more attention for the markup and styling Dax describes. Making those parts simple gives developers space to be more ambitious with the result.
Markup and styling still leave plenty of decisions to make. You can care about spacing and interaction details, and spend time making a screen pleasant to use. Those choices are easier to give your attention to when you aren't also arranging the server calls behind them.
For a founder, the ambition can go beyond shipping the same screens with less code. The extra effort can go into the details you'd otherwise leave for later.
Our notes on coding agents and product-market fit look at another part of building software: deciding what deserves that effort. If you're building your team, talk to Silver.dev. Watch Dax Raad's full conversation with Gabriel Benmergui for the broader discussion.