Am 19. Juni 2025 war ich beim PiterJS #79 in St. Petersburg. Der Abend hatte ein angenehm unspektakuläres Thema: nicht die nächste Funktion möglichst schnell auszuliefern, sondern das zu betreiben und weiterzuentwickeln, was bereits existiert — Monitoring, Deployment und Refactoring.
Das Programm passte genau dazu. Pavel Shlykov sprach darüber, wie man einen alten Monolithen verbessert, Alexander Panfilov über FrontOps und Igor Antonov über Performance-Metriken für Webanwendungen. Zu allen drei Themen nahm ich praktische Notizen mit.
Der unerwartete Teil war das Q&A. Am Ende gewann ich zwei Preise für die besten Fragen während der Sessions. Das ist kein großer technischer Erfolg, aber gerade deshalb blieb mir dieser Moment im Gedächtnis: Er erinnerte mich daran, warum ich Präsenz-Meetups weiterhin schätze. Man konsumiert nicht nur einen vorbereiteten Vortrag, sondern kann das eigene Verständnis prüfen, solange die Menschen, die das Thema vorgestellt haben, noch im Raum sind.
Das nützliche Thema war Wartung, nicht Neuheit
Frontend-Veranstaltungen können leicht zu einer Parade neuer Frameworks, APIs und Abstraktionen werden. PiterJS #79 war bodenständiger. Das angekündigte Thema war die Unterstützung von Software, die bereits läuft.
Das ist relevant, weil ein großer Teil der Engineering-Arbeit nach dem ersten erfolgreichen Release beginnt. Ein Legacy-Monolith ist nicht automatisch ein schlechtes System, und „Modernisierung“ bedeutet nicht automatisch, alles neu zu schreiben. Die praktischere Frage lautet meist: Welche Einschränkung verursacht heute tatsächlich Probleme, und welche Änderung reduziert diese Probleme, ohne mehr Risiko zu erzeugen, als sie beseitigt?
Deshalb passten die drei Vorträge für mich gut zusammen. Refactoring verändert den Code. FrontOps verändert, wie das Frontend gebaut, paketiert, ausgeliefert und betrieben wird. Performance-Arbeit verändert, wie wir das Ergebnis messen. Das sind unterschiedliche Ebenen derselben Aufgabe: ein reales System auch nach seinem Wachstum verständlich und kontrollierbar zu halten.
FrontOps ist mehr als ein Dockerfile
Eine meiner Notizen vom Meetup betraf FrontOps mit Docker. Die wichtige Unterscheidung lautet: Docker ist ein Werkzeug, nicht die Definition von FrontOps.
Frontend-Verantwortung endet nicht zwangsläufig, sobald npm run build erfolgreich war. In einem Produktionssystem muss weiterhin jemand über reproduzierbare Builds, die Paketierung von Artefakten, Konfiguration, Rollbacks, Caching und die Beobachtung von Fehlern nachdenken. Container können manche dieser Abläufe vorhersehbarer machen, ersetzen aber nicht die betrieblichen Entscheidungen dahinter.
Das korrigiert ein verbreitetes mentales Modell: Ein erfolgreicher Build beweist, dass der Build abgeschlossen wurde. Er beweist nicht, dass die Anwendung korrekt deployt wird, sich in Produktion korrekt verhält oder sich bei einem Fehler problemlos wiederherstellen lässt.
Performance beginnt mit der Frage, was „langsam“ bedeutet
Der Performance-Vortrag war besonders praktisch darin, wie er Messung einordnete. Der angekündigte Umfang umfasste Faktoren, die Ladegeschwindigkeit beeinflussen, verschiedene Frontend-Performance-Metriken, Möglichkeiten, „langsam“ zu quantifizieren, und sogar die Frage, warum Optimierung nicht immer notwendig ist.
Gerade der letzte Punkt wird leicht unterschätzt. „Mach es schneller“ klingt objektiv. Ohne eine Metrik und ein sichtbares Nutzerproblem kann daraus jedoch teures Raten werden. Ein sinnvoller Performance-Prozess beginnt damit, zu definieren, was tatsächlich langsam ist, es zu messen, den Engpass zu identifizieren, eine relevante Sache zu ändern und danach erneut zu messen.
Eine Metrik ist nicht die User Experience selbst, aber sie gibt der Diskussion eine gemeinsame Einheit. Ohne Messung kann Performance-Arbeit zu einer Sammlung technisch beeindruckender Änderungen werden, ohne klare Evidenz dafür, dass sie das relevante Problem verbessert haben.
Das Q&A hat den Wert des Meetups für mich verändert
Ich hätte später Aufzeichnungen ansehen und Links sammeln können. Was sich deutlich schwerer reproduzieren lässt, ist die Interaktion rund um einen Vortrag. Eine gute Frage zu stellen zwingt mich, meine Unsicherheit so weit zu verdichten, dass ein anderer Engineer konkret darauf antworten kann.
Die zwei Preise waren natürlich schön. Die nützlichere Erkenntnis war aber einfacher: Wer vorbereitet kommt und wirklich teilnimmt, bekommt aus einem Offline-Meetup deutlich mehr heraus, als wenn er es wie eine Live-YouTube-Playlist behandelt.
Eine gute technische Frage enthält meist Kontext und eine Einschränkung. Statt „Was ist die beste Architektur?“ ist es oft hilfreicher zu fragen, welcher Trade-off sich verändert, wenn ein Team ein Legacy-System nicht neu schreiben kann, ein Deployment rückwärtskompatibel bleiben muss oder eine Performance-Metrik besser wird, ohne dass Nutzer einen entsprechenden Unterschied bemerken.
Nicht jede Frage muss besonders clever sein. Sie sollte vor allem Annahmen, Grenzen oder mögliche Fehlerfälle sichtbar machen.
Was ich zum nächsten technischen Meetup mitnehmen würde
- Wissen, warum ein Vortrag für mich relevant ist. Vor Beginn ein reales Problem oder eine offene Frage notieren.
- Die Erfahrung des Speakers vom eigenen System trennen. Eine gute Fallstudie ist Evidenz, kein universelles Rezept.
- Nach Trade-offs fragen. „Wann würdest du das nicht einsetzen?“ ist oft aufschlussreicher als „Welches Tool ist das beste?“
- Eine konkrete Folgeaktion festhalten. Eine Notiz wird wertvoller, wenn daraus etwas entsteht, das ich später prüfen, testen oder nachlesen kann.
- Einen überzeugenden Vortrag nicht mit Produktionsbeweisen verwechseln. Architektur-, Deployment- und Performance-Entscheidungen müssen weiterhin im eigenen Umfeld validiert werden.
Was geblieben ist
Ich möchte nicht übertreiben, was ein einzelnes Meetup verändern kann. Ich bin nicht mit einem universellen Architektur-Rezept aus PiterJS gegangen, und ein guter Vortrag ersetzt weder Dokumentation noch Profiling, Tests oder Produktionsdaten.
Was ich tatsächlich mitgenommen habe, ist konkreter: brauchbare Notizen zur Modernisierung eines Legacy-Monolithen, zu FrontOps mit Docker und zur Messung von Web-Performance; zwei Preise aus dem Q&A; und eine weitere Erinnerung daran, dass lokale Developer-Communities es wert sind, persönlich hinzugehen.
Aufzeichnungen können den Vortrag bewahren. Der Teil, der sich am schwersten archivieren lässt, ist das Gespräch darum herum.