Een frontend die vandaag werkt is een lage lat. De interessante vraag is of dezelfde codebase over drie jaar — met andere mensen, andere bibliotheken en een andere productrichting — nog steeds werkbaar is. Mijn werk in frontend-architectuur richt zich primair op die middellange termijn.
Concreet heb ik aan grote SPA's gewerkt in vrijwel iedere Angular-versie van 1.13 tot en met 16, en daarnaast in Vue.js 2 en React/TypeScript. Voor mij is geen enkel framework heilig; het zijn middelen om gestructureerd vakwerk te leveren. Wel ben ik strikt over scheiding van zorgen, gedeelde building blocks en een testbare laag tussen UI en businesslogica.
Specifiek met micro-frontends heb ik diepgaande ervaring opgedaan op het nalatenschap-portaal. Daar leven Angular 16 en AngularJS jarenlang naast elkaar binnen één applicatie. Routing, sessies, styling en state moeten naadloos samenwerken zonder dat de gebruiker ooit doorheeft welk deel hij gebruikt. Goed neergezet is dat een onzichtbare oplossing; slecht neergezet wordt het een tweede legacy systeem bovenop het eerste.
In het online casino-portaal en het social game-platform leerde ik wat een SPA-architectuur betekent op echte schaal: continu live met betalingen en gaming-providers communiceren, met een UI die zo dicht mogelijk bij een native app moet aanvoelen. In het horloge-CRM/ERP en het reparatieportaal lag de uitdaging in real-time signalering richting Angular via websockets. In de 3D-configurator dwong de combinatie van Angular met WebGL me om scenegraph-achtig te denken in een framework dat daar van huis uit niet voor is gemaakt.
Componenten, state-management en testbaarheid zijn de gereedschappen die ik in al deze projecten als één systeem heb leren behandelen. Een component dat alleen werkt in zijn eigen context is broos; een component dat losstaand getest, herbruikt en uitgewisseld kan worden is veel meer waard dan zijn paar regels code suggereren.
Verder geloof ik sterk in design systems als instrument om consistentie en snelheid tegelijk te halen. Niet als bibliotheek die ergens los leeft, maar als onderdeel van het ontwikkelproces zelf — dichtbij de productontwerpers en met expliciete bijdragen vanuit elk team dat ervan gebruik maakt.