Op 8 oktober 2025 bezocht ik de Frontmania in Utrecht: een dag vol inspiratie, kennisdeling en technische diepgang. Deze blogpost is geschreven voor een technisch publiek, maar iedereen is welkom om het te lezen. Frontmania 2025 stond opnieuw in het teken van alles wat het front-end landschap beweegt. Van innovatieve frameworks tot diepgaande inzichten in performance, debugging en schaalbaarheid — de conferentie bracht een diverse groep developers samen die hun passie voor moderne webtechnologie delen. De dag zat vol energie: sprekers van onder andere Google, Delivery Hero en RTL deelden hun kennis over de nieuwste tools, architecturen en best practices. Hoewel sommige talks bol stonden van de technische details en anderen juist meer op inspiratie mikten, was de rode draad duidelijk: de front-endwereld evolueert snel richting meer automatisering, slimme observability en robuuste user experiences. Frontmania 2025 liet zien dat front-end development niet langer alleen over interfaces gaat, maar over het bouwen van betrouwbare, schaalbare en slimme digitale ervaringen.

Why Reactive Functional Is My Paradigm of Choice – Bart Kuijper

De eerste talk van de dag zette meteen de toon. De spreker nam ons mee in zijn persoonlijke reis door de wereld van Reactive Functional Programming (RFP) — een paradigm dat volgens hem te vaak als academisch wordt weggezet, maar juist verrassend natuurlijk aanvoelt als je er eenmaal in duikt. Zijn missie was duidelijk: laten zien waarom RFP niet alleen een technische aanpak is, maar een manier van denken die dichter bij de natuur ligt dan we ons beseffen.

Hij begon met een intrigerende vraag: waarom is RFP zo populair in het onderwijs, maar wordt nog steeds niet breed omarmd in de praktijk? Vervolgens bouwde hij zijn verhaal op aan de hand van metaforen, die zowel filosofisch als praktisch vlaktes raakten. Een observable vergeleek hij met een waterstroom: een bron die continu nieuwe waarden uitzendt, waarop andere delen van het systeem kunnen reageren. Zoals rivieren samenvloeien, zo kunnen streams in RxJS met functies – als merge, expand en scan – samenkomen en nieuwe patronen vormen.

Wat me vooral bijbleef, was de manier waarop hij de concepten van push-based en pull-based systemen koppelde aan natuurlijke processen. In de natuur ontstaat informatie niet doordat we erom vragen — ze wordt uitgezonden, gedeeld, verspreid. Zoals een boom reageert op licht, past een ecosysteem zich aan de veranderingen in temperatuur. Het is allemaal een reactive proces.

Zijn voorbeelden waren even poëtisch als technisch. Van een amandelboom die blikseminslag overleeft terwijl zijn omgeving afbrandt, tot genetische veranderingen bij kuikens — telkens keerde hij terug naar hetzelfde idee: systemen die reageren, evolueren en zich aanpassen zijn sterker. En precies dat probeert een RFP te vangen in code.

Hij liet met de front-end libary genaamd RxJS zien hoe we deze natuurlijke dynamiek kunnen modelleren in software. Data als een keten van gebeurtenissen, waarin alles met elkaar verbonden is. Het voelde bijna alsof hij een brug sloeg tussen mechanische en natuurlijke engineering: niet langer rigide objecten (zoals in OOP), maar stromen die bewegen, veranderen en samen nieuwe vormen aannemen.

De talk eindigde met een krachtige boodschap: RFP is niet alleen efficiënter of eleganter — het voelt gewoon goed. Natuurlijk, vloeiend en in lijn met hoe de wereld zelf werkt. En misschien is dat wel de reden waarom het tijd is om ons reactive functional-spel écht op te pakken.

The Web Components Compass – Tom Herni

Web Components blijven een van de meest polariserende onderwerpen in front-end development. Sommige ontwikkelaars prijzen ze als de toekomst van framework-onafhankelijke UI’s, terwijl anderen ze zien als omslachtig en beperkt. Tijdens zijn talk “The Web Components Compass” nam Tom Herni van Rabobank ons mee in een nuchtere en praktische verkenning van deze technologie: wat web components precies zijn, wanneer ze werken en wanneer je ze beter kunt vermijden.

Hij begon met een herkenbare constatering: de webplatformen blijven evolueren. Nieuwe features – zoals lazy loading, de Intersection Observer API en het steeds breder wordende scala aan Web API’s – tonen hoe de browser zelf een steeds volwaardiger applicatieplatform wordt. In dat licht passen Web Components perfect — ze zijn immers gebaseerd op open standaarden en draaien rechtstreeks in de browser, zonder afhankelijkheid van frameworks als React of Angular.

Tom structureerde zijn talk rond drie pijlers: Custom Elements, Shadow DOM en HTML Templates.

Custom Elements

Met Custom Elements kun je je eigen HTML-tags definiëren compleet met eigen gedrag en lifecycle-methoden zoals connectedCallback() en disconnectedCallback(). In plaats van een <div> of <button> kun je dus iets als <my-button> maken, met interne logica en styling die je zelf beheert. Dat klinkt klein, maar het is precies wat nodig is voor het bouwen van een duurzaam design system. Rabobank gebruikt dit principe voor componenten zoals datepickers, knoppen en invoervelden — allemaal met unieke prefixen om naamconflicten te voorkomen.

Shadow DOM

Vervolgens dook hij in het Shadow DOM, het onderdeel dat zorgt voor echte encapsulatie van markup en styles. Het creëert een eigen DOM-subtree binnen een component, waardoor CSS en scripts niet onbedoeld naar buiten lekken (of van buitenaf worden beïnvloed). Die isolatie is krachtig, maar brengt ook uitdagingen met zich mee. Bepaalde CSS-properties — zoals font-families en variabelen — worden wél geërfd, maar selectors kunnen niets “zien” binnen het Shadow DOM. Daardoor moet je soms creatief omgaan met styling en communicatie tussen componenten.

Toegankelijkheid en forms zijn een ander pijnpunt. Inputs binnen een Shadow DOM gedragen zich niet automatisch als standaard form controls, waardoor integratie met formulieren of ARIA-attributen extra aandacht vraagt. Rabobank gebruikt hier form-associated custom elements voor een nog relatief nieuwe, maar veelbelovende oplossing.

HTML Templates

Het derde onderdeel waren HTML templates: <template>-elementen die vooraf gedefinieerde markup bevatten en met JavaScript kunnen worden gekloond. Samen met Shadow DOM vormt dit de basis voor het bouwen van herbruikbare UI’s zonder externe libraries.

Praktijk: Rabobank’s Design System

Tom deelde hoe Rabobank inmiddels meer dan 150 UI-componenten onderhoudt, gebouwd als Web Components. Omdat het bedrijf teams heeft die werken met Angular, React en zelfs Svelte, zijn Web Components daar een ideale verbindende laag. De interoperabiliteit tussen frameworks maakt het mogelijk om één gedeeld design system te onderhouden, terwijl elke afdeling zijn eigen frontend-stack kan kiezen. Dat betekent niet dat alles vlekkeloos verloopt. Auto-completion in editors, tag-herkenning in Angular en wrapper-componenten blijven bronnen van frictie. Toch wegen de voordelen van herbruikbaarheid en onafhankelijkheid zwaar genoeg.

Conclusie

Tom’s conclusie was realistisch: Web Components zijn niet voor elk project de heilige graal. Ze vragen om zorgvuldige afweging, vooral bij complexe styling of form-integratie. Maar voor organisaties met meerdere frameworks en een gedeelde design language — zoals Rabobank — kunnen ze een enorme meerwaarde bieden.
Of zoals Tom het samenvatte: “If interoperability matters more than convenience then Web Components are worth the effort.”

Pixels, Tokens and Prompts: The Evolution of Design Systems – Dražen Janković

Met zijn talk “Pixels, Tokens and Prompts” nam Dražen Janković ons mee op een reis door de geschiedenis van design systems, van de eerste papieren styleguides tot de opkomst van AI-gestuurde ontwerptalen. Het was niet alleen een technisch overzicht, maar ook een reflectie op hoe ontwerp, ontwikkeling en intelligentie steeds meer met elkaar versmelten.

Van Styleguides tot Living Systems

Janković begon bij de oorsprong: de eerste styleguide van IBM in de jaren ’60. Strikte visuele standaarden die zorgden voor consistentie in drukwerk en marketing, maar nog niets van doen hadden met digitale interfaces. In 1978 volgde Apple met zijn Human Interface Guidelines — de eerste poging om niet alleen de look, maar ook het gedrag van interfaces vast te leggen.

Vanaf daar ging het snel: de opkomst van HTML in 1991, CSS in 1994 en JavaScript-frameworks vanaf 2006 brachten steeds meer dynamiek. Yahoo’s Design Pattern Library (2006) en Twitter’s Bootstrap (2011) legden de basis voor moderne design systems. In 2014 zette Google’s Material Design daar een laag bovenop: een levend systeem dat gedrag, animatie en betekenis combineerde. Salesforce kwam in dezelfde tijd met het Lightning Design System.

Shelves, Guides, and Systems

Op een van zijn slides liet Janković een helder overzicht zien van deze evolutie — van Component Shelves naar Styleguides en uiteindelijk Design Systems. Elke stap voegt meer context, tooling en samenwerking toe:

Component Shelf: hergebruik van UI-elementen, vaak puur in code.
Styleguide: zorgt voor visuele consistentie, maar blijft statisch.
Design System: brengt tokens, componenten, documentatie en tooling samen — een continu evoluerend ecosysteem dat gedrag, toegankelijkheid en gebruik omvat.

Zijn metafoor was treffend: elk niveau voegt meer duidelijkheid, consistentie en schaalbaarheid toe — als een doos LEGO die zich blijft uitbreiden.

The Rise of Tokens

Daarna doken we dieper in design tokens. Dit zijn herbruikbare en benoemde variabelen die visuele waarden vastleggen, zoals: kleuren, typografie, spacing, animatie en de motion of elevation. Tokens maken ontwerp schaalbaar en consistent over platformen heen. Janković liet zien hoe design tools, zoals Figma deze tokens nu kunnen exporteren als JSON, waardoor ze direct bruikbaar zijn in code of zelfs als input voor AI-systemen. Waar ontwerpers vroeger handmatig waarden moesten bijhouden, vormen tokens nu een single source of truth die ontwerp en ontwikkeling verbindt.

Governance in a System World

Met groei komt ook structuur. Een goed design system heeft governance nodig: versiebeheer, documentatie, tooling en analytics. In een enterprise-achtige schaal vraagt dit om data-gedreven onderhoud — een levend ecosysteem dat zichzelf bijwerkt en leert van gebruik.

Prompts and AI: The New Interface Layer

Het laatste deel van zijn talk richtte zich op de toekomst: prompts als nieuwe interface-laag. Waar tokens de woorden vormen en componenten de grammatica, maken prompts volledige zinnen mogelijk. AI-modellen kunnen leren “design systems te spreken”, mits ze goed getraind worden. Janković noemde dit een bilingual conversation tussen mens en machine:

• Pixels zijn de visuele atomen.
• Tokens vormen de woordenschat.
• Components bepalen de syntaxis.
• Prompts worden de volzinnen waarmee we communiceren met AI-designers of copilots.

AI vervangt de mens niet, benadrukte hij, maar kan wél fungeren als een nieuwe collega — een junior die je traint met documentatie, voorbeelden en goed beschreven componenten. Quote: “Train your design system en je traint je AI-teamgenoot tegelijk.”

Van LEGO naar Leven

De talk eindigde met een blik op de toekomst: design systems die niet alleen reageren op tokens, maar ook leren van gebruik: een ecosysteem waarin designers, developers, AI-agents en tools in één taal samenwerken.

It’s the End of the Front as We Know It (I Feel Fine) – Nir Kaufman

Nir Kaufman begon zijn talk met een prikkelende vraag: wat betekent de titel “front-end developer” anno 2025 nog? Volgens hem staat die term op het punt zijn betekenis te verliezen. Niet omdat gebruikersinterfaces verdwijnen, maar omdat de grens tussen client, server en AI steeds meer vervaagt. De rol van de front-ender verschuift van het schrijven van UI-code naar het begrijpen van architectuur, gedrag en samenwerking met slimme tools.

Hij verdeelde die evolutie in drie bedrijven.

In Act I, de server-era van 1996 tot 2015, draaide alles om pagina’s die volledig door de server werden gegenereerd. Denk aan PHP of HTML die rechtstreeks uit templates kwam. Daarna kwam de Flash-periode, waarin interfaces vooral bestonden uit pixels in plaats van DOM-elementen. Vervolgens de Ajax-tijd: dynamische data “sprinkles” die websites wat interactiviteit gaven. De jaren 2010 brachten de SPA’s, single-page apps waarin de client de koning was: één keer laden en daarna alles lokaal afhandelen.

In Act II kwam de ommekeer. Met de opkomst van APIs, server-side rendering en React Server Components keerden veel verantwoordelijkheden terug naar de server. Ontwikkelaars begonnen na te denken over de balans tussen client en server, performance en streaming. Kaufman vatte het mooi samen: “We optimized where to render for a decade. Now we optimize what to render.” Niet langer de locatie van de render is de belangrijkste keuze, maar de vraag welke content en componenten überhaupt getoond moeten worden en wie dat bepaalt.

Act III bracht de grote plotwending: AI. Tools kunnen vandaag complete interfaces genereren vanuit Figma-bestanden, kleurpaletten aanpassen op commando of componenten toevoegen via een gesprek in natuurlijke taal. Kaufman liet een live demo zien waarin een chatinterface een kleurpicker genereerde en direct geïntegreerd in een bestaande UI. De grens tussen mens – machine en design – implementatie is dunner dan ooit.

Toch waarschuwde hij voor een verkeerde conclusie. Het is niet het einde van de front-end of van grafische interfaces. Mensen blijven nodig voor micro-interacties, toegankelijkheid en gevoel voor context. De kern van het vak verandert: front-end is niet langer een aparte specialisatie, maar een deel van volwaardige software-engineering. Wie de fundamenten van webarchitectuur begrijpt, — netwerk, performance, beveiliging, state management — zal zich blijven onderscheiden.

Kaufman eindigde met een optimistische noot: “Dit is niet het einde van front-end development, maar een nieuw begin”. De toekomst is aan ontwikkelaars die verder kijken dan frameworks, die design systems begrijpen en weten hoe AI hun werk kan versnellen zonder hun rol over te nemen. Wie zich aanpast aan die bredere manier van denken, staat sterker dan ooit.

The Real Cost of React Re-renders in 2025 – Emīls Pļavenieks

Emīls Pļavenieks, een ontwikkelaar uit Letland met een passie voor performance en side-projects, gaf een scherpe en diepgaande talk over iets wat veel React-ontwikkelaars kennen, maar zelden écht begrijpt: re-renders. Zijn sessie “The real cost of React re-renders in 2025” liet zien hoe moderne React-apps vaak performant lijken, maar onder de oppervlakte vol verborgen vertragingen zitten — van subtiele CPU-belastingen tot hydration mismatches die pas opvallen wanneer je app draait op tragere devices of instabiele netwerken.

Pļavenieks begon met de basis: waarom rendert React eigenlijk opnieuw? Elke verandering in state, context of props kan een her-render veroorzaken, maar lang niet altijd om de juiste redenen. Vooral complexe hooks, contextgebruik en foutief gememoiseerde functies zorgen ervoor dat componenten vaker renderen dan nodig. “Most re-renders are cheap,” benadrukte hij, “but some are very expensive — especially when they trigger heavy computation or block the main thread.”

Hij nam het publiek stap voor stap mee door het proces dat elke React-component doorloopt. Eerst is er de render phase, waarin React de virtuele DOM opbouwt. Daarna volgt de commit phase, waarin de daadwerkelijke wijzigingen worden toegepast op de browser-DOM. Pas daar vinden de echte en kostbare operaties plaats: layout thrashing, appendChild-acties en herberekeningen van de UI. In veel projecten ligt hier het ongemerkte performanceprobleem.

Tijdens zijn live demo liet Pļavenieks zien hoe je zulke bottlenecks kunt blootleggen met moderne tooling. In Chrome’s Performance-tab en de React DevTools Profiler toonde hij flamegraphs van een component dat bij het scrollen of typen meerdere keren onnodig opnieuw renderde. Door de CPU te throttlen werd duidelijk zichtbaar hoeveel tijd elke render kostte — soms vier keer meer dan verwacht. Zijn boodschap was helder: optimaliseer eerst de renders zelf, voordat je probeert re-renders te voorkomen.

Daarna verdiepte hij zich in wat React de afgelopen jaren veranderd heeft. React 18 introduceerde concurrent rendering, waarbij React z’n “fibers” kan pauzeren en prioriteit kan geven aan belangrijkere taken. Dat maakt de interface vloeiender, maar kan ook nieuwe valkuilen opleveren als transitions verkeerd worden gebruikt. In React 19, dat hij beschreef als “compiler-backed React”, komt daar nog een revolutionaire stap bij: React Forget. Deze nieuwe compiler maakt memoization grotendeels automatisch. Waar we vroeger zelf moesten nadenken over useMemo en useCallback, zal React zelf bepalen wat onthouden moet worden. Dat moet niet alleen her-renders verminderen, maar ook inconsistenties tussen renders en commits voorkomen.

Pļavenieks toonde hoe React 19 dankzij “partial signals” en een slimmer diff-algoritme alleen datgene her-rendert wat écht nodig is. Toch waarschuwde hij dat geen enkele tool de verantwoordelijkheid van ontwikkelaars overneemt: “There’s no single performance metric that tells the full story. Smoothness is what users feel — not what you measure.”

Hij sloot af met een belangrijke boodschap voor teams: performance is niet iets dat je aan het eind van een sprint test. Het moet een structureel onderdeel zijn van het ontwikkelproces. Gebruik flamegraphs, meet core web vitals zoals INP en/of TBT en leer de commit phase begrijpen — want dáár ligt de echte kost van re-renders.

Debug Like a Pro: Unlocking Hidden Power in the Latest Chrome DevTools – Talia Asghar

Ik denk dat iedere ontwikkelaar wel eens vastzit. Je zit urenlang te staren naar je scherm, breakpoints gezet, logs gecheckt, maar het probleem blijft zich verstoppen. Debuggen kan frustrerend zijn — en zoals Kerninghan’s Law zegt: “Debugging is twice as hard as writing the code in the first place.”

Tijdens de sessie van Talia Asghar, Developer bij Delivery Hero en Google Developer Expert, ontdekte ik dat Chrome DevTools veel krachtiger is dan ik dacht. Het gaat verder dan inspecteren en breakpoints zetten. Er schuilen verborgen tools die je debugging-game volledig kunnen veranderen.

Een nieuwe kijk op DevTools

De sessie begon met een vraag: “Welke Chrome DevTools heb je nog nooit gebruikt?” De resultaten waren verrassend. Meer dan de helft van de aanwezigen had nog nooit van Sensors of AI Assistance gehoord. Dat zette me aan het denken: hoeveel verborgen parels liggen er nog in onze tools die we simpelweg niet gebruiken?
Talia nam ons mee langs tien functies die niet alleen tijd besparen, maar ook je manier van werken verandert.

De magie van Sensors

Eén demo die bleef hangen, was Sensors. Met een paar klikken emuleerde Talia een apparaat in een andere tijdzone, veranderde de locatie en schakelde naar een andere taal. Plots zag ik hoe makkelijk het is om te testen voor internationale gebruikers zonder een fysiek device aan te sluiten. Voor iemand die werkt aan apps met meerdere talen of locatie-afhankelijke features, is dit echt heel waardevol.

CSS Overview: schoon schip maken

Tijdens de CSS Overview demo ontdekte ik hoe eenvoudig het is om inconsistenties in je design system te vinden. Contrastproblemen voor toegankelijkheid? Check. Ongebruikte CSS-regels? Check-check. Inconsistent gebruik van knoppen of kleuren? Ook check. Deze tool voelde als een extra paar ogen die je project kritisch doorlicht.

Local Overrides: vrijheid in debuggen

Een van mijn favoriete momenten was de demo over Local Overrides. Stel je voor: je front-end hangt vast, omdat het back-end nog niet klaar is. Normaal zou je moeten wachten, maar met local overrides kun je content, API-responses of zelfs scripts lokaal aanpassen en testen alsof het live is. Niet wachten, geen frustratie — gewoon doorwerken.

Autofill en performance monitoring

De demo over Autofill Debugging liet zien hoe je formulieren test met verschillende adressen en landen. Voor developers die werken aan internationale formulieren is dit heel waardevol. En dan was er nog de Performance Monitor, waarmee je realtime CPU en geheugenverbruik ziet. Samen met de Coverage tool die ongebruikte code aan het licht brengt, voelt dit als een toolbox voor optimale performance.

AI Assistance: debuggen met een assistent

Er zit ook een AI-assistent in DevTools. Je stelt vragen over je pagina of een API-call en krijgt direct inzichten, zonder dat je hoeft te wisselen tussen tools.

The Tech Behind Buienradar: How Technology Keeps You Ahead of the Weather — Neel Bhatt

De talk van Neel Bhatt, software engineer bij RTL Nieuws (eigenaar van Buienradar), bood een zeldzaam kijkje achter de schermen van Nederlands populairste weerplatform. Hij begon met een eenvoudige observatie: “In Nederland is regen niet zomaar weer — het is cultuur.”
Buienradar is met 93,5 miljoen pageviews per dag en 7,5 miljoen unieke gebruikers per maand het drukst bezochte weerplatform van het land. Wat velen echter niet weten, is dat dit alles wordt onderhouden door een team van slechts zeven ontwikkelaars. Iedere vijf minuten worden nieuwe radarbeelden verwerkt, afkomstig van meer dan tachtig radars en tien waarschuwingssystemen, goed voor miljoenen alerts per dag.

Van stormachtige monoliet naar schaalbare microservices

Bhatt schetste hoe Buienradar jarenlang draaide op een monolithische architectuur die regelmatig bezweek onder zijn eigen succes. Eén bug kon het hele systeem platleggen, releases veroorzaakten nachtelijke stress en trage pagina’s misten soms letterlijk de regen waarvoor ze bedoeld waren. Slechte observability maakte het bovendien lastig om problemen te lokaliseren en op social media kon één foutieve voorspelling een storm aan kritiek veroorzaken.
In plaats van meer hardware toe te voegen of de schuld bij upstream-providers te leggen, besloot het team tot een fundamentele herziening. Het motto werd: “True scalability is culture plus code moving faster than the storm.” Ze kozen voor een DevOps-mentaliteit waarin elasticiteit, resilience, observability, automatisering en prestatieoptimalisatie centraal staan.

Turning the tide

De nieuwe infrastructuur draait op Kubernetes, met ArgoCD en GitOps als basis voor volledig geautomatiseerde en versiebeheerde deployments. De overgang van een monoliet naar microservices bracht flexibiliteit en zelfherstellend vermogen. Wanneer één service faalt, blijft de rest operationeel. Deployments verlopen zonder downtime dankzij canary releases, feature flags en automatische rollback-mechanismen.
De voordelen zijn meetbaar: 93,5 miljoen views per dag, 200 miljoen API-requests, 1,6 miljoen gelijktijdige gebruikers en razendsnelle API’s — de Image API reageert in 30 ms, Graph API in 20 ms, Location API in 17 ms en Forecast API binnen 200 ms.

Observability en weerbestendig ontwerpen

Een belangrijk thema was observability. Met OpenTelemetry, Grafana Loki en een uitgebreid dashboard krijgt het team realtime inzicht in latency, CPU-belasting, foutpercentages en ontbrekende datapunten. Problemen worden zichtbaar nog vóór gebruikers er iets van merken.
Ook bij het ontwerp van de systemen is rekening gehouden met falen. Bhatt beschreef hoe circuit breakers, retries met exponential backoff, failover-mechanismen en self-healing pods helpen om incidenten op te vangen zonder merkbare impact. Automatische alerts via PagerDuty en postmortems zorgen ervoor dat elk incident wordt geanalyseerd en verbeteringen structureel worden doorgevoerd.

Snelheid en efficiëntie als kernwaarde

Om latency laag te houden, maakt Buienradar gebruik van caching, CDN’s, asynchrone verwerking, compressie, minificatie en NoSQL-databases zoals Elastic en MongoDB. Hierdoor blijft het platform responsief, zelfs onder zware belasting.
Bhatt sloot af met een vooruitblik. Het team experimenteert met 3D-weermodellen, AI-ondersteunde code review en verdere verfijning van observability. Zijn conclusie was helder: schaalbaarheid draait niet alleen om technologie, maar om cultuur, discipline en een team dat leert bewegen met de storm in plaats van ertegenin.

Conclusie van het evenement

Frontmania 2025 laat de breedte zien van front-end development. Het is niet alleen de visuele weergave, schaalbare systemen, slimme observability en een nauwe samenwerking tussen mens, machine en architectuur. Van de filosofische diepgang van reactive programming tot de praktische kracht van web components, van AI in design systems tot de precisie van performance-optimalisatie en DevTools. Elke talk benadrukte dezelfde beweging: een vakgebied dat continu leert, automatiseert en evolueert. De toekomst van front-end is niet één framework, maar een mindset die even veerkrachtig en reactief is als de systemen die we bouwen.