Wat is JavaScript?

JavaScript is de programmeertaal die websites interactief maakt. HTML bepaalt wat er staat, CSS hoe het eruitziet, en JavaScript wat er gebeurt als je iets doet.

Een menu dat opengaat, een formulier dat controleert wat je invult, een kaart die je kunt slepen, een winkelmandje dat bijwerkt zonder dat de pagina opnieuw laadt. Op vrijwel elke website draait het, meestal zonder dat je het merkt en soms zo veel dat je het merkt aan de laadtijd.

Waar de taal vandaan komt

Brendan Eich schreef de eerste versie in 1995 bij Netscape, in een paar weken tijd. De taal heette eerst Mocha, daarna LiveScript, en kreeg vlak voor de lancering de naam JavaScript omdat Java op dat moment populair was. Het zijn compleet verschillende talen en die naamgelijkenis levert al dertig jaar verwarring op.

In 1997 werd de taal vastgelegd als standaard onder de naam ECMAScript. Die naam zie je terug in versienummers. ECMAScript 2015, ook bekend als ES6, was de grote verbouwing die de taal bruikbaar maakte voor grotere projecten. Sindsdien verschijnt er elk jaar een versie met een handvol toevoegingen.

Praktisch betekent dat: code van voor 2015 ziet er anders uit dan code van nu. Een handleiding waarin overal het woord var staat, is oud.

Waar het draait

Oorspronkelijk alleen in de browser van je bezoeker. Dat is nog steeds de belangrijkste plek: de code wordt meegestuurd met de pagina en uitgevoerd op het apparaat van de bezoeker, niet op jouw server.

Elke browser heeft daarvoor een eigen motor. Chrome en Edge gebruiken V8, Firefox gebruikt SpiderMonkey, Safari gebruikt JavaScriptCore. Die motoren vertalen je code tijdens het uitvoeren naar machinetaal, waardoor JavaScript sneller is dan mensen aannemen.

Eén eigenschap verklaart bijna alles wat er misgaat: een pagina heeft maar één draad om code op uit te voeren. Terwijl jouw script rekent, kan de browser niets anders doen. Geen knop indrukken, geen scrollen, geen tekst selecteren.

Sinds Node.js in 2009 draait dezelfde taal ook op servers, waarmee je met één taal de voorkant en de achterkant kunt bouwen. Wat dat inhoudt staat in het artikel over Node.js.

Hoe de taal er in het kort uitziet

Je maakt waarden aan en geeft ze een naam. Sinds 2015 doe je dat met let voor iets dat verandert en met const voor iets dat gelijk blijft. De taal kent getallen, tekst, waar of niet waar, lijsten en objecten. Een object is een verzameling namen met waarden erachter, en daarmee wordt vrijwel alles in JavaScript gebouwd.

Wat de taal berucht maakt is dat ze soepel omgaat met types. Zet je een getal naast tekst met een plusteken, dan plakt hij ze aan elkaar in plaats van te rekenen. Vergelijk je met twee istekens, dan maakt hij de waarden eerst gelijk, met uitkomsten die niemand verwacht. Vergelijk daarom met drie istekens, want die kijkt ook naar het type. Achter veel onverklaarbare fouten zit precies dit.

Wat een script met je pagina doet

De browser bouwt van je HTML een boomstructuur in het geheugen. Elk element is daarin een knooppunt met kinderen eronder. Die structuur heet het document object model, meestal afgekort tot DOM.

JavaScript kan die boom lezen en veranderen. Een element opzoeken, de tekst erin vervangen, een klasse toevoegen zodat je opmaak iets anders doet, een blok verbergen of er een nieuw blok bij zetten. Alles wat op een pagina verandert zonder dat hij herlaadt, gebeurt zo. Daarnaast luistert een script naar gebeurtenissen: een klik, een toetsaanslag, het versturen van een formulier.

Belangrijk als je een site laat bouwen: wat een script aan de pagina verandert, staat niet in je HTML-bestand. Bekijk je de broncode, dan zie je wat de server heeft gestuurd. Kijk je in de inspecteur van je browser, dan zie je de pagina inclusief alles wat scripts eraan hebben gedaan. Bij problemen wil je weten in welke van die twee de fout zit. Hoe de HTML eronder in elkaar zit staat in een eigen artikel.

Wachten zonder de pagina te blokkeren

Veel van wat een script doet gaat over wachten: gegevens ophalen bij een server, een betaalverzoek versturen, een adres controleren. Dat duurt tientallen milliseconden tot enkele seconden, en in die tijd mag de pagina niet stilvallen.

Daarom werkt JavaScript asynchroon. Je zegt: haal dit op en voer dat uit zodra het binnen is. Ondertussen loopt de rest door. Dat is in drie stappen gegroeid: eerst met functies die werden teruggeroepen, daarna met promises, en sinds 2017 met async en await, waarmee wachtende code er weer uitziet als gewone code van boven naar beneden.

Blijft een formulier na het verzenden hangen, dan wacht je site op antwoord van een andere partij. Bij een trage koppeling zie je dat terug in het aantal mensen dat afhaakt.

Hoe een script op je pagina komt

Met een script-tag, die verwijst naar een bestand of die de code er direct in heeft staan. Waar die tag staat en welke woorden erbij staan, bepaalt wanneer hij wordt uitgevoerd.

• Zonder toevoeging. De browser stopt met het opbouwen van de pagina, haalt het bestand op en voert het uit. Alles daaronder wacht. De traagste variant en nog steeds de meest voorkomende.
• Met defer. Het bestand wordt op de achtergrond opgehaald en pas uitgevoerd als de pagina klaar is, in de volgorde waarin de tags staan. Voor de meeste scripts de juiste keuze.
• Met async. Het bestand wordt uitgevoerd zodra het binnen is. Bruikbaar voor losse meetscripts die niets met de rest te maken hebben.
• Als module. Zo'n script gedraagt zich standaard als defer en kan andere bestanden inladen.

In WordPress melden het thema en de plugins hun bestanden aan, waarna WordPress ze in de pagina zet. Sinds versie 6.3 uit 2023 kan een plugin daarbij aangeven dat zijn script uitgesteld mag worden. Dat gebeurt lang niet altijd, en daar komt een deel van de traagheid vandaan.

Wat te veel JavaScript met je snelheid doet

Dit is het punt dat op de meeste sites het meeste kost.

Een afbeelding van honderd kilobyte is honderd kilobyte downloaden. Honderd kilobyte JavaScript is downloaden, uitpakken, lezen, vertalen en uitvoeren, en dat gebeurt op het apparaat van de bezoeker. Op een moderne laptop merk je het nauwelijks. Op een telefoon van vier jaar oud met een matige verbinding merk je het meteen.

Google meet dat sinds 12 maart 2024 met interaction to next paint, afgekort tot INP: hoe lang duurt het voordat de pagina zichtbaar reageert nadat je iets aanraakt. INP verving toen de oudere maat die alleen naar de allereerste klik keek. Een pagina die zwaar leunt op scripts scoort hier slecht, ook als hij er snel uitziet.

Bij een gemiddelde WordPress-site komt het meeste JavaScript van plugins, waarvan er meestal een paar dingen laden op pagina's waar ze niets doen. Een formulierplugin die zijn code op elke pagina laadt is een klassieker.

Wat je eraan doet

Kijk in de netwerkweergave van je browsergereedschappen welke bestanden er laden en van wie ze komen. Verwijder plugins die je niet gebruikt, want uitgeschakeld is niet hetzelfde als weg. Laat wat overblijft alleen laden waar het nodig is; de betere optimalisatieplugins hebben daar een instelling voor per pagina.

Kijk daarna wat je kunt weghalen. De browser kan zelf wat je vroeger met een script moest bouwen: een uitklapbaar blok met details en summary, een venster over de pagina heen met dialog, afbeeldingen die pas laden als ze in beeld komen. Elk script dat je zo vervangt kan nooit meer kapot.

Waarom je site zonder JavaScript moet blijven werken

Niet omdat mensen het uitzetten. Dat doet bijna niemand.

Het gaat om alle momenten waarop het niet aankomt. Een bestand dat de server niet haalt. Een tikfout in één script waardoor alles eronder stopt. Een advertentieblokker of een bedrijfsnetwerk dat een domein weert. Een telefoon in de trein die halverwege zijn verbinding verliest. In al die gevallen krijgt je bezoeker de HTML wel en de rest niet.

De praktische regel: bouw eerst iets dat werkt met gewone HTML, en gebruik JavaScript om dat prettiger te maken. Een menu dat een echte lijst met links is, blijft bruikbaar als het uitklapscript faalt. Een formulier dat naar een echt adres verstuurt, komt aan zonder script. Een link is een a-tag met een href en geen div waar iemand een klik op geplakt heeft.

Diezelfde regel geldt voor het controleren van formuliervelden. Controleren in de browser is een gemak voor de bezoeker, geen beveiliging. Iemand die kwaad wil, stuurt de gegevens rechtstreeks naar je server en slaat je pagina over. Controleren moet dus ook op de server gebeuren.

Toegankelijkheid

Hier ligt de grootste onzichtbare schade van slordig gebruikte scripts.

Een knop van een div met een klikafhandelaar erop werkt met de muis en niet met een toetsenbord. Je klikafhandelaar luistert alleen naar de muis: de tabtoets slaat het element over, toetsaanslagen komen er niet in, en hulpsoftware ziet gewoon een blokje tekst. Iemand die geen muis kan gebruiken komt er niet doorheen.

Hetzelfde geldt voor onderdelen die je zelf nabouwt: uitklapmenu's, tabbladen, vensters die over de pagina komen. Die vragen om toetsenbordbediening en om een zichtbare focus. Bouw ze dus niet zelf als het met een standaardelement kan.

De snelste test kost een minuut. Leg je muis weg en loop met de tabtoets door je pagina. Kun je overal komen, zie je steeds waar je bent, en kun je elk uitklapmenu openen en sluiten?

JavaScript en vindbaarheid

Google voert JavaScript uit. Googlebot draait sinds mei 2019 op een steeds bijgewerkte versie van Chrome, dus inhoud die pas na het laden verschijnt wordt meestal wel gezien.

Meestal, en later. Het ophalen en het uitvoeren zijn twee aparte rondes. Eerst wordt je HTML opgehaald, daarna komt de pagina in een wachtrij om gerenderd te worden, en dat kan uren tot dagen duren. Inhoud die meteen in de HTML staat heeft dus een voorsprong.

Er zijn daarnaast dingen die een zoekmachine niet doet. Hij klikt niet, hij vult geen formulieren in, hij accepteert geen cookiemelding en hij wacht niet oneindig. Inhoud die pas na een klik bij de server wordt opgehaald, komt niet in de index. En links moeten echte links zijn: een navigatie die met scripts van pagina naar pagina springt zonder dat er een adres achter zit, levert pagina's op die niemand kan vinden. Bij sites die volledig in een raamwerk zijn gebouwd, zoals met Vue.js of React, los je dat op door de pagina's op de server op te bouwen.

Controleer het zelf met de URL-inspectie in Google Search Console. Vraag daar de live versie op en bekijk de gerenderde HTML. Staat je tekst er niet in, dan ziet Google hem ook niet. Hoe dat proces verloopt staat in het artikel over indexering door zoekmachines.

Beveiliging

Er zijn drie risico's en ze zitten alle drie op een andere plek.

Cross-site scripting

Iemand krijgt zijn eigen code op jouw pagina, bijvoorbeeld via een reactieveld of een zoekvak dat zonder controle wordt getoond. Die code draait daarna bij al je bezoekers en kan meelezen of sessies overnemen. De oplossing is alles wat een gebruiker invoert te ontdoen van betekenis voordat je het toont, en dat op de server te doen.

Cross-site request forgery

Een bezoeker is ingelogd bij jou en opent tegelijk een andere site, die op de achtergrond een verzoek naar jouw site stuurt. Voor jouw server ziet dat eruit als een gewone actie van een ingelogde gebruiker. Daarom werken beheeracties met een eenmalig token in het formulier. WordPress noemt die nonces, en plugins die ze weglaten zijn een terugkerende bron van lekken.

Code van anderen

Elk script dat je van een externe server laadt, draait met alle rechten op jouw pagina. Het kan bij je formuliervelden, bij je cookies en bij alles wat een bezoeker intikt. Dat is geen theoretisch risico: in juni 2024 werd een veelgebruikte hulpdienst voor oude browsers overgenomen door een andere partij, waarna het script kwaadaardige code ging serveren aan iedere site die het inlaadde. Honderdduizenden sites laadden dat bestand al jaren zonder er nog naar te kijken.

Wat je ertegen doet: laad alleen wat je nodig hebt, plaats het bij voorkeur op je eigen server, en gebruik voor bestanden van buiten een integriteitscontrole zodat de browser weigert als het bestand is gewijzigd. Verkoop je online en staat je betaalpagina op je eigen site, dan gelden sinds 31 maart 2025 strengere eisen uit de betaalkaartstandaard PCI DSS 4.0 over het bijhouden van elk script op die pagina. De rest staat in het artikel over een WordPress-website beveiligen.

Scripts van derden en de AVG

Zodra je een script van een ander domein inlaadt, gaat het IP-adres van je bezoeker naar die partij. Een IP-adres is een persoonsgegeven, dus dat is een verwerking waarvoor je een grondslag nodig hebt.

Daar komt artikel 11.7a van de Telecommunicatiewet bij. Voor het lezen of opslaan van gegevens op het apparaat van een bezoeker heb je toestemming nodig, tenzij het strikt noodzakelijk is voor de dienst die hij vraagt. Dat gaat verder dan cookies: opslag in de browser en herkenningstechnieken vallen er ook onder.

De uitwerking is streng: meet- en advertentiescripts mogen pas laden nadat iemand ja heeft gezegd. Een cookiemelding die een keuze vraagt terwijl de scripts al in de pagina staan, is een decorstuk. Dat is de meest voorkomende fout die ik tegenkom, en hij is in twee minuten aan te tonen.

Twee voorbeelden die verder gaan dan cookies. Lettertypen die je rechtstreeks bij Google inlaadt sturen het IP-adres van je bezoeker mee; een rechtbank in München oordeelde daarover in januari 2022, en sindsdien zetten veel bureaus die bestanden op de eigen server. Ingesloten video's zetten cookies zodra de speler laadt, tenzij je de variant zonder volgcookies gebruikt en pas na een klik inlaadt.

Voor Amerikaanse partijen speelt de doorgifte van gegevens. Sinds het Schrems II-arrest van 16 juli 2020 mocht dat niet zomaar meer, en sinds 10 juli 2023 is er weer een adequaatheidsbesluit voor bedrijven die zijn aangesloten bij het EU-US Data Privacy Framework. Controleer of je leverancier daarin staat. De Autoriteit Persoonsgegevens publiceerde een handleiding om Google Analytics privacyvriendelijker in te stellen, met de kanttekening dat het daarmee nog niet vanzelf is toegestaan.

Raamwerken, bibliotheken en jQuery

Een bibliotheek is een verzameling hulpstukken die je gebruikt waar je wilt. Een raamwerk bepaalt de opzet van je hele toepassing en jij vult de gaten in. Dat onderscheid staat uitgewerkt bij webontwikkelingsbibliotheken.

Voor een gewone bedrijfswebsite heb je geen raamwerk nodig. Ze zijn gebouwd voor toepassingen waarin veel schermen op elkaar reageren, zoals een dashboard of een boekingssysteem, en op een site van vijftien pagina's leveren ze vooral gewicht en onderhoud op.

De bibliotheek die je in WordPress hoe dan ook tegenkomt is jQuery, ontstaan in een tijd dat browsers onderling erg verschilden. Moderne browsers kunnen het meeste zelf, dus voor nieuw werk kies je hem niet meer, en tegelijk draait er nog een enorme hoeveelheid plugincode op. WordPress werkte jQuery in 2020 en 2021 in stappen bij en haalde het hulpbestand voor oude code weg. Sites met verouderde plugins kregen toen kapotte schuifbalken, menu's die niet opengingen en formulieren die niet verstuurden.

Fouten opsporen

Open de ontwikkelaarsgereedschappen in je browser, meestal met F12, en kijk in het tabblad Console. Fouten staan daar in het rood, met het bestand en de regel erbij.

Onthoud daarbij één ding dat veel verklaart: als een script een fout geeft, stopt dat script. Alles wat er in datzelfde bestand onder stond, gebeurt niet meer. Zo kan een fout in een klein hulpscript ervoor zorgen dat je hele menu blijft hangen.

Bij WordPress komt dat meestal door twee plugins die elkaar in de weg zitten. De standaardaanpak is saai en werkt: zet op een testomgeving alle plugins uit, kijk of het probleem weg is, en zet ze daarna één voor één weer aan.

Als je het wilt leren

Leer eerst HTML en CSS. JavaScript zonder die basis levert code op die wel werkt en nergens op slaat, omdat je dan met scripts oplost wat de browser zelf al kan.

Leer daarna de taal zelf voordat je aan een raamwerk begint. Wie met een raamwerk start, leert dat raamwerk en niet de taal, en loopt vast zodra hij iets moet doen wat er niet in zit.

Gebruik de ontwikkelaarsgereedschappen vanaf dag één. MDN Web Docs van Mozilla is het naslagwerk dat ik zelf gebruik: gratis en bijgehouden. Hoe deze taal samenwerkt met de rest van de voorkant staat in het artikel over front-end ontwikkeling.

Veelgestelde vragen over JavaScript

Wat is het verschil tussen Java en JavaScript?

Het zijn twee verschillende talen die niets met elkaar te maken hebben. Java komt uit 1995 van Sun Microsystems en wordt vooral gebruikt voor bedrijfssoftware en Android-apps. JavaScript kreeg zijn naam in datzelfde jaar omdat Java toen populair was.

Heb ik JavaScript nodig voor mijn WordPress-website?

Je gebruikt het al. De beheeromgeving van WordPress draait erop en vrijwel elke plugin voegt eigen scripts toe aan de voorkant. De vraag is niet of je het gebruikt maar hoeveel: bij de meeste sites die ik onder ogen krijg, laadt er code van plugins op pagina's waar die plugin niets doet.

Werkt mijn website nog als JavaScript niet laadt?

Dat kun je in een minuut testen. Zet JavaScript uit in de instellingen van je browser en open je eigen site. Kun je nog navigeren, lezen en contact opnemen? Belangrijker dan mensen die het uitzetten zijn de momenten waarop het misgaat: een bestand dat niet aankomt, een blokker, een fout in één script.

Leest Google inhoud die pas met JavaScript verschijnt?

Ja, meestal. Googlebot draait sinds 2019 op een moderne versie van Chrome en voert scripts uit.

Dat gebeurt in een tweede ronde die uren tot dagen later kan komen, en er zijn dingen die hij niet doet: klikken, formulieren invullen, cookiemeldingen wegklikken. Zet je belangrijkste tekst en je links daarom in de HTML zelf.

Maakt JavaScript mijn website traag?

Te veel JavaScript wel. De bestanden moeten worden gedownload, gelezen en uitgevoerd, en dat laatste gebeurt op het apparaat van de bezoeker. Op een oudere telefoon is dat het langzaamste onderdeel van je pagina.

Wat is XSS en loop ik daar risico op?

Cross-site scripting is een lek waarbij iemand zijn eigen code op jouw pagina krijgt, meestal via een veld dat bezoekers kunnen invullen en dat zonder controle wordt getoond. Op een WordPress-site loop je dat risico vooral via verouderde plugins, dus updates bijhouden dekt het grootste deel af.

Heb ik toestemming nodig voor scripts van derden?

Voor alles wat niet strikt nodig is om je site te laten werken, ja. Meetscripts, advertentiescripts, ingesloten video's met volgcookies en socialeknoppen vallen daaronder.

Die scripts mogen pas laden nadat de bezoeker toestemming heeft gegeven. Een cookiemelding die verschijnt terwijl de scripts al draaien, voldoet niet.

Mag ik Google Fonts gebruiken op mijn website?

Wel als je de lettertypen op je eigen server zet. Laad je ze rechtstreeks bij Google in, dan stuur je het IP-adres van je bezoeker naar een andere partij zonder dat daar toestemming voor is gevraagd. Zelf hosten is bovendien sneller, want je pagina hoeft geen verbinding met een extra domein te openen.

Wat is het verschil tussen JavaScript en een raamwerk als React?

JavaScript is de taal. React, Vue en Angular zijn er in geschreven en nemen je werk uit handen bij het bijwerken van het scherm als er gegevens veranderen. Je kunt alles wat een raamwerk doet ook zonder schrijven; het kost meer regels. Voor een website met pagina's die vooral gelezen worden, is een raamwerk overdreven.

Waarom werkt mijn menu niet meer na een update?

Bijna altijd een scriptfout. Kijk in de console van je browser: staat daar een rode melding met een bestandsnaam, dan weet je meteen welke plugin of welk thema het betreft.

Zet daarna op een testomgeving alle plugins uit en één voor één weer aan. In negen van de tien gevallen is het een plugin die al jaren niet is bijgewerkt.

Hoe lang duurt het om JavaScript te leren?

De basis leer je in een paar weken: variabelen, functies, voorwaarden, lijsten en het aanpassen van de pagina. Daarmee kun je een formulier controleren of een blok in en uit klappen. Wat langer duurt is asynchroon werken en het opsporen van fouten in code van anderen. Reken op maanden voordat je een bestaande WordPress-site met vertrouwen aanpast.