TypeScript in frontend en backend: wat één taal oplevert

Met TypeScript in de frontend en de backend kun je types delen. Verander je een veld in een API-response, dan wijst de typechecker aan beide kanten aan wat er stukgaat, voordat het in productie staat. Daarnaast kan een developer makkelijker een ticket oppakken dat aan beide kanten iets raakt. Er zijn ook grenzen: types bestaan alleen tijdens het bouwen, en voor sommige soorten werk is een andere taal beter.

Wat gedeelde types opleveren

Het grootste voordeel is één definitie van je API-contract. Zet de types voor requests en responses in een gedeeld package, en laat de frontend en de backend allebei daaruit importeren. Hernoem je in de backend customerName naar name, dan wijst de typechecker in de frontend elke plek aan die je moet aanpassen.

Zonder gedeelde types schrijf je het contract twee keer: één keer in de backend en één keer als interface in de frontend. Die twee lopen uit elkaar, en dat merk je pas als een veld leeg blijft op het scherm.

Ook werkt een developer makkelijker aan beide kanten. Wie vooral frontend doet, kan een extra veld aan een endpoint toevoegen zonder eerst een andere taal en andere tooling te leren. In een klein team scheelt dat overdrachten.

Types bestaan niet tijdens runtime

TypeScript controleert je code tijdens het bouwen. Tijdens het draaien is het gewoon JavaScript. Node.js kan tegenwoordig zelf TypeScript-bestanden uitvoeren door de types weg te halen. Dat staat standaard aan sinds Node.js 22.18 en 23.6, en de functie is stabiel sinds 24.12 en 25.2. Node.js controleert daarbij geen types, dus in CI heb je nog steeds een stap nodig die tsc --noEmit draait.

Belangrijker is dat data die binnenkomt niet gecontroleerd is. Een request body, een webhook of een response van een externe API kan alles bevatten, wat je type ook beweert. Valideer die data aan de rand van je systeem.

Mijn advies is om het schema de bron te maken en het type daarvan af te leiden. Met Zod schrijf je één schema, valideer je daarmee de input en haal je met z.infer het TypeScript-type eruit. Dat schema zet je in het gedeelde package, zodat de frontend het ook voor formuliervalidatie kan gebruiken.

Hoe je de types deelt

Het eenvoudigst is een monorepo, met frontend, backend en het gedeelde package naast elkaar. Een wijziging in het contract en de aanpassingen aan beide kanten zitten dan in één pull request. De afweging tussen een monorepo en losse repositories staat in monorepo of losse repositories.

Met losse repositories publiceer je het gedeelde package met een versienummer, of je genereert de types uit een OpenAPI-specificatie. Dat laatste werkt ook als de backend niet in TypeScript is geschreven. Een .NET- of Python-backend kan een OpenAPI-specificatie leveren waaruit de frontend zijn types genereert. Hoe je zo'n contract opzet, lees je in API-first ontwerpen.

Werven voor een TypeScript-stack

De groep developers die TypeScript kent, is groot. Volgens het Octoverse-rapport van GitHub werd TypeScript in augustus 2025 voor het eerst de meest gebruikte taal op GitHub, gemeten naar het aantal maandelijkse contributors. Het passeerde daarmee Python en JavaScript.

Een developer die TypeScript kent, kent daarmee nog niet beide kanten. Frontendwerk vraagt kennis van rendering en toegankelijkheid. Backendwerk vraagt kennis van databases, queues en beveiliging, en van wat er gebeurt als het druk wordt. Dezelfde taal maakt die kennis niet overdraagbaar. Let bij een "full-stack TypeScript"-profiel dus op waar iemand echt ervaring mee heeft. Welke stacks wij inzetten, zie je op de pagina technologie.

Waar één taal ophoudt

Voor data-analyse en machine learning zit je in Python dichter bij de bibliotheken die je nodig hebt. Zet daar liever een aparte Python-service naast je TypeScript-stack dan alles in één taal te willen houden. De types van die service genereer je weer uit de OpenAPI-specificatie.

Heb je al een werkende backend in .NET of Java, dan is één taal geen reden om die te herschrijven. Genereer de types uit de API-specificatie en laat de backend zoals hij is.

In grote codebases is typechecken traag. TypeScript 7.0 kwam in juli 2026 uit als native port van de compiler, geschreven in Go. Microsoft meldt bij volledige builds meestal 8 tot 12 keer kortere buildtijden. Die versie heeft nog geen API, en tooling die TypeScript inbouwt, zoals voor Vue, Svelte en Astro, kan daardoor waarschijnlijk nog niet overstappen. Kijk dus eerst naar je eigen toolchain voordat je de upgrade plant.

Afspraken voor gedeelde types

• Zet strict aan, in alle packages.
• Gebruik geen any in het gedeelde package. Weet je het type niet, gebruik dan unknown en valideer.
• Draai de typecheck in CI bij elke pull request, voor frontend en backend samen.
• Houd het gedeelde package klein: contracten en schema's, geen bedrijfslogica.
• Voer je TypeScript direct uit met Node.js, zet dan erasableSyntaxOnly aan. De compiler geeft dan een fout bij syntax die Node.js niet kan weghalen, zoals enums.

Bronnen

• Node.js: Modules: TypeScript
• TypeScript: erasableSyntaxOnly
• Microsoft: Announcing TypeScript 7.0
• GitHub Octoverse 2025
• Zod: basic usage en type inference