Content Is Anything: Elian Van Cutsem on Astro, Islands, and the CMS Spectrum

Elian Van Cutsem occupies an unusual position in the CMS ecosystem. He is an Astro maintainer — formerly a core maintainer — who now works as Lead DevRel at React Bricks, a visual CMS built on a headless architecture. That dual vantage point, deep in both the framework internals and the product layer that sits on top of it, makes his perspective on content systems unusually grounded. In a conversation with Maciek Palmowski for the CMS Conf podcast, Elian covers the definition of content web, the real decision variables in CMS selection, island architecture, vocabulary fragmentation across frameworks, and why Astro is unusually well-suited to AI-assisted development.

React Bricks is the CMS that bridges the gap between developer control and marketer autonomy — and right now it is one of the most interesting tools in the headless space. Unlike traditional headless setups where content editors work in a separate interface disconnected from your design system, React Bricks lets you define what marketers can and cannot change at the component level, down to individual fields and layouts. If you are building with Astro or React and want to give your team genuine visual editing without sacrificing the design system, react.bricks is worth exploring today.

What “Content Web” Actually Means

The phrase content web is sometimes used as a synonym for “any site with a CMS,” but Elian defines it more precisely. Content is not just articles or blog posts. It is the home page title, the YouTube video embedded in a landing page, the list of GitHub sponsors on a project page, the structure of a pricing table. If something is displayed on a website and someone other than a developer might need to change it, it is content.

The practical consequence is that systems which treat content narrowly — where the CMS manages articles but the page structure is hardcoded — create operational friction. A marketer who needs to change a title but has to open a support ticket to do it is working in a system with an implicit architectural assumption about who owns what. Elian frames this as one of the core problems React Bricks was built to address: allowing any element to be editable without surrendering the design system to editor discretion.

Content format is equally broad. For Astro specifically, content can be Markdown, MDX, JSON, CSV, or a database. Astro’s content collections and data collections exist precisely because the distinction between “content” and “data” is often artificial. A static list of sponsored projects is data — but it is also content if someone needs to display, update, and loop over it.

Choosing on the CMS Spectrum

Asked how to choose between headless, tightly coupled, and hybrid CMS approaches, Elian’s answer is the canonical one — it depends — but the reasoning he provides is more specific than the cliché implies.

The real variables are scale, team composition, and customization requirements. A personal site can be well-served by WordPress. A high-volume content operation where rendering cost in a tightly coupled system becomes prohibitive has different trade-offs. A team without engineering capacity cannot manage a fully headless setup where every feature not built into the CMS is a custom development project.

The trap Elian identifies with tightly coupled systems is the inverse of what most headless advocates highlight. It is not just that WYSIWYG systems produce suboptimal HTML or constrain interaction patterns — it is that customization cost scales steeply. A feature that would take a few hours to build as a React component may take several times longer inside a tightly coupled CMS’s extension model. At some point, the accumulated cost of customization exceeds the cost of managing a headless setup, and the team may not notice the crossover until it has happened.

The inverse problem with headless is that the accumulated feature set of a mature tightly coupled CMS represents thousands of solved edge cases. Choosing headless means inheriting none of those solutions — every edge case is either discovered and built, or it is missing from the product.

The WYSIWYG Promise and Accessibility

Visual editing in CMS products is typically described as solving for marketer autonomy — the ability to make changes without developer involvement. Elian adds a second dimension: output quality. The HTML produced by a visual CMS is not a detail. It directly determines whether accessibility features are available, whether ARIA attributes are correctly applied, and whether a site functions correctly under assistive technologies.

Elian’s position is that most CMS systems, including WordPress, do not do this particularly well. The constrained editing model that makes WYSIWYG convenient also tends to abstract away the layer where accessibility decisions are made. The developer cannot easily reach the output HTML; the editor does not know to care about it. The result is that accessibility is addressed neither by the system nor by the person operating it.

The argument for component-based visual editing — where the developer defines the output and the editor controls only permitted variables — is that accessibility concerns can be built in at the component level, where the developer is working anyway. The editor cannot inadvertently break what is not exposed as an editable field.

Naming Things Across Frameworks — and with AI

Vocabulary fragmentation is a low-visibility problem in the CMS and framework ecosystem. Astro uses client islands and server islands. Next.js calls similar patterns server actions. The mental model is substantially the same; the terminology is not. Elian describes this as a problem that requires standards — and acknowledges that defining those standards in an open-source community with fast-moving projects is structurally difficult.

The conversation takes an interesting turn when AI enters the discussion. Vocabulary precision now has a different kind of cost. Asking an LLM to implement a client island in Next.js — where the term does not exist — wastes tokens or produces incorrect output. The CMS ecosystem has always had internal terminology that developers internalized and communicated informally. That approach breaks when the development surface includes a language model that does not have your team’s context.

Elian and Maciek agree that the practical response is explicit vocabulary documentation inside teams — a shared glossary that covers what terms mean in the specific stack being used. This has always been useful practice. It is now a prerequisite for using AI assistance effectively, because the model will work from whatever terminology appears in the prompt and cannot infer which meaning was intended when a term is ambiguous across ecosystems.

Why Headless Integrations Fail

Elian identifies two primary failure modes for headless integrations, and both are engineering discipline problems rather than architectural ones.

The first is over-engineering or under-engineering specific subsystems. A tightly coupled CMS accumulates solutions over time — someone filed a pull request for an edge case a decade ago and it was merged. A headless implementation starts with none of that. Every edge case is either anticipated and handled, or it surfaces in production. Teams that under-engineer assume the edge cases will not matter. Teams that over-engineer build complexity for scenarios that do not occur. Both fail, just at different points.

The second is API request volume. Headless architectures, by definition, involve remote data fetches. Those fetches can accumulate: authentication, content, related items, media metadata. Elian describes a scenario where a news article page has loaded its text content but is stuck because a two-megabyte image in the background is saturating a mobile network connection. The content arrived; the page cannot render because another request has not resolved.

The structural solution Elian describes is static rendering where possible. Astro’s static-first model means that most content is fetched at build time and served as pre-rendered HTML. There is no runtime network request for content that does not change between deploys. The performance floor is lower because the request count on the client side is lower by default.

He also notes that testing infrastructure is underused in headless CMS setups. Tools like Playwright can run against actual CMS content. Most teams do not configure this. When integration assumptions break — an API response changes shape, a content field is missing — the failure surfaces in production rather than in a test run.

Island Architecture: What Astro Actually Does

Hydration is the moment when JavaScript loads and a web page becomes interactive. In a conventional framework, that JavaScript can include the full library runtime, component code for the entire page, and anything in the dependency tree — regardless of how much of the page is actually interactive.

Astro’s island architecture makes hydration selective. The compiler outputs static HTML and CSS for the full page by default. JavaScript is scoped to specific components — islands — where interactivity is needed. A button that opens a modal ships a small piece of JavaScript for that button. The article text above and below it ships none.

The architectural implication is that different islands can use different libraries. A legacy React component can coexist with a Svelte widget and a Vue form on the same page. Each is isolated; they do not share state by default (though mechanisms for shared state exist). This makes incremental migration from a monolithic SPA technically straightforward — components can move to static rendering individually without requiring a full rewrite.

Server islands extend the model to the server side. A server island is rendered on the server after the initial page is returned to the client. This allows parts of a page to be pre-rendered based on runtime data — inventory levels, pricing, personalized recommendations — without holding the initial response until all data is fetched. The client receives the full HTML skeleton, and the dynamic sections resolve and update asynchronously. For CMS-heavy pages where static and dynamic data coexist, this separation has direct performance implications.

Common Misuses of Islands

Elian describes two recurring misuse patterns.

The first is wrapping the root component with client:load. In Astro, marking a component for client-side hydration causes all its children to also hydrate. If the root component of a page section is marked as a client island, the entire subtree behaves as a client-rendered SPA — which is the outcome the architecture is designed to avoid. The intent of islands is granular hydration; applying it at the root negates the granularity.

The second is shipping multiple framework runtimes simultaneously. A React component requires the React library. A Vue component requires the Vue library. If a page includes interactive islands in React, Vue, and Svelte, all three runtimes are shipped to the client. Each runtime is not large, but their combined weight can exceed the cost of a single framework used consistently. The migration path Elian describes as correct is to progressively convert components to static rendering, choosing one library for interactive components during the transition. Using islands to experiment with multiple frameworks on a production site produces the opposite result from the intended optimization.

Why Astro Works Well with AI

Astro’s syntax is close to JSX, and JSX is one of the best-represented patterns in LLM training data. A model that writes JSX well transfers most of that capability directly to writing Astro components. The significant structural difference is the frontmatter block at the top of an .astro file — but frontmatter is standard TypeScript or JavaScript, which is also well-represented. The net effect is that generating, modifying, and debugging Astro files is a lower-friction operation for an LLM than working in a framework with an unusual or sparse syntax.

Elian also points to Astro’s data model. Schemas defined in content collections and data collections are code — TypeScript interfaces and Zod schemas in a file the model reads once and uses throughout the session. There are no implicit database structures to infer from query patterns or migration history. The model sees the schema directly and can reason about content structure, valid field values, and query patterns without additional context.

The cost argument matters here too. AI sessions are bounded by token limits and, increasingly, cost. A content architecture where all relevant structure is available in a small number of readable files is cheaper to work with than one where structure is distributed across database schemas, migration files, API response shapes, and runtime conventions. Elian notes that AstroDB specifically — where the schema is a single JavaScript file with no migrations — exemplifies this property.

The Future: Niche, but a Growing One

Elian does not expect Astro to become the default choice for all web projects in the near term. The framework is explicitly optimized for content-focused sites rather than application-heavy SPAs, and that constraint is not going away. But within that category — sites where content is primary and interactivity is secondary — he expects Astro to increasingly displace Next.js in cases where Next.js was chosen by default rather than by fit.

The analogy he draws is to Eleventy and Gatsby. Eleventy occupied a similar position before Astro — static-first, content-focused. Gatsby introduced content collections as a pattern; Astro’s implementation is, in Elian’s words, “inspired by” that work. This is a normal pattern in framework evolution: ideas move between projects, implementations improve, and the prior art is rarely fully acknowledged. Elian’s view is that this iteration is a feature of open-source development, not a defect.

On AI’s effect on framework selection, he notes something worth taking seriously: the velocity of tooling development is now high enough that a novel framework built with AI assistance could become competitive within days of its first commit. Selecting a framework based on its trajectory assumes that the trajectory is stable. That assumption is less safe than it was two years ago.

React Bricks is where the architectural conversation Elian describes becomes actionable for teams building visual, CMS-driven sites. The combination of a defined component design system, fine-grained editor permissions, and a headless backend gives you what a tightly coupled CMS offers in editorial experience and what a headless CMS offers in technical freedom. The permission model — where you decide exactly what editors can change, down to individual fields and layout slots — means your design system stays intact without developer involvement in every content change. If your team is hitting the ceiling of what WordPress or a basic headless setup can do, React Bricks is the most direct path to resolving that constraint without rebuilding your front end.