Das nächste Frontend‑Framework wählen: Ein praxisnaher Entscheidungsleitfaden aus „How to pick the next Front End Framework“ von Tomi Močnik (TimeTac)

Kontext: Eine langlebige Produktplattform trifft eine Weichenstellung

In seinem Vortrag „How to pick the next Front End Framework“ schildert Tomi Močnik, Lead Front End Developer bei TimeTac, einen Entscheidungsprozess, den viele Engineering‑Teams kennen: Wann und wie wechseln wir das Frontend‑Framework – und welches nehmen wir? TimeTac bietet als Software‑as‑a‑Service Anbieter eine Zeit‑ und Anwesenheitslösung für Web‑ und Mobile‑Clients und bedient damit mehr als 80.000 User. Das Produkt ist langlebig, komplex und wächst kontinuierlich. Gleichzeitig kommen neue Features, kundenspezifische Anpassungen und technische Verbesserungen laufend hinzu.

Genau in diesem Umfeld stellte sich die Grundsatzfrage: beim bestehenden Framework bleiben, langsam migrieren – oder von Grund auf neu starten? Das Team entschied sich für Option drei: ein Neustart. Tomi macht dabei klar, worüber er nicht spricht: Es geht nicht um Vanilla JavaScript versus Framework, nicht darum, ein eigenes Framework zu schreiben, und auch nicht darum, „das eine beste Framework“ zu küren oder Management von einem Wechsel zu überzeugen. Im Zentrum steht stattdessen ein nüchterner, teamgetriebener Prozess, der technische Fakten, Produktrealitäten und den Faktor Mensch vereint.

Warum überhaupt wechseln? Typische Auslöser für einen Framework‑Switch

Der Vortrag benennt die Gründe, die in der Praxis am häufigsten den Ausschlag geben:

• Nicht mehr unterstütztes Framework: Frameworks entwickeln sich ständig weiter. Manche veralten, werden nicht mehr gewartet und gelten irgendwann als „outdated“.
• Überalterte, schwer wartbare Codebasis: Legacy‑Code ohne Tests, ohne Ownership und ohne Klarheit über die Funktionsweise ist ein Risiko für Qualität und Delivery‑Tempo.
• Performance‑Grenzen: Wenn Performance‑Probleme im aktuellen Framework nicht mehr lösbar sind, zwingt die Technik zum Kurswechsel.
• Entwicklermarkt und Motivation: Modernere Frameworks sind oft besser gebaut und „mehr Spaß“ – und Entwickler möchten ungern mit Altsystemen arbeiten. Der Arbeitsmarkt spiegelt das wider.

Diese Punkte sind kein Selbstzweck. Sie adressieren reale Produkt‑ und Teamrisiken: Wartbarkeit, Lieferfähigkeit, Recruiting‑Fähigkeit und langfristige Zukunftssicherheit.

Wann ist der richtige Zeitpunkt? Voraussetzungen vor dem Startschuss

„Wechseln, weil gestern ein neues Framework erschienen ist“ – Tomi hält das für keine gute Idee. Seine Leitplanken für den Zeitpunkt des Wechsels:

• Stabiler Produktzustand und verlässliche Umsätze, um die Kosten eines Rewrites zu tragen.
• Eine klare Vision samt Feature‑Freeze für den Altzustand: Was bleibt im bisherigen System, was wird migriert, was gehört in das neue Framework?
• Ausreichende Entwicklungsressourcen: Ein Rebuild ist fordernd und braucht dedizierte Kapazität.
• Buy‑in im gesamten Unternehmen: vom Engineering bis zum Management. Große Veränderungen werden nicht leichter, wenn man sie aufschiebt – je länger man wartet, desto härter wird der Schritt.

Diese Kriterien verankern die Entscheidung in der Realität des Produkts – und verhindern, dass ein Rebuild zu einer technisch motivierten, aber wirtschaftlich riskanten Bauchentscheidung wird.

Wie wechseln? Vom Recherche‑Funnel bis zur Entscheidung

Der Kern des Vortrags ist ein Vorgehensmodell, mit dem TimeTac den Markt sondierte, Anforderungen schärfte und den Auswahlraum strukturiert verkleinerte.

1) Anforderungen „ehrlich“ definieren

Es macht einen massiven Unterschied, ob:

• nur Look & Feel gewechselt wird (gleiche App, anderes Rendering),
• das gesamte Frontend neu geschrieben wird, oder
• die Anwendung bewusst identisch aussieht, aber „unter der Haube“ ein neues Framework nutzt.

Für TimeTac spielten konkrete Bausteine eine zentrale Rolle: Grids, Dialoge, Kalender und fortgeschrittene Datenansichten – entweder „out of the box“ oder als hochwertige Add‑ons. Ebenfalls Pflicht: Entwickler‑Support und Tools (Build, Kompilierung & Co.), solide Dokumentation („einfach zu nutzen, aktuell und verständlich“) und ein realistischer Kostenrahmen, falls Bibliotheken oder Komponenten lizenziert werden müssen.

Nicht zu unterschätzen: der Wissensaspekt. Ein neues Framework bedeutet Lernaufwand. Bereits vorhandene Team‑Erfahrung mit einem Kandidaten kann den Start dramatisch beschleunigen.

2) Den Markt lesen – Trends als Ausgangspunkt, nicht als Dogma

Tomi verweist auf Surveys wie stateofjs.com, die jährlich Stimmungen, Nutzung, „Like/Hate“-Signale, Tool‑Landschaft und Community‑Größe einfangen. Ein Diagramm kann einen klaren „Sieger“ suggerieren. Seine Quintessenz: Trends sind ein hilfreicher Kompass, aber keine Entscheidung. Sie zeigen, wohin sich Wissen bewegt und wie der Jobmarkt tickt – doch weniger bekannte Frameworks können ebenfalls funktionieren, tragen aber ein höheres Veraltungsrisiko.

3) Harte Fakten messen

Neben Stimmungen lassen sich messbare Indikatoren heranziehen:

• Community‑Größe und Aktivität (z. B. GitHub‑Statistiken, Versionzyklen)
• Wer steht hinter dem Projekt? (Backing schafft Vertrauen in die Zukunft)
• Wer nutzt es (auch große Namen)?
• Verfügbarkeit von Tutorials, Videos, Blogposts
• Anzahl der Jobpostings (entscheidend fürs Recruiting)

Das Team aggregierte diese Daten und ergänzte Plus/Minus‑Punkte, Meinungen, Performance‑ und State‑Management‑Aspekte.

4) Engineering‑Vorgehen: Spreadsheet mit Gewichtungen

„Am Ende sind wir Ingenieure.“ TimeTac legte eine große Tabelle an, verteilte Gewichtungen auf die aus ihrer Sicht wichtigsten Kriterien und evaluierte die Kandidaten systematisch. Dieser Schritt diszipliniert: Er zwingt, implizite Prioritäten explizit zu machen und verhindert, dass Einzelmeinungen das Bild verzerren.

Das Ergebnis: Eine frühe Reduktion auf „die großen Drei“, die in vielen Projekten ohnehin im Fokus stehen. Welche das konkret sind, variiert je nach Kontext; entscheidend ist die Reduktion auf einen handhabbaren Vergleichsraum.

5) Passung zum Stack und zur Organisation prüfen

Nach der Grobfilterung folgt die Passform‑Prüfung:

• Integrationsfähigkeit in den bestehenden Stack
• Benötigte zusätzliche Infrastruktur/Tools
• Ausmaß des Wissens‑Shifts im Team (TimeTac wechselte von „XJS“ und musste mit einem größeren Lernsprung rechnen)
• Bedarf, externe Experten zu engagieren, um die Umstellung zu beschleunigen

Die oberste Priorität: ein Framework, mit dem das bestehende Frontend‑Team arbeiten will. Dazu startete TimeTac eine interne Umfrage und erfasste Skills und Erfahrung aller Entwickler für die Kandidaten.

6) Team‑Meinung ernst nehmen und Kandidaten eliminieren

Aus der Befragung ergab sich: Einer der Kandidaten fiel heraus, weil im Team deutlich mehr Wissen zu den anderen beiden vorhanden war. Zusätzlich zeigte Angular laut Tomi „am meisten Widerstand in der Community“ – wegen größerer Umschreibungen und einer steileren Lernkurve. Übrig blieben zwei Kandidaten, zwischen denen TimeTac die finale Wahl traf.

„Meiner Meinung nach sollte es niemals nur eine Top‑Down‑Entscheidung sein. Die Entwickler sollten eine Stimme haben.“ Also fragte das Team explizit, womit sie lieber arbeiten würden – und folgte dieser Stimme.

7) Entscheidung: React – plus TypeScript

Die Entscheidung fiel auf React. Ausschlag gaben kombinierte Daten, Umfragen, Feedback und Diskussionen – eine Entscheidung, hinter der Team und Unternehmen stehen konnten. Zusätzlich wählte TimeTac TypeScript als Basis. Tomi betont, dass dieser Punkt ursprünglich nicht prominent genug im Auswahlkatalog stand, aber zu den Hauptkriterien gehören sollte.

Prototyping als Realitätscheck: Hackathon und Iterationsschleifen

Vor dem Vollumstieg initiierte TimeTac einen zweitägigen internen Hackathon. Ziel: einen Proof of Concept (PoC) für ein Feature bauen. Dadurch ließ sich einschätzen, wie schnell das Team React adaptiert, wie viel Wissen bereits vorhanden ist und ob die Entscheidung sich „echt“ anfühlt.

Der Rat aus dem Vortrag: Beobachten, evaluieren, neu bewerten – in Zyklen. Wenn man an technische Grenzen stößt oder das Bauchgefühl kippt, sollte man „schnell und ohne harte Gefühle“ umschwenken. Diese Haltung schützt vor dem Sunk‑Cost‑Fallacy und hält die Entscheidungsqualität hoch.

„Enjoy it“ – das Ökosystem gezielt erweitern

Mit dem grünen Licht startete die konkrete Tooling‑ und Bibliotheksauswahl – immer auf Basis schneller Evaluierungen und Mini‑PoCs. Die finale Liste, die Tomi nennt:

• State‑Management: Redux
• Routing: React Router
• UI und Basis‑Komponenten: Material UI
• Datum/Zeit: Luxon
• Für Callback‑basierten Code: RxJS
• Automatisierte Tests: Jest plus Testing Library
• Kommunikation mit dem Backend: ein eigenes Open‑Source‑Projekt von TimeTac
• Desktop‑Client: Electron
• Kalenderansicht: FullCalendar
• CI/CD und Automatisierung: GitHub Pipelines (Tests, Linting, Deployment bis in die Produktion)

Diese Auswahl entstand im Dialog der Entwickler: Anforderungen teilen, Optionen vorschlagen, kleine Evaluierungen bauen und zügig entscheiden.

Teamkultur als Hebel: Zuhören, entscheiden, inkrementell verbessern

Zum Abschluss unterstreicht Tomi die Bedeutung der Teamkultur. „Es ist wichtig, immer auf das Team zu hören. Wenn sich etwas ändern muss, findet eine Lösung, die für alle funktioniert.“ Bei TimeTac heißt das: Jede Meinung zählt. In wöchentlichen „Frontend Tea Parties“ diskutiert das Team neue Bibliotheken und Tools, wie sie in das Projekt passen, sammelt Informationen, baut Proofs of Concept, stimmt über Änderungen ab und integriert diese schnell.

Diese Rituale sorgen dafür, dass der Technologiestack nicht statisch ist, sondern sich kontrolliert weiterentwickelt – ohne Entscheidungsmüdigkeit und ohne wildes Tool‑Hopping.

Leitfaden zum Nachbauen: Der Prozess in klaren Schritten

Aus der Session lässt sich ein reproduzierbarer Entscheidungsansatz ableiten. Jeder Schritt ist im Vortrag benannt, und zusammen ergeben sie eine belastbare Roadmap:

1. Problemraum klären: Warum überhaupt wechseln? Welche Produkt‑, Team‑ oder Marktgründe sind ausschlaggebend?
2. Timing prüfen: Produktstabilität, Einnahmen zur Kostendeckung, Feature‑Freeze‑Rahmen, Ressourcen, Organisations‑Buy‑in.
3. Anforderungen erfassen: Zielbild (Re‑Skin, Rewrite), benötigte Komponenten (Grids, Dialoge, Kalender, Advanced Data Views), Doku‑Qualität, Tooling, Kosten.
4. Markt und Trends scannen: Surveys wie stateofjs.com als Ausgangspunkt, kein Dogma.
5. Harte Fakten sammeln: Community, Maintainer/Backing, GitHub‑Aktivität, Versionzyklen, Nutzung durch größere Player, Lernressourcen, Jobmarkt.
6. Bewertungsmatrix aufbauen: Spreadsheet, Gewichtungen, Plus/Minus, State‑Management‑ und Performance‑Aspekte.
7. Kandidaten reduzieren: zunächst auf einen handhabbaren Pool (z. B. „die großen Drei“), dann auf die Favoriten.
8. Stack‑Fit und Lernkurve prüfen: Integration, Infrastruktur, Wissens‑Shift, Bedarf externer Expertise.
9. Team befragen: interne Skills und Präferenzen erfassen; die Entwickler einbeziehen, die täglich damit arbeiten.
10. Entscheidung treffen: datengestützt, teamgetragen; begleitend zentrale Plattformentscheidungen wie TypeScript bewusst treffen.
11. Prototyping: Hackathon oder PoC zur Validierung von Adoptionsgeschwindigkeit und Teamfit.
12. Iterieren: Beobachten, evaluieren, unvoreingenommen neu entscheiden, wenn Grenzen sichtbar werden.
13. Ökosystem zusammenstellen: State, Routing, UI‑Kit, Testing, Build/CI, Desktop‑Client, Spezialkomponenten – jeweils mit Mini‑PoCs und schneller Entscheidungsfindung.
14. Teamkultur pflegen: regelmäßige Austauschformate, gemeinsames Voten, schnelle, kontrollierte Integration von Verbesserungen.

Besonders einprägsame Einsichten aus dem Talk

• „Die länger man wartet, desto schwieriger wird es am Ende.“ Rewrites werden mit der Zeit nicht günstiger. Wer die Entscheidung aufschiebt, erhöht Risiko und Komplexität.
• „Es sollte niemals nur eine Top‑Down‑Entscheidung sein.“ Entwickler‑Buy‑in ist nicht Kür, sondern Bedingung für eine nachhaltige Framework‑Wahl.
• Dokumentation ist ein K.O.-Kriterium. Gute, aktuelle, verständliche Doku spart Lernzeit, reduziert Fehler und beschleunigt Delivery.
• Prototypen sind das beste Antidot gegen Annahmen. Ein zweitägiger Hackathon liefert mehr Evidenz als wochenlange Debatten.
• „Switch fast and without hard feelings“, wenn Limits sichtbar werden. Diese Haltung schützt vor sturem Festhalten an Fehlentscheidungen.

Praktische Anwendung: Von der Dilemma‑Frage zur stabilen Entscheidung

TimeTac stand vor der typischen Dreifaltigkeit: bleiben, migrieren oder neu starten – und entschied sich für den Neustart. Auf dem Weg dorthin:

• wurde die Notwendigkeit eines Wechsels sauber hergeleitet (Support, Wartbarkeit, Performance, Talentmarkt),
• das Timing betriebswirtschaftlich abgesichert (Produktstabilität, Einnahmen, Ressourcen, Feature‑Freeze, Buy‑in),
• die Auswahl systematisch verengt (Anforderungen, Markt, harte Fakten, Gewichtungen),
• das Team einbezogen (Skill‑Erhebung, Präferenzabfrage),
• die Entscheidung datengestützt getroffen (React) und mit einer wichtigen Basistechnologie verknüpft (TypeScript),
• und das Ganze durch Prototypen, Iterationsschleifen und eine lernorientierte Tool‑Kultur abgesichert.

Die anschließende Toolkette – Redux, React Router, Material UI, Luxon, RxJS, Jest + Testing Library, ein eigenes Open‑Source‑Backend‑Kommunikationsmodul, Electron, FullCalendar sowie GitHub Pipelines – entstand nicht am Reißbrett, sondern im schnellen, teamgetriebenen Experimentieren.

Fazit: Entscheidungen, die Bestand haben – weil sie getragen sind

Aus Redaktion‑Sicht bei DevJobs.at ist das Bemerkenswerte an „How to pick the next Front End Framework“ nicht die Nennung eines „Gewinners“, sondern die Konsequenz des Prozesses. Tomi Močnik (TimeTac) zeigt, wie man eine zentrale Technologieentscheidung trifft, ohne in Dogmen, Hypes oder endlose Debatten zu geraten:

• Forschung statt Bauchgefühl,
• harte Daten plus Teamstimme,
• Prototypen statt PowerPoint,
• und die Demut, Kurskorrekturen zuzulassen.

Am Ende steht ein Stack, den das Team trägt, der zum Produkt passt und der genug Beweglichkeit lässt, um sich weiterzuentwickeln. Genau so fühlen sich Technologieentscheidungen an, die länger halten als der nächste Hype‑Zyklus.

Kurz zusammengefasst – die Takeaways für Engineering‑Teams

• Wechselt nicht aus Reflex, sondern aus Notwendigkeit – und nur, wenn Produkt und Organisation den Schritt tragen können.
• Definiert Anforderungen präzise. Komponenten, Doku‑Qualität, Tooling und Kosten gehören früh auf den Tisch.
• Nutzt Trends als Orientierung, aber entscheidet anhand eurer Daten und Prioritäten.
• Messt harte Fakten und bewertet sie mit Gewichtungen in einer nachvollziehbaren Matrix.
• Reduziert früh auf wenige Kandidaten und prüft die Passung zum bestehenden Stack und Wissensstand.
• Holt eure Entwickler aktiv ins Boot – Skill‑Erhebung, Präferenzen, gemeinsames Voten.
• Validiert mit Prototypen und iteriert ohne Eitelkeit.
• Stellt euer Ökosystem schlank und begründet zusammen – von State Management bis CI/CD.
• Pflegt eine Teamkultur, die kontinuierliche, schnelle, kleine Verbesserungen ermöglicht.

So entsteht aus einem Dilemma eine kompetente Entscheidung – und aus der Entscheidung eine Plattform, mit der sich arbeiten lässt: jeden Tag, über Jahre hinweg.

• 

  

  Are you using debugger and why not?

  Borislav Lazendic von TimeTac zeigt in seinem devjobs.at TechTalk die Vorteile von Xdebug und überprüft, ob an den üblichen Vorurteilen zu diesem Thema auch etwas dran ist.

  Jetzt ansehen
• 

  

  TimeTac Connect, How we handle Integrations

  Anna Kastner von TimeTac erzählt in ihrem devjobs.at TechTalk darüber, wie das Devteam an die Challenges von Integrations herangegangen ist.

  Jetzt ansehen
• 

  

  Challenges in mobile application development

  Ludwig Blaikner von TimeTac spricht in seinem devjobs.at TechTalk über den Weg, wie das Team ein Design Proposal zu einer funktionierenden Mobile Software gebaut hat.

  Jetzt ansehen