diff --git a/javascript-skill.md b/javascript-skill.md
index 3c8c385..4815359 100644
--- a/javascript-skill.md
+++ b/javascript-skill.md
@@ -11,9 +11,10 @@ Gebruik deze stijl wanneer je Javascript-code voor Hans schrijft of aanpast.
 
 Schrijf code zoveel mogelijk in lijn met hoe Hans racket code schrijft. Zie daarvoor de racket skill.
 
-Gebruik bij javascript als je een closure definitie maakt, bij voorkeur classes, m.a.w. ga voor OO en class definities in plaats van property gestuurde closures.
+Gebruik bij javascript als je een closure definitie maakt een class.  
+Met andere woorden: ga voor OO en class definities in plaats van property gestuurde closures.
 
-Liever 
+Dus wel: 
 
 ```javascript
 class Rectangle {
@@ -38,7 +39,7 @@ class Rectangle {
 }
 ```
 
-In plaats van:
+En niet:
 
 ```javascript
 const Rectangle = (() => {
@@ -72,6 +73,8 @@ const Rectangle = (() => {
 
 Houd bronbestanden overzichtelijk. 
 Geen grote javascript bouwwerken. 
+
+Werk met modules en import/export. 
 Ga voor module gewijze code. 
 Zorg dat modules zoveel mogelijk een eenheid zijn. 
 
@@ -81,5 +84,61 @@ dan wordt het onoverzichtelijk.
 Voorkom eindeloze nestingen. 
 Probeer dingen functioneel op te zetten, zoals dat in racket zou werken. 
 
+### Klassen en objecten
 
+- Aanvullend bij de bovenstaande class regel. Gebruik een class wanneer een 
+  object een eigen identiteit, levensduur, toestand en bijbehorend gedrag heeft.
+- Zorg dat een constructor een direct bruikbaar object oplevert.
+- Geef concrete afhankelijkheden als betekenisvolle constructorargumenten door.
+  Introduceer geen algemene configuratie- of dependency-container zonder
+  concrete noodzaak.
+- Geef de voorkeur aan samenstelling. Gebruik overerving alleen wanneer
+  daadwerkelijk sprake is van een stabiele is-een-relatie of een gedeeld
+  gedragscontract.
+- Een domeinobject beheert zijn eigen toestand, validatie, wijzigingsmeldingen
+  en serialisatie. Andere modules horen niet rechtstreeks in zijn interne
+  datastructuur te werken.
+
+### Modules en API's
+
+- Gebruik expliciete imports en exports. Exporteer alleen de publieke
+  onderdelen van een module.
+- Modulevariabelen zijn toegestaan voor werkelijke modulebrede toestand,
+  zoals een singleton, cache of gedeelde wachtrij.
+- Behandel interne velden en helpers als implementatiedetails, ook wanneer
+  JavaScript die privacy niet technisch afdwingt.
+- Behoud externe veldnamen bij een API- of serialisatiegrens. Normaliseer
+  gegevens expliciet bij het binnenkomen en uitgaan van de applicatie.
+
+### Domein en gebruikersinterface
+
+- Houd domeinlogica en DOM/GUI-logica in afzonderlijke modules.
+- Laat GUI-objecten de publieke methoden van domeinobjecten gebruiken.
+- Een domeinobject hoort geen kennis te hebben van concrete DOM-elementen,
+  dialogen of widgets.
+
+### Asynchrone bewerkingen
+
+- Centraliseer bewerkingen waarvan volgorde belangrijk is, zoals opeenvolgende
+  opslagopdrachten, in een herkenbare wachtrij of coördinator.
+- Gebruik binnen één workflow één duidelijke asynchrone stijl.
+- Gebruik arrowfuncties wanneer lexicale `this` gewenst is. Gebruik een gewone
+  functie wanneer de aanroepende API bewust een eigen `this`-waarde levert.
+
+### Omvang en samenhang
+
+- Een groot aantal regels is een signaal, geen harde grens.
+- Splits een bestand wanneer het meerdere zelfstandig benoembare en stabiele
+  verantwoordelijkheden bevat, niet uitsluitend omdat een regelaantal is
+  overschreden.
+
+## Documentatie
+
+- Documenteer het doel en de functionele samenhang van modules, classes en
+  niet-triviale publieke methoden.
+- Beschrijf parameters, resultaat, neveneffecten en relevante interne
+  samenwerking.
+- Schrijf geen commentaar dat slechts iedere programmaregel in woorden herhaalt.
+- Triviale getters, setters en lokale callbacks hoeven niet afzonderlijk
+  gedocumenteerd te worden wanneer hun werking direct duidelijk is.