Der Lock-in-Effekt bei Frameworks ist die Bindung, die entsteht, wenn eine Anwendung eng auf ein bestimmtes Framework zugeschnitten ist. Je tiefer der Code mit dessen Konventionen verwoben ist, desto teurer wird ein späterer Wechsel.
- Lock-in-Effekt bei Frameworks
Die Abhängigkeit einer Anwendung von einem Framework, die einen Wechsel nur mit einer weitgehenden Neuentwicklung erlaubt.
Beispiel: „Der Lock-in-Effekt bei Frameworks zeigt sich spätestens, wenn das Framework eingestellt wird und die Anwendung weiterlaufen muss.“Verwandt: Vendor Lock-in, die Bindung an einen Anbieter, etwa ein CMS oder eine Plattform.
Woher der Lock-in-Effekt kommt
Ein Framework bestimmt den Aufbau der ganzen Anwendung, von der Ordnerstruktur über die Datenbankzugriffe bis zu den Templates. Code, der so geschrieben ist, läuft nur dort, wo das Framework läuft.
Bei Meta-Frameworks kommt eine zweite Ebene hinzu. Manche Funktionen sind auf die Plattform eines Anbieters zugeschnitten, etwa bei Next.js und Vercel, sodass auch das Hosting gebunden ist.
Wie sich der Lock-in-Effekt zeigt
Selten am Anfang. Er wird sichtbar, wenn sich etwas ändert: Das Framework wird eingestellt, eine neue Hauptversion bricht mit der alten, die Kosten der Plattform steigen, oder es finden sich keine Entwickler mehr.
Dann gibt es oft nur noch die Wahl zwischen teurem Weiterbetrieb und einer Neuentwicklung.
Wie du den Lock-in-Effekt klein hältst
Ganz vermeiden lässt er sich nicht: Wer ein Framework nutzt, bindet sich. Klein bleibt er, wenn die Geschäftslogik in eigenen Klassen liegt, die das Framework nur aufruft, wenn Webstandards Vorrang vor Sonderfunktionen haben und wenn das Framework quelloffen ist und eine große Gemeinde hat.
Bei der Auswahl zählt deshalb weniger, was ein Framework heute kann, als ob es in zehn Jahren noch gepflegt wird. Wird jede neue Aufgabe trotzdem mit einem weiteren Werkzeug aus demselben Umfeld gelöst, spricht man von Frameworkismus.