Hoe AI-tools JavaScript onverwacht populairder maken

Sophie Jansen · 2026-08-21

Stel je voor: het is augustus 2025 en ineens is TypeScript de meest gebruikte taal op GitHub. Dat is echt een enorme verschuiving, de grootste in tien jaar zelfs! En weet je wat? Het gebeurde precies toen we massaal begonnen met het omarmen van AI-code-assistenten. Eerder dachten we dat deze AI-hulpjes de keuze van een programmeertaal minder belangrijk zouden maken. Organisaties zouden dan gewoon de beste technologie kiezen voor hun probleem, zonder zich druk te maken over welke ontwikkelaars er beschikbaar waren. Maar wat blijkt? Twee jaar na de doorbraak van AI-code-tools is de markt juist beperkter geworden. Er is een duidelijke focus op een specifieke taalfamilie. ### Een kijkje in de cijfers Laten we eens naar de feiten kijken. Het Octoverse-rapport van GitHub uit oktober 2025 toonde aan dat TypeScript 2,64 miljoen maandelijkse bijdragers had. Dat is een waanzinnige stijging van 66% vergeleken met het jaar ervoor! In 2025 alleen al begonnen meer dan een miljoen ontwikkelaars met hun eerste TypeScript-code op GitHub. Dit is extra indrukwekkend, want JavaScript was al superdominant. Uit een ontwikkelaarsenquête van Stack Overflow in 2025, met meer dan 49.000 reacties, bleek dat 66% van de respondenten JavaScript gebruikte. Sinds 2011 staat JavaScript bijna elk jaar bovenaan. Kortom, de JavaScript-familie is niet alleen de meest gebruikte, maar ook de snelst groeiende op GitHub. Natuurlijk, je moet altijd kritisch blijven op de telmethode van GitHub. Ze tellen immers activiteit op hun eigen platform, wat een beetje belangenverstrengeling kan opleveren. En modetrends spelen ook een rol in wat er in openbare repositories verschijnt. Maar toch, de indicatoren komen goed overeen met andere enquêtes, dus er zit zeker een kern van waarheid in. ### Waarom AI zo dol is op JavaScript Het principe is eigenlijk heel simpel: AI-modellen leren van bestaande code. En raad eens welke code het meest wordt gepubliceerd? Juist, JavaScript en TypeScript. Sterker nog, een groot deel van die code draait om React. Dit zorgt voor een opmerkelijk verschil in de output van AI-assistenten. Als je een code-assistent vraagt om een getypeerd React-component te genereren, is de output vaak direct bruikbaar. Het compileert, voldoet aan de standaarden en heeft minimale aanpassingen nodig. Vraag je echter hetzelfde voor Svelte, Solid, of een minder populair backend-framework, dan is de output veel magerder. Je zult dan vaker vreemde API's zien en de basisstructuur heeft veel meer correcties nodig voordat het werkt. Dit heeft grote gevolgen voor hoe teams nu hun technologie kiezen. Het gaat niet langer alleen om de meest efficiënte of gebruiksvriendelijke framework. Nee, het draait nu om welk framework het beste samenwerkt met de AI-tools van het team. De productiviteitskloof die ontstaat door bruikbare AI-output tijdens een lange ontwikkelingscyclus wordt steeds groter. En wanneer een team iets produceert, wordt dat gepubliceerd, verzameld en gebruikt voor toekomstige AI-trainingen, waardoor die kloof alleen maar groter wordt. Dit betekent overigens niet dat Svelte of Solid slecht zijn. Integendeel, het zijn prima frameworks en sommige modernere frameworks zijn zelfs sneller dan React. Maar de markt beloont nu eenmaal de keuzes die de AI-modellen al kennen. ### Python voor ontwikkeling, JavaScript voor de gebruiker Je zou kunnen tegenwerpen dat AI-ontwikkeling toch vooral in Python gebeurt. Model training, evaluatie en de meeste onderzoekstools draaien inderdaad in Python, en dat is niet veranderd. Maar wat de klant uiteindelijk ziet en gebruikt, is zelden in Python geschreven. De frontend van een AI-product is eigenlijk een venster dat informatie doorgeeft. Het heeft ook knoppen nodig om tools uit te voeren, een goedkeuringsstap voor mogelijke negatieve uitkomsten, en een duidelijke uitleg van wat het systeem heeft gedaan en waarom.