Simpel
Bij het inchecken van een project, of tijdens een meeting over de progressie van een opdracht realiseer ik me soms hoe erg ons vak (is) veranderd.
Laravel, Astro, Vue.js, websockets, developer experience en de adoptie van frameworks binnen TwoPine. Ik begrijp in grote lijnen waar het in het team over gaat. Ergens halverwege ben ik ze vaak kwijt.
Dat ligt niet aan ons team. Het ligt ook niet per se aan de frameworks. We maken tegenwoordig applicaties met veel data, gebruikersrollen, API's, realtime communicatie en complete ecosystemen eromheen. Daar heb je nu eenmaal meer voor nodig dan een HTML-bestand en een beetje CSS.
Toch moet ik op zulke momenten vaak denken aan hoe simpel het vroeger was.
Of in ieder geval hoe simpel het in mijn herinnering was.
Een mapje met bestanden
Toen we in 2010 TwoPine begonnen, voelde een website veel directer.
Er was een mapje. Daar stonden bestanden in. Je opende een PHP-, HTML- of CSS-bestand, paste iets aan en zette het online.
Natuurlijk was dat niet altijd professioneel. We testten minder/niet, documenteerden te weinig en deden soms rechtstreeks dingen op productie waar we nu licht nerveus van zouden worden.
Maar als een klant vroeg of een titel iets groter kon, was dat ook gewoon wat je deed.
Je hoefde niet eerst een lokale omgeving te starten, dependencies te installeren, een build te draaien en uit te zoeken waarom een package uit 2025 niet meer overweg kan met de huidige versie van Node. Een aanpassing was een aanpassing.
Nu kan een paar regels CSS wijzigen zomaar beginnen met een soort van digitale archeologie.
En nu
Het huidige technische verhaal van TwoPine klopt (meestal). Door de keuzes van de afgelopen jaren staat code vaker waar we het verwachten. Projecten zijn beter schaalbaar en onderdelen kunnen worden hergebruikt.
Dat is belangrijk.
Als alleen collega begrijpt hoe een project werkt, hebben we als team geen slim systeem gebouwd. Meer een afhankelijkheid.
Frameworks helpen ons om richting te geven. Ze zorgen ervoor dat niet iedere collega opnieuw hoeft te bedenken waar iets hoort en waar een probleem moet worden opgelost.
De oplossing wordt voorspelbaarder.
En daarmee vaak ook eenvoudiger.
Maar niet altijd.
Simpel aan de buitenkant
Moderne tooling is heel goed geworden in het verbergen van complexiteit. Met één commando staat er een project. Met een plugin voeg je authenticatie toe. Een externe dienst regelt e-mail, afbeeldingen, hosting of monitoring. Alles heeft documentatie, een dashboard en soms zelfs een “Get started” knop.
Als alles werkt, is het fantastisch.
Als iets breekt, ontdek je pas hoeveel er achter die ene knop zat.
Iedere dependency is code die we zelf niet hebben geschreven, maar waar we wel verantwoordelijk voor worden. Iedere externe dienst bespaart vandaag tijd, maar maakt ons ook afhankelijk van de prijzen, voorwaarden, tokens en keuzes van iemand anders.
Dat betekent niet dat we alles weer zelf moeten gaan bouwen. Dat zou pas echt onhandig zijn. Maar, zeker in de aankomende jaren, moeten we ons blijven afvragen wat eenvoud eigenlijk betekent.
Vibecoding
Met Claude Code en andere agents kan ik inmiddels zelf weer veel sneller van een idee naar iets werkends. Ik kan overleggen met een klant, een richting bedenken en kort daarna al zien wat we er technisch van kunnen maken.
Dat voelt ergens weer een beetje zoals vroegah.
Je bedenkt iets. Je maakt iets. Je kijkt of het werkt.
Alleen gebeurt er onder de motorkap nu veel meer dan toen. Een agent kan in een paar minuten twintig bestanden, zeven packages en drie extra abstractielagen toevoegen. De code ziet er overtuigend uit. De tests zijn groen. Het werkt. Maar hoe dan?
AI haalt complexiteit niet weg. We kunnen vooral sneller produceren en complexiteit beter voor ons verbergen. Juist daarom zijn duidelijke frameworks, conventies en documentatie zo belangrijk. Ze geven houvast en zorgen dat een agent niet iedere keer zijn eigen wiel verzint.
Tegelijk blijft iemand nodig die kan beoordelen of een oplossing logisch, robuust en onderhoudbaar is. Kunnen anderen ermee door? Is deployment en monitoring geregeld? Wordt dit geen onderhoudshel? Hadden we dit onderdeel niet veel eenvoudiger kunnen oplossen?
AI maakt kennis van techniek belangrijk.
Het maakt het alleen makkelijker om zonder die kennis heel ver te komen.
Misschien romantiseer ik het
Waarschijnlijk romantiseer ik het web van vroeger.
De simpele website uit mijn herinnering had geen realtime data, persoonlijke omgeving, meertalige content, geautomatiseerde tests of koppelingen met vijf andere systemen. We bouwden niet per se betere software. We bouwden vooral kleinere dingen.
En zodra meerdere mensen aan een project werken, wordt voorspelbaarheid belangrijker dan persoonlijke vrijheid. Dan is het fijn dat een collega weet waar code hoort. Dat een nieuwe developer niet eerst de logica van de oorspronkelijke maker hoeft te ontcijferen. Dat we kunnen testen, monitoren en veilig uitrollen.
De complexiteit heeft dus ook veel gebracht.
Maar soms lossen we een probleem dat al was opgelost opnieuw op, alleen dan met meer lagen ertussen.
Omdat het kan. Omdat het de standaard is. Of omdat een tool belooft dat het later allemaal makkelijker wordt.
Daar probeer ik kritischer op te blijven.
Niet iedere website hoeft een platform te worden. Niet iedere interactie heeft een framework nodig. Niet ieder probleem vraagt om een nieuwe service, package of agent.
Eenvoud betekent voor mij niet dat we terug moeten naar FTP en rechtstreeks wijzigingen doen op productie.
Het betekent dat we alleen complexiteit toevoegen als die iets oplost.
Dat een collega begrijpt wat we hebben gemaakt. Dat een project kan groeien zonder opnieuw te moeten beginnen. En dat iemand over vijf of tien jaar nog steeds een kleine wijziging kan doen zonder eerst een halve dag de gereedschapskist te repareren.
Bruce heeft gelijk dat een framework succesvol is geadopteerd als het prettig werkt, herkenbaar is en anderen ermee verder kunnen.
En toch denk ik soms met lichte nostalgie terug aan dat mapje met bestanden.
Openen. Aanpassen. Opslaan.
Klaar.
