Op 19 juni 2025 ging ik naar PiterJS #79 in Sint-Petersburg. De avond had een verfrissend weinig glamoureus thema: niet hoe je de volgende feature bouwt, maar hoe je onderhoudt wat al bestaat — monitoring, deployment en refactoring.
Het programma sloot daar goed op aan. Pavel Shlykov sprak over het verbeteren van een oude monoliet, Alexander Panfilov over FrontOps en Igor Antonov over performancemetrics voor webapplicaties. Over alle drie de onderwerpen ging ik met praktische aantekeningen naar huis.
Het onverwachte deel was de Q&A. Uiteindelijk won ik twee prijzen voor de beste vragen tijdens de sessies. Het is een klein detail, maar juist daardoor werd het mijn meest memorabele moment van de avond. Het bevestigde waarom ik technische meetups op locatie nog steeds waardeer: je kunt meer doen dan een voorbereide talk consumeren. Je kunt je eigen begrip toetsen terwijl de mensen die het onderwerp net hebben gepresenteerd nog in dezelfde ruimte zijn.
Het nuttige thema was onderhoud, niet nieuwigheid
Frontend-evenementen kunnen gemakkelijk veranderen in een parade van nieuwe frameworks, API’s en abstracties. PiterJS #79 was nuchterder. Het aangekondigde thema ging over het ondersteunen van software die al bestaat.
Dat is relevant omdat veel engineeringwerk pas na de eerste succesvolle release begint. Een legacy-monoliet is niet automatisch een slecht systeem, en “moderniseren” betekent niet automatisch alles herschrijven. De praktische vraag is meestal smaller: welke beperking doet het systeem nu echt pijn, en welke verandering vermindert dat probleem zonder meer risico toe te voegen dan ze wegneemt?
Daarom pasten de drie talks voor mij ook goed bij elkaar. Refactoring verandert de code. FrontOps verandert hoe de frontend wordt gebouwd, verpakt, geleverd en beheerd. Performancewerk verandert hoe we het resultaat meten. Het zijn verschillende lagen van hetzelfde probleem: een echt systeem begrijpelijk en beheersbaar houden nadat het is gegroeid.
FrontOps is breder dan een Dockerfile
Een van mijn notities van de meetup ging over FrontOps met Docker. Het belangrijke onderscheid is dat Docker een hulpmiddel is, niet de definitie van FrontOps.
Frontendverantwoordelijkheid eindigt niet per se zodra npm run build slaagt. In productie moet iemand nog steeds nadenken over reproduceerbare builds, het verpakken van artifacts, configuratie, rollbacks, caching en het waarnemen van fouten. Containers kunnen een deel daarvan voorspelbaarder maken, maar vervangen de operationele beslissingen niet.
Dat corrigeert een veelvoorkomend denkmodel: een geslaagde build bewijst dat de build is afgerond. Het bewijst niet dat de applicatie correct wordt gedeployed, zich in productie correct gedraagt of eenvoudig te herstellen is wanneer er iets misgaat.
Performance begint met bepalen wat “traag” betekent
De performancetalk was vooral praktisch in de manier waarop meten werd benaderd. De aangekondigde inhoud omvatte factoren die laadsnelheid beïnvloeden, verschillende frontendperformancemetrics, manieren om “traag” te kwantificeren en zelfs de vraag waarom optimaliseren niet altijd nodig is.
Dat laatste is gemakkelijk te onderschatten. “Maak het sneller” klinkt objectief, maar zonder een metric en een zichtbaar gebruikersprobleem kan het dure gokkerij worden. Een nuttig performanceproces begint met definiëren wat werkelijk traag is, het meten, de bottleneck vinden, één relevante verandering doen en opnieuw meten.
Een metric is niet op zichzelf de gebruikerservaring, maar geeft het gesprek wel een gedeelde eenheid. Zonder metingen kan performancewerk veranderen in een verzameling technisch indrukwekkende wijzigingen zonder duidelijk bewijs dat het probleem dat ertoe deed daadwerkelijk is verbeterd.
De Q&A veranderde de waarde van de meetup voor mij
Ik had later opnames kunnen bekijken en links kunnen verzamelen. Wat veel moeilijker te reproduceren is, is de interactie rondom de talks. Een goede vraag stellen dwingt je om je onzekerheid terug te brengen tot iets specifieks waarop een andere engineer daadwerkelijk kan antwoorden.
Twee prijzen winnen was leuk, maar de nuttigere les was eenvoudiger: voorbereid komen om mee te doen geeft een offline meetup veel meer waarde dan wanneer je die behandelt als een live YouTube-playlist.
Een sterke technische vraag bevat meestal context en een beperking. In plaats van “Wat is de beste architectuur?” is het vaak nuttiger te vragen welke trade-off verandert wanneer een team een legacy-systeem niet kan herschrijven, wanneer een deployment backward-compatible moet blijven of wanneer een performancemetric verbetert zonder een overeenkomstig zichtbaar voordeel voor gebruikers.
Niet iedere vraag hoeft slim te klinken. Ze moet vooral aannames, grenzen of failure modes blootleggen.
Wat ik naar de volgende technische meetup zou meenemen
- Weten waarom een talk voor mij relevant is. Vooraf één echt probleem of één onzekerheid opschrijven.
- De ervaring van de spreker scheiden van mijn eigen systeem. Een goede case study is bewijs, geen universeel recept.
- Naar trade-offs vragen. “Wanneer zou je dit juist niet gebruiken?” zegt vaak meer dan “Welke tool is het beste?”
- Eén vervolgactie vastleggen. Een notitie wordt nuttiger als die leidt naar iets dat ik na de meetup kan verifiëren, testen of lezen.
- Een overtuigende talk niet verwarren met productieproof. Architectuur-, deployment- en performancebeslissingen moeten nog steeds in de eigen omgeving worden gevalideerd.
Wat bleef hangen
Ik wil niet overdrijven wat één meetup kan veranderen. Ik verliet PiterJS niet met een universeel architectuurrecept, en een goede talk vervangt geen documentatie, profiling, tests of productiedata.
Wat ik wel meenam was concreter: bruikbare notities over het moderniseren van een legacy-monoliet, FrontOps met Docker en het meten van webperformance; twee prijzen uit de Q&A; en opnieuw de herinnering dat lokale developercommunities de moeite waard zijn om fysiek voor te verschijnen.
Opnames kunnen de presentatie bewaren. Het gesprek eromheen is het deel dat het moeilijkst te archiveren is.