--- title: Why I Prefer Datastar Over Vue + GraphQL for Most Craft CMS Projects date: 2025-10-06T15:16:00+02:00 author: admin canonical_url: "https://craft-kit.dev/blog/why-i-prefer-datastar-over-vue-and-graphql" section: Blog --- There was a time when every Craft CMS project I built had the same stack: Craft as the backend, GraphQL as the data layer, Vue on the frontend. It felt modern. It felt professional. It felt like the right way to build things. It wasn't. ## What Vue + GraphQL Solves To be fair: Vue + GraphQL is a legitimate stack. GraphQL gives you a flexible, typed API that lets the frontend request exactly the data it needs. Vue gives you a reactive component model that's approachable and well-documented. Together, they work — especially for teams where frontend and backend developers work independently, or for projects that need a public API consumed by multiple clients. If you're building a headless Craft setup that powers a mobile app, a third-party integration, and a web frontend simultaneously, GraphQL makes sense. That's the use case it was designed for. ## What It Costs The problem is that most Craft CMS projects aren't that. Most are websites. They have one frontend, one team, and one job: render content from Craft into HTML. For that use case, Vue + GraphQL introduces a layer of complexity that doesn't pay for itself. You end up maintaining a GraphQL schema that mirrors your Craft content model. You write queries that fetch data your Twig templates could have accessed directly. You manage client-side state that the server already owns. You debug hydration issues, loading states, and component lifecycle problems that simply don't exist in a server-rendered setup. The frontend becomes a second application — with its own build pipeline, its own error surface, and its own opinions about how data should flow. Every content model change requires updates in two places instead of one. Every new developer needs to understand both Craft and the Vue layer before they can ship anything. This is not a problem with Vue or GraphQL. It's a problem with applying them where they don't belong. ## The Web Already Has an Architecture for This Before SPAs became the default, the web worked on a simple principle: the server renders HTML, the browser displays it, and links and forms handle interaction. This is hypermedia — and it is not a legacy pattern. It is the architecture the web was built on, and it is still the most robust way to build content-driven websites. Hypermedia means HTML is the interface. The server is the source of truth. State lives on the backend, not in a client-side store. Navigation happens through URLs, not JavaScript routers. Updates happen through HTTP, not through a custom event system. Craft CMS is a hypermedia-native platform. It stores content, renders Twig templates, and returns HTML. When you add Vue + GraphQL on top of it, you are not extending Craft — you are replacing its rendering model with a client-side one. You are moving state off the server and onto the browser, where it is harder to reason about, harder to debug, and harder to maintain. ## What Datastar Does Differently Datastar is a hypermedia framework. It does not replace Craft's rendering model — it extends it. The server continues to own state and render HTML. Datastar adds just enough reactivity on top to handle the interactions that need it: live search, filtered listings, load-more pagination, real-time updates. The mechanism is Server-Sent Events. The browser opens a persistent connection to the server and receives HTML fragments in response to user interactions. Those fragments are morphed into the existing DOM — no virtual DOM, no hydration, no client-side reconciliation. The browser does what it was built to do: render HTML. The result is a stack that feels like classic Craft development, because it is. Twig templates, entry queries, clean content models — with the ability to update parts of the page without a full reload. A developer who knows Craft and Twig can read a Datastar template without learning a new paradigm. ## When Vue + GraphQL Still Makes Sense There are projects where I would still reach for Vue and GraphQL. Highly interactive single-page applications with complex client-side state. Projects where the API needs to serve multiple consumers simultaneously. Teams with dedicated frontend developers who work independently from the backend. Situations where real-time bidirectional communication is a core requirement. These scenarios exist. But in my experience, they represent a minority of Craft CMS projects — not the majority. ## The Default Should Match the Use Case The reason I prefer Datastar for most Craft projects is not that it is newer or more interesting. It is that it matches how Craft actually works — and how the web was designed to work. Vue + GraphQL is a powerful stack for the right problem. But it should not be the default for every Craft project. Most Craft projects are websites, not applications. They need server-rendered HTML, clean content models, and just enough interactivity to feel modern. Hypermedia gives you that. Datastar makes it practical. And Craft CMS was built for exactly this model — you just have to stop fighting it.