Wat JS doet: gedrag & interactie

Waarom websites “leven” door JavaScript

Je krijgt in een training-opdracht een simpele pagina: een formulier, een knop “Verstuur”, en een melding “Bedankt!”. In HTML en CSS ziet alles er netjes uit, maar zodra iemand op de knop klikt gebeurt er… niets. De gebruiker verwacht feedback, een foutmelding bij een leeg veld, of dat er iets openklapt. Zonder gedrag voelt de site als een poster: mooi, maar stil.

In veel opdrachten in training draait het precies hierom: interactie toevoegen zonder direct een hele applicatie te bouwen. JavaScript (JS) is de laag die je gebruikt om een pagina te laten reageren op acties van gebruikers en op veranderingen in de pagina zelf. Denk aan klikken, typen, scrollen, of een timer die iets automatisch laat veranderen.

In deze les leer je wat JavaScript “doet” in de browser: gedrag sturen (wat gebeurt er) en interactie mogelijk maken (hoe reageert de pagina op de gebruiker). Je hoeft nog niet alles te kunnen schrijven; het belangrijkste is dat je begrijpt waar JS in het geheel past en welke soort problemen je ermee oplost.

De drie lagen: structuur, uitstraling en gedrag

Een website in de browser bestaat grofweg uit drie lagen die samenwerken. HTML is de structuur (koppen, knoppen, formulieren), CSS is de presentatie (kleur, layout, animaties), en JavaScript is het gedrag (reageren, logica uitvoeren, content aanpassen). Het helpt om dit als een taakverdeling te zien: je houdt je markup leesbaar, je styling overzichtelijk, en je gedrag helder.

Belangrijke begrippen:

• DOM (Document Object Model): de browser zet je HTML om in een boomstructuur van elementen (nodes) die JS kan lezen en aanpassen.

• Event (gebeurtenis): een signaal dat iets gebeurt, zoals click, input, submit, keydown, load.

• Event handler / listener: code die draait wanneer een event plaatsvindt.

• State (toestand): informatie die bijhoudt “hoe het nu is” (bijv. menu open/dicht, foutmelding zichtbaar/verborgen).

• Progressive enhancement: de pagina blijft bruikbaar zonder JS, en wordt rijker met JS.

Een handige analogie: HTML is het skelet, CSS is de kleding, JS zijn de spieren en zenuwen. De spieren bewegen niet “zomaar”; ze reageren op prikkels (events) en voeren beslissingen uit (logica). JS werkt dus vooral als een reactiemechanisme: er gebeurt iets → JS beslist → de DOM wordt aangepast → de gebruiker ziet het effect.

Hoe JavaScript gedrag en interactie aanstuurt

1) JavaScript praat met de DOM (en verandert wat je ziet)

Wanneer JS in de browser draait, werkt het meestal niet “op zichzelf”, maar tegen de DOM aan. In de praktijk betekent dit dat je elementen opzoekt, informatie uitleest, en daarna iets wijzigt: tekst, attributen, classes, of zelfs de structuur (nieuwe elementen toevoegen of verwijderen). Dat maakt JS zo krachtig voor interactie: je hoeft geen nieuwe pagina te laden om feedback te geven.

De meest voorkomende acties zijn:

• Lezen: wat staat er in een veld (value), welke tekst staat er in een element, heeft iets een class?

• Schrijven: tekst vervangen, disabled aan/uit zetten, een class toevoegen/verwijderen om CSS te laten “omschakelen”.

• Structuur aanpassen: error-bericht toevoegen, lijstitems renderen, een modal invoegen.

Waarom classes zo vaak terugkomen: het is een best practice om JS niet direct stijlen te laten instellen (zoals element.style.color = ...) behalve in uitzonderingen. In plaats daarvan laat je JS een class toggelen (bijv. .is-open, .has-error), en laat je CSS bepalen hoe dat eruitziet. Zo blijft de scheiding tussen gedrag en presentatie intact en kun je je ontwerp later aanpassen zonder je logica te herschrijven.

Veelgemaakte denkfout: “JS is voor animaties.” Animaties kúnnen met JS, maar meestal is JS er om beslissingen te nemen (wanneer open/dicht, valideren ja/nee, tonen/verbergen), en laat je CSS het visuele werk doen. Een andere valkuil is te veel DOM-bewerkingen achter elkaar doen zonder plan; dan wordt je code snel onleesbaar. Werk liever met een duidelijke intentie: “Wat is de toestand?” en “Welke class hoort daarbij?”

2) Events: van gebruikersactie naar code die draait

Interactie start bijna altijd met een event. De browser detecteert acties (klik, input, submit, scroll) en stuurt dat door als een event-object. Jij “luistert” daarop met een event listener. Dit model is essentieel: JS draait niet continu alles na elkaar; het reageert meestal asynchroon op gebeurtenissen.

Belangrijke nuance: events bubbelen vaak door de DOM. Dat betekent dat een klik op een knop ook “langs” de ouders gaat. Dat is handig (event delegation), maar kan ook verwarrend zijn als je niet weet waarom een handler meerdere keren lijkt te werken. Voor beginners is het prima om te onthouden: een event gebeurt ergens, en kan doorgegeven worden. Later kun je specifieker leren hoe je dat stuurt.

Een klassieke plek waar events misgaan is formulieren. Een submit event triggert standaard een paginareload (of navigatie). Als je een eigen flow wilt (bijv. inline validatie en een melding tonen), moet je die default actie vaak tegenhouden. Conceptueel is dit belangrijk: JS voegt gedrag toe, maar de browser heeft al gedrag ingebouwd. Jij kiest wanneer je dat standaardgedrag gebruikt en wanneer je het overschrijft.

Best practices rond events:

• Koppel gedrag aan betekenisvolle elementen (button voor acties, form voor submit), niet aan willekeurige containers.

• Houd handlers klein: pak input → beslis → update DOM.

• Vermijd “magische” koppelingen: als je element verandert, wil je niet dat alles breekt. Werk daarom met stabiele selectors en duidelijke classes/attributes.

Typische misvatting: “Als ik een knop heb, kan ik overal click-handlers op zetten.” Technisch kan dat, maar semantiek telt: als iets een knop is, maak het een <button>. Dat helpt toegankelijkheid, toetsenbordgebruik, en zorgt dat je events voorspelbaar blijven.

3) State en flow: dezelfde actie, ander resultaat

Zodra je meerdere interacties hebt, krijg je “toestand”: een menu is open of dicht, een stap is afgerond of niet, een foutmelding is zichtbaar of verborgen. Zonder state ga je vaak code schrijven als: “als er al een foutmelding is, verwijder hem; anders maak hem”. Dat kan werken, maar het wordt snel rommelig.

Een heldere manier van denken is:

1. Bepaal de state (bijv. isOpen = true/false, of “veld is valid”).
2. Update de UI op basis van die state (classes, tekst, disabled, aria-attributen).
3. Herhaal bij elk event.

Dit is ook waar veel beginners de DOM als “database” gaan gebruiken (“ik kijk of de tekst nu ‘Open’ is, dan weet ik of het open is”). Dat maakt bugs waarschijnlijk, omdat tekst of layout kan veranderen. Beter is: gebruik DOM als weergave en houd state als concept apart, ook al is dat in het begin nog simpel (bijv. 1 boolean).

Een andere veel voorkomende valkuil is het door elkaar halen van verantwoordelijkheden: een handler die tegelijk valideert, HTML bouwt, styling instelt, en ook nog analytics wil doen. In kleine opdrachten lijkt dat prima, maar het schaalt slecht. Denk in blokken: input verwerken, beslissen, UI bijwerken. Zelfs als alles in één bestand staat, kun je die scheiding in je hoofd (en straks in functies) aanhouden.

HTML/CSS/JS naast elkaar: wie doet wat?

Dimensie	HTML (structuur)	CSS (uitstraling)	JavaScript (gedrag)
Hoofddoel	Betekenis en opbouw van content	Visuele vormgeving en layout	Reageren, beslissen, aanpassen
Voorbeelden	Formulier, button, headings, links	Kleuren, grid/flex, transitions, responsief	Click afhandelen, validatie, toggles, dynamische content
Wat verandert het?	De DOM-structuur (statisch gedefinieerd)	Hoe DOM-elementen eruitzien	De DOM en de “flow” van interacties
Best practice	Semantische elementen, toegankelijk	Classes als “bron van waarheid” voor styles	Classes toggelen, kleine handlers, duidelijke state
Typische valkuil	Div-soup, onduidelijke structuur	Inline styles, te veel “!important”	Alles in één handler, DOM als state, standaardgedrag vergeten

[[flowchart-placeholder]]

Twee herkenbare voorbeelden uit training-opdrachten

Voorbeeld 1: Een uitklapbaar menu dat werkt op klik (zonder nieuwe pagina)

Stel: je bouwt een trainingspagina met een navigatie die op mobiel achter een “hamburger”-knop zit. Zonder JS kun je de navigatie al in de HTML zetten, zodat de links er zijn en de pagina bruikbaar blijft. Met CSS kun je het menu standaard verbergen op smalle schermen en klaarzetten met een class zoals .is-open om het te tonen. JS is dan de schakel die bepaalt wanneer die class aan/uit gaat.

De flow is concreet en herhaalbaar. Eerst zoek je in de DOM de knop en het menu-element. Daarna koppel je een click-event aan de knop. In de handler bepaal je de nieuwe state: stond het menu open, dan moet het dicht; stond het dicht, dan moet het open. Tot slot update je de UI: je toggelt de class op het menu en past eventueel de knoptekst aan (bijv. “Menu” ↔ “Sluiten”) zodat de gebruiker feedback krijgt.

Impact en voordelen: de gebruiker krijgt een snelle, “app-achtige” ervaring zonder paginareloads. De code kan ook netjes blijven omdat CSS het uiterlijk regelt. Beperking: als je volledig leunt op JS om links überhaupt zichtbaar te maken, wordt de pagina onbruikbaar wanneer JS faalt. Daarom is progressive enhancement belangrijk: de content bestaat al, JS maakt het prettiger en sneller.

In een organisatiecontext (bijv. een interne trainingsportal) is dit waardevol omdat navigatie vaak op meerdere pagina’s terugkomt. Een consistente toggle-oplossing maakt gedrag voorspelbaar voor gebruikers en onderhoudbaar voor teams: design kan classes aanpassen, developers houden dezelfde JS-logica.

Voorbeeld 2: Formuliergedrag — validatie en feedback vóór versturen

Een andere veelvoorkomende training-opdracht: een aanmeld- of contactformulier met een verplicht e-mailadres. HTML kan al basisvalidatie bieden (required, type="email"), en de browser kan standaard meldingen tonen. Maar vaak wil je eigen feedback: een foutmelding onder het veld, een rode rand (via class), en een “Verstuur” knop die pas actief wordt als het formulier valide is. Dat is precies waar JS gedrag toevoegt bovenop de structuur.

Stap voor stap denk je in events. Je luistert naar input op het e-mailveld om live te reageren terwijl iemand typt. Je checkt dan de toestand: is het veld leeg, lijkt het op een e-mail, voldoet het aan jouw regels? Op basis daarvan update je de UI: je zet een .has-error class op de container, vult een foutmelding, en zet de submit-knop op disabled = true/false. Je luistert ook naar submit om te bepalen of je de standaard submitactie laat doorgaan of tegenhoudt. Als je inline feedback geeft en nog niet echt naar een server post, wil je vaak eerst voorkomen dat de pagina herlaadt.

Voordelen: gebruikers maken minder fouten, begrijpen sneller wat er mis is, en voelen meer controle. Beperkingen: JS-validatie is geen beveiliging; het is gebruikersgemak. In echte systemen moet validatie ook server-side gebeuren, omdat JS te omzeilen is. Nog een valkuil is dubbele waarheid: HTML-validatie én JS-validatie die elkaar tegenspreken. Kies één duidelijke bron van regels, of zorg dat ze op zijn minst consistent zijn.

In workflow-termen past dit in “kwaliteit aan de voorkant”: minder foutieve inzendingen betekent minder correctiewerk achteraf. Zelfs in training-opdrachten is dat een realistische reden waarom teams investeren in goede interactie.

Wat je hieruit meeneemt

JavaScript in de browser gaat vooral over reactie en verandering: je luistert naar events, maakt een beslissing, en werkt de DOM bij zodat de gebruiker direct feedback ziet. De meest onderhoudbare aanpak is vaak: JS stuurt classes en states, en CSS bepaalt de look. Zo blijft je code beter leesbaar en groeien je projecten eenvoudiger mee.

Belangrijk om te onthouden:

• DOM is de “levende” versie van je HTML waar JS mee werkt.

• Events zijn de triggers voor gedrag (klik, input, submit).

• State-denken voorkomt rommelige “als-dit-dan-dat” DOM-trucs en maakt interactie voorspelbaar.

This sets you up perfectly for Variabelen, functies & events [25 minutes].