In a recent post, Eugene Yan documents his attempt to build the same application using four different web frameworks: FastAPI, FastHTML, Next.js, and SvelteKit. The goal was to see how each framework handles a typical CRUD app, and to reflect on how coding assistants influence the tools developers choose. He notes that the exercise is less about declaring a winner and more about understanding the subtle pressures that shape a developer's default stack.
Yan observes that coding assistants—such as GitHub Copilot—tend to produce more fluent and confident suggestions for frameworks with large amounts of public code. This means popular choices like Next.js and FastAPI often receive better autocomplete and boilerplate support, while newer or less common frameworks like FastHTML may require more manual guidance. He argues that this creates a feedback loop: assistants reinforce existing popularity, making it harder for niche tools to gain traction even if they offer technical advantages.
The author also highlights practical differences in the frameworks themselves. FastAPI shines with Python type hints and automatic OpenAPI docs; Next.js offers a rich React ecosystem but adds complexity; SvelteKit provides a simpler mental model with less boilerplate; and FastHTML, being a newer entrant, trades ecosystem maturity for a minimal, HTML-centric approach. Yan suggests that while coding assistants can accelerate development, they may also obscure the learning curve—users might not notice when a framework is doing more heavy lifting than they realize.
Ultimately, the post is a reminder that framework choice is not purely technical. It is also influenced by the tools we use to write code, the communities we participate in, and the invisible biases baked into our AI helpers. Yan's experiment serves as a practical starting point for developers who want to make more deliberate choices rather than simply following the path of least resistance.