The Headless Story Is Bolted On

TYPO3 was designed as a traditional server-side CMS. Its native output is HTML rendered by Fluid templates. The EXT:headless extension — maintained by the TYPO3 Headless community, not TYPO3 GmbH — transforms this into a JSON API.

It works, and for teams that have invested in TYPO3 and need to expose content as an API, it's a reasonable path. But it's a community extension with its own release cycle, its own compatibility surface against TYPO3 core versions, and its own documentation. There's no SLA, no versioned API contract from TYPO3 GmbH, and no TypeScript SDK.

b10cks was designed as a headless CMS from day one. The API is the product. Every design decision — block architecture, localization, versioning, webhooks — was made to serve API consumers, not template renderers.

The Editorial Interface

TYPO3's backend interface (the "Backend") is powerful and highly configurable, but it has a learning curve that most teams acknowledge honestly. The content element paradigm (tt_content, TypoScript configuration, FlexForms for structured content) is not intuitive for non-technical editors. Onboarding typically requires structured training.

TYPO3 v12 and v13 introduced backend improvements and a refreshed UI — progress is real. But the fundamental mental model — page tree, content columns, TypoScript — remains distinct from how modern content teams work.

b10cks' visual editor sits inside the team's actual website. Editors click on elements they want to change and edit them in place. Onboarding is minimal because the interface is the product the editors use every day.

Localization: TYPO3's Real Strength

This is where TYPO3 genuinely leads. Its localization system — field-level translation, locale fallback chains, per-language page trees, translation status tracking — is among the most mature in any CMS. Organizations managing 20+ languages on complex site structures have relied on it for decades.

b10cks' localization is robust for most real-world requirements: field-level translation, locale inheritance, per-locale publish workflows, integration with professional translation tools (Lokalise, Phrase, DeepL). For teams making a fresh start, it covers the full feature set without legacy complexity.

For organizations already running deeply complex TYPO3 translation workflows, the maturity gap is worth honestly weighing.

Workspaces: TYPO3's Other Strength

TYPO3's Workspace module is one of the most powerful content staging systems in the CMS market. Editors can prepare entire versions of a site in an isolated workspace, compare against live content, preview, and release as a batch — across multiple pages, content elements, and locales simultaneously.

b10cks offers git-like version history, branching, and atomic releases: you can bundle multiple content changes into a single scheduled deployment. For most product content teams, this is more than sufficient.

For large editorial operations that manage complete site releases as atomic events — think government portals, large media sites at election time — TYPO3's Workspace system is a specialized tool b10cks doesn't match in depth.

The Developer Experience

Setting up a modern headless TYPO3 stack requires meaningful investment: TYPO3 core, EXT:headless configuration, TypoScript for API field mapping, a frontend framework integration (Nuxt-TYPO3 is the primary option), and configuration for FAL (File Abstraction Layer), caching, and CDN.

b10cks self-hosted deployment:

git clone https://github.com/b10cks/cms
cd cms && docker compose up

That's a running CMS. Add a domain. Connect your frontend via the TypeScript SDK.

The API is documented with an OpenAPI spec. Framework adapters exist for Next.js, Nuxt, Astro, and Vue. The content model is defined on the infinite canvas and immediately reflected in the API.

Content Modeling: Page Trees vs. Blocks

TYPO3 organizes content in a page tree: pages are the primary entity, and content elements live within page column regions. This model maps well to traditional websites but requires additional architectural decisions for content-as-a-service scenarios (shared content across multiple pages or channels).

b10cks organizes content as blocks: every content type is a composable, reusable block. Blocks can be referenced across pages and channels without duplication. The content model is defined visually and reflects API-first thinking: content isn't bound to a page location, it's a resource.