Frontmania 2026 – Een tester in het hol van de ontwikkelaar
Als tester is het soms goed om je horizon te verbreden en ook aan andere skills te werken naast je testskills. Ik (Joeri) ben nu al een aantal jaar naar verschillende testconferenties geweest, dus het leek me interessant om eens een developersconferentie bij te wonen. Ik had goede verhalen gehoord over Frontmania, dus besloot ik op 7 oktober eens te gaan kijken.
Omdat het oktober was en Halloween er weer aan zat te komen, had Frontmania dit jaar een Halloweenthema. Dat was een leuke verrassing, want ik had nog nooit meegemaakt dat een conferentie een thema had. De introductie begon dan ook heel toepasselijk: de presentatoren kwamen dansend als zombies het podium op, begeleid door Thriller van Michael Jackson. Erg leuk gedaan!
Keynote 1 - Koen van Gilst - Growing a better world. Together with AI?
Helaas waren er technische problemen met de presentatie, dus het duurde even voordat de eerste keynote kon beginnen. Je ziet maar dat een zaal vol techneuten niet betekent dat de techniek altijd meewerkt.
Koen vertelde over hoe AI de ervaring van programmeren verandert. Wat verliezen we als AI het programmeren steeds meer overneemt? Hij liet eerst een paar leuke games zien die hij had gemaakt voordat AI opkwam. Daarna kwam vibe coding. In het begin was dat nog niet zo goed, maar het werd steeds beter en AI deed bijna al het werk. Je zou een softwareproces zelfs helemaal kunnen automatiseren met AI, maar geen enkele developer wordt daar enthousiast van. Tijdens het programmeren bouw je context op en als AI het overneemt, verlies je die. De beste ideeën ontstaan juist tijdens het proces en je kunt nu eenmaal niet alles van tevoren bedenken.
AI moet daarom geen vervanger zijn, maar meer een exoskelet. Hoe gaan we van AI houden in plaats van er bang voor te zijn? Zie het als iets wat je sterker maakt. Kijk ook uit voor burn-out, want programmeren met AI kan vermoeiend zijn. Neem de verantwoordelijkheid voor het systeem dat je bouwt en, het belangrijkste van allemaal: geef je creativiteit niet uit handen.
Keynote 2 - Manfred Steyer - Agentic AI
Eindigt de evolutie van software development echt in de chatbox van een LLM? Manfred liet dynamische dashboards zien die de gebruiker zelf kan genereren. De applicatie laadt zelf de data die nodig is en bouwt aan de hand van de vraag van de gebruiker het dashboard op. Denk bijvoorbeeld aan een reisplanner die automatisch hotels en vluchten ophaalt.
AG-UI zorgt voor een makkelijke koppeling tussen de frontend en de backend, ongeacht welke AI-tool de backend gebruikt. Dat zou voor de frontend namelijk niet uit moeten maken: de backend geeft gewoon terug welke data de AI moet laten zien. A2UI geeft vervolgens structuur aan welke elementenboom getoond moet worden en met welke teksten.
Soms wil je ook data van externe apps laten zien. Daar zijn MCP apps voor. Die geven clientcode terug die je in een iframe kunt draaien. Je kunt er ook context aan meegeven zoals styling, om te voorkomen dat de iframe helemaal niet binnen de styling van je pagina past.
Een interessante ontwikkeling dus. Ik ben benieuwd waar dit de komende jaren naar toe gaat. En als tester ben ik stiekem ook wel benieuwd hoe je dit zou testen. Je weet op deze manier namelijk nooit hoe de UI er precies uit gaat doen en wat de AI terug gaat geven!
Talk 1 - Dani Coll - How not to get hacked
Waarom zouden we als frontend developer over security nadenken als we een securityteam hebben? Omdat securityrisico's overal kunnen voorkomen, en het dus belangrijk is dat iedereen de kennis heeft.
Dani liet een voorbeeld zien van een vulnerability in React, waarmee je een request kon sturen met wat je maar wilde. Je kon zelfs Claude aanroepen om dingen te doen in het systeem. Cross-site scripting wordt tegenwoordig gelukkig moeilijker gemaakt, want moderne frameworks hebben hier een hoop beveiligingen voor.
Een ander risico is privilege escalation, waarbij je gegevens van andere users kunt ophalen. Gebruik daarom UUID's die onmogelijk te raden zijn en doe ook checks op de backend. Zorg verder voor rate limits, geef niet te veel data terug aan de frontend en geef users niet meer rechten dan nodig.
Supply chain attacks komen ook veel voor, bijvoorbeeld via een package in je dependencies waar een vulnerability in zit. Het is belangrijk om dependencies vaak te updaten, maar haal alleen versies binnen die minstens 24 of 48 uur live staan. Een private package repo waarin je aangeeft welke packages binnengehaald mogen worden is ook verstandig. Let dus goed op welke dependencies je binnenhaalt. Monitoring is daarnaast erg belangrijk: als er iets misgaat, moet je ook weten wat er is gebeurd.
Ook het gebruik van AI brengt risico's met zich mee. Je wilt niet dat een gebruiker er van alles mee kan doen. Zorg dus voor safeguards, bijvoorbeeld dat de AI niet buiten de context mag antwoorden en dat er een limiet op zit. Laat de AI ook niet meer doen dan nodig is, en vraag bij belangrijke acties altijd om een approval.
Tot slot is CORS erg belangrijk om goed te configureren, anders kun je vanuit andere tabs data ophalen. Zorg er voor dat client en server op dezelfde host staan. Security is dus een gedeelde verantwoordelijkheid. Frameworks geven wat veiligheid, maar zorg dat je op alle lagen security toevoegt.
Talk 2 - Bart Waardenburg - Your tools check files, but who checks the code base?
Agents kunnen tegenwoordig heel snel code genereren, maar dat binnen een bestaande codebase doen is lastig. Een agent kan namelijk veel dingen niet zien, zoals of code dubbel is of dat de design tokens wel gebruikt worden.
Hoe lossen we dat op? Een linter kan helpen, maar die checkt maar één file per keer. Agents zien ook maar één of een paar files tegelijk, dus missen ze de context.
De tool die Bart presenteerde (Fallow) maakt een map van de dependencies binnen een codebase, zodat je kunt zien welke files het meest geïmporteerd worden. Dit is visueel gemaakt, maar agents kunnen er ook gebruik van maken. De tool ziet bijvoorbeeld ongebruikte of dode code, vindt duplicate (of vergelijkbare) code en detecteert import cycles, oftewel files die elkaar importeren.
Je kunt de tool over de hele codebase draaien of alleen over nieuwe wijzigingen, bijvoorbeeld in de pipeline of een pull request. Hij kan zelfs in productie draaien om te zien welke delen van je applicatie daadwerkelijk gebruikt worden. De agent kan tijdens het schrijven ook de Fallow MCP-server aanroepen om zijn eigen code te laten checken.
Een interessante tool, maar van tevoren was niet duidelijk dat het om een betaalde tool ging. Prima om je tool te verkopen, maar vermeld het dan wel duidelijk vooraf zou ik zeggen!
Panel discussion - AI agents are here: now what happens to developers?
In dit panel bespraken verschillende mensen AI in development en de toekomst ervan. Een van de vragen was hoeveel code we over drie jaar nog zullen schrijven. De ontwikkelingen gaan zo snel dat het moeilijk te voorspellen is, zeker over drie jaar. Zelfs het afgelopen jaar ging al heel erg snel. De consensus was wel dat we veel minder, of misschien zelfs helemaal geen code meer gaan schrijven, en meer bezig zullen zijn met andere zaken in het ontwikkelproces, zoals design en user requirements. Een brede skillset is dus heel belangrijk.
Ook de toekomst van junior developers kwam aan bod. Uit het publiek kwam een interessante opmerking: juniors zijn waarschijnlijk eerder met AI-tools aan de slag gegaan en hebben dus juist de kennis om ze goed te gebruiken. Hoe bereiden we ons dan het best voor op de toekomst? Leer concepten in plaats van een specifieke programmeertaal, want concepten blijven bestaan. Werk daarnaast meer samen met andere disciplines en leer van ze.
Talk 3 - Ramona Domen - So your components are accessible? Doesn't mean your application is
Tegenwoordig worden drie soorten components gebruikt: framework components (de standaardcomponenten in bijvoorbeeld React), library components (packages zoals Material UI) en custom components (zelfbouw). Alleen de components gebruiken is niet genoeg. Ze kunnen nog zo goed in elkaar zitten, maar een pagina bestaat uit meer dan alleen components.
Er kan een aantal dingen misgaan. Eén ervan is focus management en page flow: de tabvolgorde kan nog steeds fout zijn en daar moet je dus aan denken. Ook de HTML-structuur is belangrijk, vooral voor schermlezers. Denk aan zaken als headerniveaus en landmarks. Daarnaast moet je letten op forms en error handling. Forms kunnen op allerlei manieren geïmplementeerd worden, maar vergeet niet te checken of de error handling goed werkt. De paginastructuur is dus net zo belangrijk als de components.
Frameworks kunnen helpen, want veel ervan hebben hun eigen accessibility-documentatie. Maar die heeft ook beperkingen, omdat er niet altijd nagedacht wordt over een overkoepelende accessibilitystrategie.
De enige echte oplossing is een goede way of working. 67% van de accessibility defects begint in het design, en het is veel makkelijker om defects vroeg in het proces op te lossen dan in productie. Zorg daarom voor een goed designsysteem waarin niet alleen de components staan, maar waarin ook uitgelegd wordt hoe je ze moet gebruiken en wat de gedachte achter het systeem is. Testen is uiteraard ook erg belangrijk. Dat kan geautomatiseerd (met of zonder AI), handmatig en via gebruikersacceptatietesten.
De belangrijkste take-aways: ontwerp voor toegankelijkheid, draag bij aan open-source en support de makers en bedrijven die goede dingen doen voor toegankelijkheid.
Talk 4 - Kilian Valkhof - Programming principles for front-end developers
Veel developers hebben geen computer science-achtergrond en kennen daardoor de programming principles niet die je daar leert. Als tester met een achtergrond in geschiedenis kon ik me daar natuurlijk goed in vinden. Neem bijvoorbeeld de rule of least power: als je iets met een simpelere taal kunt doen, dan moet je dat doen (HTML boven JavaScript). Of de wet van Gall, die zegt dat complexe systemen evolueren vanuit een simpel systeem.
Dit zijn leuke weetjes, maar ze maken je niet per se een betere ontwikkelaar. Nuttiger zijn principes waar je iets aan hebt tijdens het programmeren. DRY (Don't Repeat Yourself) en YAGNI (You aren't going to need it) zijn handig, maar in de praktijk soms best vervelend. Praktischer is de rule of three: ga pas refactoren als je dezelfde code drie keer of vaker gebruikt. Gebruik je iets maar twee keer, dan kun je prima de code van de vorige keer hergebruiken. Zo voorkom je dat je applicatie onnodig complex wordt, en bij de derde keer weet je beter hoe de generieke oplossing moet werken.
Een ander principe is jezelf afvragen: "is it right?" en "is it fast enough?". Dat kun je tijdens het programmeren toepassen, zodat je alleen de aanpassingen prioriteert die echt nodig zijn.
Een betere benadering van de wet van Gall is om met een slechte versie van je functie of applicatie te beginnen. Dan heb je een begin waarop je kunt itereren en verbeteren, en dat maakt je ook efficiënter.
Idempotency is ook belangrijk: een functie moet altijd hetzelfde resultaat geven, ook als je hem meerdere keren aanroept. Daarnaast is er het single responsibility principle: zorg dat elke functie of class maar één verantwoordelijkheid heeft.
Leuke praktische tips van Kilian dus en goed om te horen dat ik een aantal daarvan al eerder had gehoord. Ik denk dat deze zeker van pas zullen komen in mijn toekomstige programmeerwerk.
Ervaring
Het was een mooie ervaring om als tester Frontmania 2026 bij te wonen. Van tevoren was ik bang dat de praatjes te technisch zouden zijn, maar dat viel reuze mee. Vanuit mijn werk heb ik altijd al interesse gehad in front-end development en momenteel volg ik een full-stack development cursus. Daardoor kon ik als tester goed meepraten. Ik heb deze dag een hoop nieuwe dingen geleerd en ook gezien waar de front-endwereld mee bezig is en wat de toekomst gaat brengen. Kortom: voor herhaling vatbaar!
Newspark presenteert op Testnet Najaarsevent, 28 oktober.
5 november DeepDive: hoe kun je met AI je leven makkelijker maken met een Chrome extensie, schrijf je snel in!
