Het gereedschap voor webontwikkeling dat er echt toe doet
Lijsten met hulpmiddelen verouderen snel en helpen wie een website laat maken zelden. Wat blijft is de set *categorieën* die een capabel project gebruikt, en wat hun afwezigheid zegt over hoe het project zal verlopen.
Deze gids behandelt de categorieën die ertoe doen, wat elk voorkomt, en de vragen die onthullen of een ontwikkelaar zo werkt.
De niet-onderhandelbare categorieën#
Dit zijn geen voorkeuren. Een project zonder deze bouwt risico op dat op het slechtst denkbare moment opduikt — meestal wanneer er iets kapotgaat en niemand kan zeggen wat er veranderd is.
| Categorie | Wat het voorkomt | Vraag |
|---|---|---|
| Versiebeheer | Verloren werk, onverklaarde wijzigingen, geen weg terug | «In welke repository staat de code en kan ik toegang krijgen?» |
| Testomgeving | Testen op productie | «Waar beoordeel ik voordat het live gaat?» |
| Geautomatiseerde uitrol | Iemand die vrijdag om zes uur bestanden overzet | «Hoe komt een wijziging op productie?» |
| Back-ups | Totaal verlies | «Hoe vaak, waarheen, en wanneer heb je er voor het laatst een teruggezet?» |
| Foutmonitoring | Stille storingen die niemand weken opmerkt | «Hoe kom je erachter dat er iets kapot is?» |
| Beschikbaarheidsmonitoring | Het van een klant horen | «Wie krijgt een melding als de site eruit ligt?» |
| Bijwerken van afhankelijkheden | Bekende kwetsbaarheden die blijven staan | «Hoe worden beveiligingsupdates toegepast?» |
Het sterkste signaal is het antwoord op «hoe komt een wijziging op productie?». Gaat het over bestanden slepen in een FTP-programma, dan ontbreekt waarschijnlijk ook al het andere op deze lijst.
Build- en front-endgereedschap#
Hier beweegt de mode het snelst en doet ze er voor jou als opdrachtgever het minst toe. Wat telt is het resultaat, niet het gereedschap dat het opleverde.
- Een buildstap die bestanden verkleint, samenvoegt en optimaliseert — paginagewicht is een conversieprobleem, geen zuiverheidsprobleem.
- Een beeldstraat die automatisch moderne formaten en meerdere formaten oplevert. Handmatig geëxporteerde afbeeldingen blijven nooit actueel.
- Een CSS-aanpak met systeem — variabelen, tokens, hoe je het ook noemt — in plaats van een opeenstapeling van eenmalige regels.
- Alleen het JavaScript dat de pagina nodig heeft. Een framework is een legitieme keuze voor een applicatie en meestal ballast voor een brochuresite.
- Browserondersteuning schriftelijk vastgelegd. «Moderne browsers» is geen specificatie.
Test- en kwaliteitsgereedschap#
Volledige geautomatiseerde testsuites zijn op een marketingsite zelden te rechtvaardigen. Een beetje automatisering op de paden die geld opleveren vrijwel altijd wel.
- Geautomatiseerde controles alleen op de kritieke paden: afrekenen, aanmelden, het belangrijkste contactformulier.
- Een snelheidsbudget dat automatisch wordt gecontroleerd — een getal dat een build laat falen, geen hoop.
- Geautomatiseerd toegankelijkheidsonderzoek in de straat, wetend dat het ongeveer een derde van de problemen vindt.
- Controles over de browsers die je statistieken werkelijk tonen, niet over een lijst van alles.
- Een contentset op de testomgeving die echte tekstlengtes weerspiegelt, inclusief de lastige.
Een snelheidsbudget is de meest waardevolle automatisering voor een contentsite: zonder stijgt het paginagewicht elke maand stilletjes en is niemand verantwoordelijk.
Waar je toegang toe hoort te hebben#
Ongeacht welk gereedschap de ontwikkelaar verkiest, horen deze accounts vanaf dag één op jouw naam te staan. Bij de aftrap is dat veel makkelijker te regelen dan nadat een samenwerking is geëindigd.
- Domeinregistrar — op naam van jouw organisatie, met jouw factuurgegevens.
- Hostingaccount, met de ontwikkelaar toegevoegd als gebruiker in plaats van als eigenaar.
- Code-repository, met jouw organisatie als eigenaar.
- Statistiek- en Search Console-eigendommen.
- Elke dienst van derden waarvan de site afhangt: betaling, e-mail, CDN, foutmonitoring.
- Een schriftelijke lijst hiervan, bewaard waar je team hem kan vinden.
Veelgestelde vragen
Moet ik dit gereedschap begrijpen?
Nee, maar je zou moeten vragen of het bestaat en wie toegang heeft. De vragen in de tabel hierboven beantwoordt elke capabele ontwikkelaar in één zin per stuk, en aarzeling bij de vragen over uitrol en back-ups is een echt signaal in plaats van een kwestie van stijl.
Is een JavaScript-framework nodig?
Voor een webapplicatie meestal wel. Voor een marketing- of contentsite meestal niet — en het kost vaak snelheid zonder voordeel, omdat de browser een framework moet downloaden en uitvoeren voordat tekst verschijnt die net zo goed in de HTML had kunnen staan. De juiste vraag is welk probleem het op jouw site oplost, en «dat gebruiken wij nu eenmaal» is geen antwoord.
Wat is een snelheidsbudget?
Een afgesproken grens — bijvoorbeeld onder 200 KB JavaScript en Largest Contentful Paint onder 2,5 seconden op de hoofdsjablonen — die automatisch wordt gecontroleerd en de build laat falen bij overschrijding. Het werkt omdat het snelheid verandert van iets waar iedereen het belang van erkent in iets dat een uitrol tegenhoudt.
Hoe weet ik of de site wordt onderhouden?
Vraag om een maandelijkse notitie: wat is bijgewerkt, wat is gepatcht, wat was de beschikbaarheid, en welke fouten kwamen er voorbij. Levert een onderhoudsabonnement geen rapport op, dan is zorgvuldig onderhoud lastig te onderscheiden van geen onderhoud, en dat merk je meestal tijdens een incident.
webontwikkeling gereedschapwebontwikkeling stackversiebeheertestomgevingsnelheidsbudgetuitrolstraat
