Universität Jena: Migration auf Vue 3

Problem und Rahmenbedingungen

Der Webauftritt der Friedrich-Schiller-Universität Jena umfasst mehr als hundert Einrichtungen. Mein Ausschnitt davon war die Physikalisch-Astronomische Fakultät: neun Institutswebsites, vom Astrophysikalischen Institut und der Universitätssternwarte bis zum Otto-Schott-Institut für Materialforschung und dem Fraunhofer-Institut für Angewandte Optik und Feinmechanik (IOF).

Die Websites liefen auf Vue 2, das sich dem Ende seines Supports näherte, und jedes Jahr Wachstum machte die Codebasis schwerer wartbar. Das Framework war nicht das einzige Problem: Es gab zwar eine gemeinsame Komponentenbibliothek, aber sie wurde über die Websites hinweg uneinheitlich genutzt (manche Teams setzten sie ein, andere nicht), und so war sie in einen veralteten, chaotischen Zustand abgedriftet, mit Varianten derselben Oberfläche auf jeder Website.

Zwei Rahmenbedingungen prägten alles. Die Websites mussten durchgehend online bleiben; eine Universität kann ihre Institute nicht für eine Neuentwicklung vom Netz nehmen. Und das Team war funktionsübergreifend aufgestellt (Backend-Entwickler, UI/UX-Designer, DevOps-Engineers), also musste die Migration vorankommen, ohne die Arbeit der anderen zu blockieren. Die Vue-Migration selbst, ihr Testing und die Komponentenbibliothek lagen in meiner Verantwortung.

Architektur

Das waren keine SPAs. Jede Institutswebsite war eine Multi-Page-Anwendung, in die Vue dort eingebunden war, wo Interaktivität gebraucht wurde, bei Dashboards und interaktiven Komponenten, gebaut mit Webpack. Der Zustand lag in Vuex, die Daten kamen über REST-APIs (per Axios) aus einem schlichten Java-Backend. Die gemeinsame Komponentenbibliothek reichte über alle neun Websites.

Die Migration selbst lief in einem separaten Repository: Dort wurde die Codebasis schrittweise und unter Tests umgestellt, während die Produktion unberührt blieb. Erst als der umgestellte Code gründlich getestet war, ersetzte er die Live-Websites; einen Wechsel auf eine halb migrierte Codebasis gab es nie. Die Entscheidungen dahinter stehen im Entscheidungsprotokoll unten, jede mit der Alternative, gegen die sie sich durchgesetzt hat.

Ergebnisse

Tree-Shaking und die kleinere Laufzeitumgebung von Vue 3 machten das JavaScript-Bundle um 40 % kleiner. Die Barrierefreiheit wurde über ARIA-Attribute und semantisches HTML auf WCAG-Konformität gebracht, und Cypress-basierte Integrationstests, gemeinsam mit dem Team eingeführt, gaben der Migration eine End-to-End-Abdeckung.

Genauso wichtig waren die strukturellen Gewinne: Die Plattform konnte wieder mit aktuellen Vue-Funktionen Schritt halten, alte selbst geschriebene Logik wurde durch gut gepflegte Erweiterungen aus dem Vue-Ökosystem ersetzt, die Komponentenbibliothek war über alle neun Websites hinweg einheitlich und aktuell, und die Codebasis kam aus der Migration spürbar sauberer heraus, als sie hineingegangen war.

Lehren

Würde ich es noch einmal machen, würde ich alles auf die Composition API umstellen und keine Options API zurücklassen. Die stabilen Abschnitte zu behalten wirkte damals pragmatisch, aber eine Codebasis in zwei Stilen hat leise Kosten: Jedes künftige Upgrade und jede neue Person im Team muss mit zwei Denkmodellen umgehen, und der übrig gebliebene Options-Code ist genau die Stelle, an der künftige Reibung auftauchen wird. Die schrittweise Strategie mit separatem Repository würde ich dagegen ohne Zögern wiederholen: Sie hat neun Live-Websites einer Universität ohne Drama das Framework wechseln lassen.