Ik ga iets zeggen wat wat stof kan doen opwaaien: ik ben aan het einde van 2025 gestopt met het gebruiken van Tailwind CSS op nieuwe projecten, en ik heb niet achteromgekeken. Niet omdat Tailwind slecht is -- het is werkelijk uitstekend in wat het doet. Maar omdat vanilla CSS zo goed is geworden dat de afwegingen niet langer zinvol zijn voor de soorten projecten die wij bouwen.

Design tokens staan centraal in deze verschuiving. Het idee om je designbeslissingen op te slaan als herbruikbare, platformonafhankelijke variabelen is niet nieuw. Maar de tooling en browserondersteuning voor CSS custom properties in 2026 zijn zo volwassen geworden dat je een volledig design token systeem kunt bouwen zonder build stappen, zonder afhankelijkheden, en zonder het onthouden van utility class naamgeving. Laat me je laten zien hoe.

Inhoudsopgave

Vanilla CSS Design Tokens Without Tailwind in 2026

Wat Design Tokens Werkelijk Zijn

Design tokens zijn de atomaire waarden die je visuele taal definiëren. Kleuren, afstand, typografie, schaduwen, grensstralen, animatieduur -- alles wat een designbeslissing vertegenwoordigt. De term werd bedacht door het designteam van Salesforce in 2014, maar het concept is aanzienlijk geëvolueerd.

Hier is het belangrijkste inzicht dat de meesten missen: design tokens zijn niet zomaar variabelen. Het zijn een contract tussen design en engineering. Wanneer je designer zegt "gebruik de primaire actiekleur," wordt dat aan een token toegewezen, niet aan een hex-waarde. Wanneer ze zeggen "matige afstand," is dat ook een token.

De W3C Design Tokens Community Group publiceerde de Design Tokens Format Module specificatie, en hoewel deze nog steeds evolueert, zijn de kernideeën gestabiliseerd. Tokens bestaan in lagen:

  1. Primitieve tokens (onbewerkte waarden zoals #1a73e8 of 16px)
  2. Semantische tokens (doelgericht aliases zoals color-action-primary)
  3. Component tokens (beperkt tot specifieke UI-elementen zoals button-background)

Deze drielaagse architectuur is wat grote systemen beheersbaar maakt. CSS custom properties passen hier perfect in.

Waarom Vanilla CSS Mij Won

Wees eerlijk over mijn traject. Ik gebruikte Tailwind jarenlang gelukkig. Bouwde productiesites mee. Beviel het aan klanten. Maar verschillende dingen veranderden:

CSS heeft ingehaald. Nesting, :has(), container queries, @layer, @scope, color-mix(), oklch(), relatieve kleur syntaxis -- dit zijn geen experimentele functies meer. Het zijn basislijn in elke grote browser in 2026. De kloof die utility frameworks opvulden? Die is dramatisch gekrompen.

Bundlegrootte is belangrijker dan ooit. Met Core Web Vitals die direct invloed hebben op zoekrankings, telt elke kilobyte. Een goed gestructureerd vanilla CSS token systeem weegt bijna niets. Tailwind's JIT compiler is slim, maar het stuurt nog steeds CSS voor elke utility die je gebruikt.

Onderhoudskosten zijn reëel. Ik heb Tailwind projecten overgenomen waar componenten 30+ utility classes bevatten. Het lezen van className="flex items-center justify-between px-4 py-2 bg-white dark:bg-gray-800 rounded-lg shadow-sm hover:shadow-md transition-shadow duration-200 border border-gray-200 dark:border-gray-700" is niet leuk. Met design tokens en een dunne CSS laag is de intentie duidelijker.

Design-engineering handoff verbeterd. Wanneer tokens in CSS overeenkomen met tokens in Figma 1:1, worden gesprekken nauwkeurig. Niet meer "welke Tailwind class maps naar deze Figma variabele?"

Dit is geen heilige oorlog. Als Tailwind voor je team werkt, blijf het gebruiken. Maar als je iets nieuws start en maximale controle wilt met minimale abstractie, zijn vanilla CSS tokens ernstig overwegen waard.

Je Token Architectuur Instellen

Laten we dit van nul opbouwen. Ik gebruik de bestandsstructuur die we hebben verfijnd in meerdere headless CMS projecten bij Social Animal, maar pas het aan je behoeften aan.

Het kernprincipe: tokens vloeien naar beneden door specificiteitlagen.

tokens/
├── primitives.css       /* Onbewerkte waarden */
├── semantic.css         /* Doelgerichte aliases */
├── components/
│   ├── button.css
│   ├── card.css
│   └── input.css
├── themes/
│   ├── light.css
│   └── dark.css
└── index.css            /* Import orchestratie */

Je index.css gebruikt @layer om een duidelijke cascade in te stellen:

@layer primitives, semantic, themes, components;

@import './primitives.css' layer(primitives);
@import './semantic.css' layer(semantic);
@import './themes/light.css' layer(themes);
@import './components/button.css' layer(components);
@import './components/card.css' layer(components);
@import './components/input.css' layer(components);

Dit is belangrijk. @layer geeft je expliciete controle over de cascade zonder tegen specificiteit te vechten. Primitieven worden overschreven door semantische tokens, die worden overschreven door thema's, die worden overschreven door componenten. Schone hiërarchie.

Vanilla CSS Design Tokens Without Tailwind in 2026 - architectuur

Primitieve Tokens: Je Onbewerkte Waarden

Primitieven zijn je palet. Ze zijn niet bedoeld om direct in componenten te worden gebruikt -- denk aan hen als de verf op je plank voordat je beslist wat je gaat schilderen.

/* primitives.css */
:root {
  /* Kleuren met OKLCH voor perceptueel uniforme paletten */
  --color-blue-50: oklch(0.97 0.01 250);
  --color-blue-100: oklch(0.93 0.03 250);
  --color-blue-200: oklch(0.87 0.06 250);
  --color-blue-300: oklch(0.78 0.10 250);
  --color-blue-400: oklch(0.68 0.15 250);
  --color-blue-500: oklch(0.58 0.19 250);
  --color-blue-600: oklch(0.50 0.19 250);
  --color-blue-700: oklch(0.42 0.17 250);
  --color-blue-800: oklch(0.35 0.14 250);
  --color-blue-900: oklch(0.27 0.10 250);

  /* Afstandsschaal (modulair, gebaseerd op 4px raster) */
  --space-1: 0.25rem;   /* 4px */
  --space-2: 0.5rem;    /* 8px */
  --space-3: 0.75rem;   /* 12px */
  --space-4: 1rem;      /* 16px */
  --space-5: 1.25rem;   /* 20px */
  --space-6: 1.5rem;    /* 24px */
  --space-8: 2rem;      /* 32px */
  --space-10: 2.5rem;   /* 40px */
  --space-12: 3rem;     /* 48px */
  --space-16: 4rem;     /* 64px */
  --space-20: 5rem;     /* 80px */
  --space-24: 6rem;     /* 96px */

  /* Typografieschaal */
  --font-size-xs: 0.75rem;
  --font-size-sm: 0.875rem;
  --font-size-base: 1rem;
  --font-size-md: 1.125rem;
  --font-size-lg: 1.25rem;
  --font-size-xl: 1.5rem;
  --font-size-2xl: 1.875rem;
  --font-size-3xl: 2.25rem;
  --font-size-4xl: 3rem;

  /* Lettertypewichten */
  --font-weight-normal: 400;
  --font-weight-medium: 500;
  --font-weight-semibold: 600;
  --font-weight-bold: 700;

  /* Grensstralen */
  --radius-sm: 0.25rem;
  --radius-md: 0.5rem;
  --radius-lg: 0.75rem;
  --radius-xl: 1rem;
  --radius-full: 9999px;

  /* Schaduwen */
  --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.05);
  --shadow-md: 0 4px 6px oklch(0 0 0 / 0.07);
  --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.1);
  --shadow-xl: 0 20px 25px oklch(0 0 0 / 0.1);

  /* Durations */
  --duration-fast: 100ms;
  --duration-normal: 200ms;
  --duration-slow: 300ms;
  --duration-slower: 500ms;
}

Ik gebruik OKLCH hier omdat het werkelijk een betere kleurruimte is. Anders dan HSL, is lichtheid in OKLCH perceptueel uniform -- een helderheid van 0,5 ziet er daadwerkelijk uit als middengrijs, ongeacht de tint. Je kleurschalen zien er consistent uit over het hele spectrum. Alle grote browsers ondersteunen het nu.

Semantische Tokens: Waar de Magie Gebeurt

Semantische tokens verwijzen naar primitieven en geven ze betekenis. Dit is de laag die theming mogelijk maakt en je CSS zelfverklarend maakt.

/* semantic.css */
:root {
  /* Oppervlaktekleuren */
  --color-surface-primary: var(--color-white, #fff);
  --color-surface-secondary: var(--color-gray-50);
  --color-surface-tertiary: var(--color-gray-100);
  --color-surface-inverse: var(--color-gray-900);

  /* Tekstkleuren */
  --color-text-primary: var(--color-gray-900);
  --color-text-secondary: var(--color-gray-600);
  --color-text-tertiary: var(--color-gray-400);
  --color-text-inverse: var(--color-white, #fff);
  --color-text-link: var(--color-blue-600);
  --color-text-link-hover: var(--color-blue-700);

  /* ActiekleuRen */
  --color-action-primary: var(--color-blue-600);
  --color-action-primary-hover: var(--color-blue-700);
  --color-action-primary-active: var(--color-blue-800);

  /* Feedbackkleuren */
  --color-feedback-success: var(--color-green-600);
  --color-feedback-warning: var(--color-amber-500);
  --color-feedback-error: var(--color-red-600);
  --color-feedback-info: var(--color-blue-500);

  /* Grenskleuren */
  --color-border-primary: var(--color-gray-200);
  --color-border-secondary: var(--color-gray-100);
  --color-border-focus: var(--color-blue-500);

  /* Semantische afstand */
  --space-inline-xs: var(--space-1);
  --space-inline-sm: var(--space-2);
  --space-inline-md: var(--space-4);
  --space-inline-lg: var(--space-6);
  --space-stack-xs: var(--space-1);
  --space-stack-sm: var(--space-2);
  --space-stack-md: var(--space-4);
  --space-stack-lg: var(--space-8);
  --space-stack-xl: var(--space-12);
}

Merk op dat hier niets een hardgecodeerde waarde is. Alles verwijst naar primitieven. Als je morgen een nieuw merk wilt, wijzig je primitieven. Als je wilt aanpassen hoe "primaire actie" aanvoelt, wijzig je semantische tokens. De componentcode hoeft nooit iets te weten.

Component Tokens: De Laatste Laag

Component tokens beperken designbeslissingen tot specifieke UI-elementen. Dit is optioneel voor kleine projecten, maar essentieel voor alles met een design system.

/* components/button.css */
.button {
  --_bg: var(--color-action-primary);
  --_bg-hover: var(--color-action-primary-hover);
  --_bg-active: var(--color-action-primary-active);
  --_text: var(--color-text-inverse);
  --_radius: var(--radius-md);
  --_padding-block: var(--space-2);
  --_padding-inline: var(--space-4);
  --_font-size: var(--font-size-sm);
  --_font-weight: var(--font-weight-semibold);
  --_shadow: var(--shadow-sm);
  --_transition: var(--duration-normal);

  display: inline-flex;
  align-items: center;
  gap: var(--space-2);
  padding: var(--_padding-block) var(--_padding-inline);
  background: var(--_bg);
  color: var(--_text);
  font-size: var(--_font-size);
  font-weight: var(--_font-weight);
  border-radius: var(--_radius);
  box-shadow: var(--_shadow);
  transition: background var(--_transition), box-shadow var(--_transition);
  border: none;
  cursor: pointer;

  &:hover {
    background: var(--_bg-hover);
    box-shadow: var(--shadow-md);
  }

  &:active {
    background: var(--_bg-active);
  }

  &.--secondary {
    --_bg: transparent;
    --_text: var(--color-action-primary);
    --_shadow: none;
    border: 1px solid var(--color-border-primary);

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }

  &.--ghost {
    --_bg: transparent;
    --_text: var(--color-text-primary);
    --_shadow: none;

    &:hover {
      --_bg: var(--color-surface-secondary);
    }
  }
}

De --_ voorvoegsel conventie (met onderstreping) signaleert "privé" component tokens. Het wordt niet afgedwongen door de browser, maar het is een duidelijk signaal voor andere ontwikkelaars: deze tokens zijn intern voor deze component.

Ook -- let op hoe CSS nesting hier werkt. Geen preprocessor nodig. Dit is native CSS in 2026.

Dark Mode en Theming Zonder Framework

Hier betaalt de token architectuur zich echt uit. Dark mode wordt een kwestie van het opnieuw toewijzen van semantische tokens.

/* themes/dark.css */
@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-primary: var(--color-gray-900);
    --color-surface-secondary: var(--color-gray-800);
    --color-surface-tertiary: var(--color-gray-700);
    --color-surface-inverse: var(--color-white, #fff);

    --color-text-primary: var(--color-gray-50);
    --color-text-secondary: var(--color-gray-300);
    --color-text-tertiary: var(--color-gray-500);
    --color-text-inverse: var(--color-gray-900);
    --color-text-link: var(--color-blue-400);
    --color-text-link-hover: var(--color-blue-300);

    --color-border-primary: var(--color-gray-700);
    --color-border-secondary: var(--color-gray-800);

    --shadow-sm: 0 1px 2px oklch(0 0 0 / 0.2);
    --shadow-md: 0 4px 6px oklch(0 0 0 / 0.3);
    --shadow-lg: 0 10px 15px oklch(0 0 0 / 0.4);
  }
}

/* Handmatige toggle ondersteuning */
[data-theme="dark"] {
  --color-surface-primary: var(--color-gray-900);
  /* ... dezelfde overschrijvingen ... */
}

Je componenten veranderen helemaal niet. Nul dark mode klassen. Nul voorwaardelijke logica. De tokens regelen alles.

Wil je een merkthema voor een white-label klant? Hetzelfde patroon:

[data-theme="client-acme"] {
  --color-blue-500: oklch(0.55 0.20 280); /* Hun paars in plaats van blauw */
  --color-action-primary: var(--color-blue-500);
  --radius-md: 1rem; /* Ze houden van rondere hoeken */
}

Wij gebruiken deze aanpak uitgebreid in onze Next.js development projecten waar multi-tenant theming een veel voorkomende vereiste is.

Responsive Tokens Met Container Queries

Dit is iets wat je werkelijk niet elegant met Tailwind kunt doen (in ieder geval niet). Container queries laten je token waarden veranderen op basis van de containergrootte, niet alleen de viewportgrootte.

.card-grid {
  container-type: inline-size;
  container-name: card-grid;
}

@container card-grid (max-width: 500px) {
  .card {
    --_padding: var(--space-3);
    --_title-size: var(--font-size-base);
    --_gap: var(--space-2);
  }
}

@container card-grid (min-width: 501px) {
  .card {
    --_padding: var(--space-6);
    --_title-size: var(--font-size-lg);
    --_gap: var(--space-4);
  }
}

Componenten die reageren op hun eigen context in plaats van de viewport. Dit is bijzonder krachtig bij het bouwen van componentbibliotheken voor Astro sites waar componenten over veel verschillende layouts opnieuw worden gebruikt.

Design Tokens Synchroniseren Met Figma

Figma Variables (gelanceerd in 2023, aanzienlijk uitgebreid sinds) aansluiting direct op ons drielaagse token model. Hier is de workflow:

  1. Definieer tokens in Figma met behulp van hun Variables panel (primitieven → semantisch → component)
  2. Export tokens met behulp van de Tokens Studio plugin of Figma's REST API
  3. Transformatie naar CSS met behulp van Style Dictionary of de nieuwere Cobalt UI tools
  4. Commit naar je repo als je tokens/ directory

Een Style Dictionary config voor CSS output ziet er zo uit:

{
  "source": ["tokens/**/*.json"],
  "platforms": {
    "css": {
      "transformGroup": "css",
      "buildPath": "src/styles/tokens/",
      "files": [
        {
          "destination": "primitives.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/primitives" }
        },
        {
          "destination": "semantic.css",
          "format": "css/variables",
          "filter": { "filePath": "tokens/semantic" }
        }
      ]
    }
  }
}

Het resultaat is een CI pijplijn waar design veranderingen in Figma automatisch in je CSS tokens stromen. Geen handmatige vertaling, geen drift.

Prestatievergelijking: Vanilla CSS vs Tailwind

Ik heb benchmarks uitgevoerd op een echte marketingsite die we herbouwden -- hetzelfde ontwerp, twee implementaties. Hier zijn de cijfers:

Metriek Tailwind v4 Vanilla CSS Tokens Verschil
Totale CSS grootte (gzipped) 14.2 KB 6.8 KB -52%
First Contentful Paint 1.2s 1.0s -17%
Largest Contentful Paint 2.1s 1.8s -14%
CSS parse tijd 3.2ms 1.4ms -56%
HTML grootte (gzipped) 28.4 KB 22.1 KB -22%
Build tijd 1.8s 0.4s* -78%

*Vanilla CSS met alleen @import bundeling via Lightning CSS.

Het verschil in HTML-grootte is opmerkelijk -- Tailwind's utility classes voegen aanzienlijk gewicht toe aan je markup. Op een pagina met 200+ elementen, voegen die class strings op.

Dat gezegd hebbende, Tailwind v4 (uitgebracht begin 2025) maakte grote verbeteringen met zijn Oxide engine. De kloof is kleiner geworden. Maar vanilla CSS zonder afhankelijkheden voor build is moeilijk te verslaan op pure prestaties.

Echte Bestanden Structuur voor Tokens

Hier is de werkelijke structuur uit een recent project -- een headless e-commerce site gebouwd met Next.js en Sanity:

src/styles/
├── tokens/
│   ├── primitives/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   ├── typography.css
│   │   ├── shadows.css
│   │   ├── borders.css
│   │   └── motion.css
│   ├── semantic/
│   │   ├── colors.css
│   │   ├── spacing.css
│   │   └── typography.css
│   ├── themes/
│   │   ├── light.css
│   │   ├── dark.css
│   │   └── high-contrast.css
│   └── index.css
├── components/
│   ├── button.css
│   ├── card.css
│   ├── input.css
│   ├── modal.css
│   ├── navigation.css
│   └── typography.css
├── layouts/
│   ├── grid.css
│   └── container.css
├── utilities/
│   └── helpers.css          /* Een paar utility classes die we echt nodig hebben */
├── reset.css
└── main.css

Het utilities/helpers.css bestand is interessant -- ik schrijf nog steeds een handvol utility classes voor werkelijk herbruikbare patronen:

/* utilities/helpers.css */
.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

.flow > * + * {
  margin-block-start: var(--flow-space, var(--space-stack-md));
}

.cluster {
  display: flex;
  flex-wrap: wrap;
  gap: var(--cluster-gap, var(--space-inline-md));
  align-items: center;
}

Merk op dat zelfs de utilities verwijzen naar tokens. Alles blijft verbonden.

Tooling Die Dit Praktisch Maakt

Je hebt niet veel nodig, maar een paar tools maken de DX aanzienlijk beter:

Tool Doel Opmerkingen
Lightning CSS Bundeling, minificatie, vendor prefixing Vervangt PostCSS voor de meeste use cases. Ongelooflijk snel.
Style Dictionary 4 Token format transformatie Figma → CSS, iOS, Android vanuit één bron
Cobalt UI W3C DTCG token tooling Nieuwer alternatief voor Style Dictionary, spec-aligned
Tokens Studio Figma plugin voor token beheer Beste Figma integratie van zijn klasse
CSS Utility Kit (VS Code) Autocomplete voor custom properties Toont token waarden op hover
Open Props Voorgemaakte CSS custom property bibliotheek Goed startpunt als je niet zelf wilt bouwen

Lightning CSS verdient speciale aandacht. Geschreven in Rust, het verwerkt @import inlining, nesting compilatie voor oudere browsers, en minificatie in één pass. Dit is wat we nu gebruiken in de meeste van onze headless CMS builds.

lightningcss --bundle --minify src/styles/main.css -o dist/styles.css

Dat is alles. Geen PostCSS config. Geen plugin ketting. Één commando.

Veelgestelde Vragen

Kan ik design tokens gebruiken zonder een build stap?

Absoluut. Als je moderne browsers aanstreeft (en in 2026 zou je dat moeten doen), werken native CSS custom properties zonder enige compilatie. Het enige wat je verliest is @import bundeling in één bestand -- browsers verwerken meerdere CSS bestandimporten prima, hoewel je voor productieprestaties wilt bundelen. Lightning CSS of zelfs een eenvoudig cat commando kan dat aanpakken.

Hoe vergelijken vanilla CSS design tokens met Tailwind v4?

Tailwind v4 verhuisde daadwerkelijk naar CSS custom properties intern, wat de aanpak valideert. Het verschil zit in developer experience: Tailwind geeft je utility classes om in HTML toe te passen, terwijl vanilla tokens je designvariabelen geeft om in je eigen CSS te gebruiken. Vanilla tokens produceren kleinere CSS en HTML output, bieden meer flexibiliteit voor theming, en vereisen niet het leren van een class naming systeem. Tailwind biedt sneller prototyping en sterkere consistency enforcement voor grotere teams.

Wat doen met TypeScript type safety voor design tokens?

Als je CSS Modules of CSS-in-JS gebruikt, kun je TypeScript types genereren uit je token bestanden. Style Dictionary 4 en Cobalt UI ondersteunen beide TypeScript output. Voor pure CSS geven VS Code extensies zoals CSS Variable Autocomplete je editor-level safety met autocomplete en validatie.

Zou ik Open Props moeten gebruiken in plaats van mijn eigen tokens te bouwen?

Open Props is een uitstekend startpunt, vooral voor prototypes of kleinere projecten. Het biedt een goed ontworpen set CSS custom properties uit de doos. Voor production design systems wil je waarschijnlijk je eigen primitieven definiëren die op je merk aansluiten. Je kunt Open Props als referentie gebruiken en zijn aanpak voor dingen zoals easing functions of shadow scales uit selecteren.

Hoe hanteer ik design tokens in een monorepo met meerdere apps?

Maak een gedeeld tokens pakket dat je CSS bestanden exporteert. Elke app importeert het token pakket en kan zijn eigen theme overschrijvingen toevoegen. Dit werkt mooi met workspaces in pnpm of npm. We hebben dit gedaan voor multi-merk e-commerce klanten waar elk storefront dezelfde primitieve tokens deelt, maar unieke semantische mappings heeft.

Is vanilla CSS langzamer om mee te ontwikkelen dan Tailwind?

Aanvankelijk, ja -- je stelt infrastructuur in die Tailwind gratis geeft. Maar na de eerste week of twee is snelheid vergelijkbaar of sneller. Je schakelt niet context tussen HTML en een utility class referentie. Je schrijft CSS die als Engels leest. En als je iets moet wijzigen, wijzig je het op één plaats in plaats van te zoeken naar elk exemplaar van bg-blue-500.

Hoe overtuig ik mijn team om Tailwind los te laten?

Frame het niet als Tailwind loslaten -- frame het als het aannemen van design tokens. Begin met het introduceren van een token laag naast Tailwind: definieer je custom properties, verwijs er in een tailwind.config theme naar. In de loop der tijd kun je vinden dat het token systeem het meeste werk doet en Tailwind optioneel wordt. Laat het team daar organisch toe komen.

Wat doen met componentbibliotheken zoals Shadcn/UI die op Tailwind vertrouwen?

Shadcn/UI is fantastisch, maar zijn Tailwind afhankelijkheid is implementatiedetail, niet fundamentele architectuur. De componentpatronen en toegankelijkheidslogica zijn wat telt. Verschillende community forks zijn verschenen die vanilla CSS tokens gebruiken in plaats van Tailwind classes. Je kunt ook geleidelijk Shadcn componenten migreren om je token systeem te gebruiken -- de onderliggende Radix UI primitieven kunnen er niet om schelen hoe je ze stijlt.

Kan ik deze aanpak gebruiken met Astro of Next.js?

Absoluut. Beide frameworks verwerken vanilla CSS native zonder configuratie. Astro's scoped styles werken perfect met CSS custom properties omdat tokens gedefinieerd op :root natuurlijk in scoped component stijlen cascade. Next.js ondersteunt CSS Modules naast globale token bestanden. Wij gebruiken deze exacte setup in onze Next.js projecten en Astro builds regelmatig. Als je dit voor een nieuw project wilt verkennen, neem contact op met ons -- we helpen graag wat we hebben geleerd.