MDX Developer-First Websites — Geen CMS Lock-In

Je inhoud mag niet gevangen zitten in iemands anders database

Elke keer als je inhoud naar een propriëtair CMS stuurt, sluit je een weddenschapje af. Je weddt erop dat de leverancier de prijzen niet gaat verhogen, geen functies gaat schrappen en niet door een ander bedrijf wordt overgenomen dat niets om je workflow geeft. Meestal verlies je die weddenschapje.

MDX draait het model om. Je inhoud leeft in je repository als Markdown-bestanden aangevuld met JSX-componenten. Het is versiebeheerd, draagbaar en volledig van jou. Geen API-sleutels die om 2 uur 's nachts verlopen, geen migratienachtmerries, geen leverancier die je inhoud gijzelt.

Bij Social Animal bouwen we MDX-aangedreven websites die ontwikkelingsteams volledige controle geven over content-architectuur terwijl de schrijfervaring schoon en snel blijft.

Wat is MDX en waarom doet het eraan?

MDX is Markdown voor het componenttijdperk. Het laat je standaard Markdown schrijven en React (of JSX-compatibele) componenten direct in je contentbestanden inbedden. Zie het als de brug tussen ontwikkelingstools en contentschrijving.

Een typisch MDX-bestand ziet er zo uit:

# Product Launch Announcement

We're shipping the new dashboard today.

<FeatureGrid features={launchFeatures} />

Read the full changelog [here](/changelog).

<CallToAction variant="primary" />

Dat is echte inhoud met echte componenten, die in een .mdx-bestand in je Git-repo leven. Geen CMS-beheerpaneel nodig. Geen REST API-aanroepen om een kop te renderen.

Waarom ontwikkelaars MDX prefereren

• Git-native workflow: inhoud gaat door dezelfde PR-, review- en deploypijplijn als code
• Type-veilige componenten: je contentcomponenten worden bij het bouwen gevalideerd, niet bij runtime
• Nul runtimekosten: MDX compileert naar statische HTML — geen client-side Markdown-parsing
• Volledige JSX-mogelijkheden: interactieve grafieken, ingebedde demo's, dynamische tabellen — allemaal inline met je tekst
• Geen leverancierafhankelijkheid: als je van framework wisselt, komen je .mdx-bestanden met je mee

Het vendor lock-in-probleem is echt

We hebben klanten van Contentful, Prismic, Sanity en WordPress af gemigreerd — soms allemaal in dezelfde kwartaal. Het patroon is altijd hetzelfde:

1. Een team kiest een CMS omdat het er goed uitziet in een demo
2. Ze bouwen diep gekoppelde templates rond propriëtaire content-modellen
3. Het CMS verandert prijzen, beëindigt een API-versie of introduceert breaking changes
4. Migratie wordt een project van meerdere sprints dat functiewerk blokkeert

Met MDX is migratie geen probleem. Je inhoud zijn bestanden. Bestanden zitten in mappen. Mappen zitten in Git. Van Next.js naar Astro? Je MDX-bestanden hebben er geen probleem mee — ze werken in beide.

Wat "geen vendor lock-in" echt betekent

Het betekent niet dat we tegen CMS zijn. Het betekent dat je contentlaag geen enkel kritiek foutpunt heeft dat jij niet beheerst. Specifiek:

• Geen propriëtaire content-modellen — je schema is in code gedefinieerd, niet in het dashboard van een leverancier
• Geen API-afhankelijkheid voor builds — inhoud is lokaal, builds zijn snel en deterministisch
• Geen prijsverrassingen per gebruiker — er is geen SaaS-rekening gekoppeld aan je inhoud
• Geen migratiebelasting — het wisselen van frameworks of hosts vereist geen herplatforming van inhoud

Onze benadering van MDX-first-architectuur

We stoppen niet zomaar MDX-bestanden in een /content-map en noemen het klaar. We bouwen een goede content-architectuur die schaalt.

Content-schema met frontmatter-validatie

Elk MDX-bestand krijgt een gevalideerd frontmatter-schema met Zod of een vergelijkbare runtime-validator. Je inhoud heeft geforceerde structuur — verplichte velden, getypte datums, gevalideerde slugs — zonder dat een CMS dit hoeft in te stellen.

const postSchema = z.object({
  title: z.string().max(70),
  date: z.coerce.date(),
  tags: z.array(z.string()),
  draft: z.boolean().default(false),
});

Push een malformed contentbestand en de build mislukt met een duidelijke fout. Dat is betere validatie dan de meeste CMS-platforms bieden.

Aangepaste componentbibliotheken

We bouwen herbruikbare MDX-componentsets afgestemd op je contentbehoeften. Veelgebruikte voorbeelden:

• <Callout> — gestylde tip-, waarschuwings- en info-blokken
• <CodeDemo> — live codevoorbeelden met syntaxisaccentuering
• <ComparisonTable> — gestructureerde vergelijkingen van functies
• <VideoEmbed> — responsieve, lazy-loaded video met juiste hoogte-breedteverhoudingen
• <PricingCard> — dynamische prijscomponenten die uit je datalaag trekken

Deze componenten zijn gedocumenteerd, getest en met versiebeheer voorzien naast je inhoud.

Content-collecties en typeveiligheid

Met behulp van Astro's Content Collections of Next.js met aangepaste loaders, creëren we volledig getypte content-API's. Je IDE vult contentsvelden in. TypeScript vangt verbroken verwijzingen op vóór deployment. Eerlijk gezegd slaat de DX elke CMS GraphQL Explorer die ik heb gebruikt.

Authoring-opties voor niet-ontwikkelaars

MDX betekent niet dat iedereen in VS Code hoeft te leven. We voegen lightweight bewerkingslagen toe wanneer nodig:

• Prose Mirror of TinaCMS voor visuele bewerking met Git-gesteunde opslag
• Decap CMS (voorheen Netlify CMS) voor een eenvoudig beheerpaneel dat naar je repo commit
• GitHub's ingebouwde editor met preview-workflows voor snelle correcties
• Aangepaste beheerdashboards met behulp van server actions die MDX-bestanden programmatisch committen

De inhoud blijft in Git. De bewerkingservaring past zich aan aan wie dan ook schrijft.

Technologie-stack

Onze MDX-builds draaien doorgaans op:

• Next.js 14+ met next-mdx-remote of @next/mdx voor App Router-integratie
• Astro met native MDX-ondersteuning en Content Collections voor statische-first sites
• Rehype en Remark-plugins voor syntaxisaccentuering, inhoudsopgavegeneratie, linkverwerking en afbeeldingsoptimalisatie
• Tailwind CSS voor componentstijling met designtokens
• Vercel of Netlify voor deployment met directe rollbacks (je inhoud zit in Git, dus elke deployment is reversibel)

Wat je krijgt

Wanneer we een MDX-first website opleveren, loop je weg met:

• Een volledig geïmplementeerde site met subsecondeladen van pagina's
• Een gedocumenteerd content-schema met validatie
• Een aangepaste MDX-componentbibliotheek
• Een Git-gebaseerde contentworkflow met preview-deployments
• Nul maandelijkse CMS-kosten
• Volledig eigendom van elk contentbestand, component en configuratie
• Een migratiepad dat niet bestaat — omdat er niets is om uit te migreren

Voor wie dit geschikt is

MDX-first-architectuur is een sterke keuze voor:

• Developer tool-bedrijven die docs, blogs en marketingpagina's in één stack willen
• Startups die niet €300/maand voor een CMS willen betalen voordat ze inkomsten hebben
• Agencies die ervan af willen zijn om CMS-integraties op dozijnen clientsites te onderhouden
• Engineeringteams die inhoud in hun monorepo willen, niet in een dashboard van derden

Als je team zich comfortabel voelt met Git en je langetermijnbezit meer waardeert dan kortetermijngemak, is MDX de juiste keuze.