Jak nadmierna standaryzacja frameworków niszczy innowacje w IT: 3 przypadki

W ciągu ostatnich pięciu lat obserwuję niepokojący trend w polskich firmach technologicznych: fetyszyzację frameworków. React, Vue, Angular, Next.js – stały się nie tylko narzędziami, ale wręcz religiami. Zespoły developerskie wybierają jeden framework i trzymają się go jak przysłowiowej deski ratunku, nawet gdy projekt ewoluuje w kierunku, dla którego to narzędzie nie było projektowane.

Problem nie leży w samych frameworkach – są one genialnymi narzędziami, które znacząco przyspieszają rozwój. Problem zaczyna się w momencie, gdy standaryzacja staje się celem samym w sobie, a nie środkiem do celu. Widzę to w trzech powtarzających się scenariuszach, które kosztują firmy nie tylko pieniądze, ale przede wszystkim – innowacyjność.

1. Framework jako więzienie architektoniczne

Przypadek z rynku: średniej wielkości e-commerce, który w 2018 roku postawił na React z Redux. Przez trzy lata zespół zbudował na tym stacku całą platformę. Gdy w 2022 roku pojawiła się potrzeba wdrożenia rozbudowanej funkcjonalności real-time (chat z konsultantem, aktualizacje stanów magazynowych na żywo), okazało się, że architektura oparta o Redux jest jak próba włożenia kwadratowego klocka w okrągły otwór.

Zespół przez miesiące próbował „na siłę” dopasować rozwiązanie do istniejącego stacku, zamiast rozważyć bardziej odpowiednie narzędzia (np. Socket.io z prostym stanem lokalnym). Efekt? Projekt opóźniony o 4 miesiące, koszty przekroczone o 60%, a finalne rozwiązanie i tak działało z opóźnieniem 2-3 sekund.

Dlaczego to się dzieje? Deweloperzy, którzy spędzili lata specjalizując się w jednym frameworku, często tracą zdolność myślenia architektonicznego w oderwaniu od tego narzędzia. Framework przestaje być środkiem transportu, a staje się celem podróży.

2. Standaryzacja, która zabija eksperymenty

W jednej z warszawskich software house’ów wprowadzono politykę „100% React dla frontendu”. Każdy projekt, niezależnie od specyfiki, musiał być realizowany w React. Początkowo przyniosło to korzyści: łatwe rotacje między projektami, wspólna baza wiedzy, przyspieszone onboardowanie.

Problem ujawnił się przy projekcie dashboardu analitycznego z setkami wykresów aktualizowanych w czasie rzeczywistym. React z Virtual DOM okazał się tu nieoptymalny – każda aktualizacja powodowała kosztowne re-rendery. Prosty eksperyment z Svelte (który kompiluje do vanilla JS) pokazał 40% lepszą wydajność, ale został odrzucony z powodu „odstępstwa od standardu”.

Koszty ukryte: firma nie tylko dostarczyła wolniejszy produkt, ale przede wszystkim straciła szansę na zdobycie kompetencji w nowej technologii. Gdy rok później pojawił się podobny projekt od klienta, musieli go odrzucić – nie mieli doświadczenia w bardziej odpowiednich narzędziach.

3. Kultura „framework first, problem second”

Najbardziej niebezpieczny scenariusz to ten, w którym dyskusja technologiczna zaczyna się od „jak to zrobić w React/Vue/Angular”, zamiast od „jaki problem rozwiązujemy i jakie są jego wymagania”.

Przykład z platformy SaaS do zarządzania projektami: zespół przez 2 miesiące implementował edytor tekstu w React, korzystając z kilku bibliotek i pisząc setki linii kodu do zarządzania stanem. Tymczasem prosty edytor oparty o ContentEditable z vanilla JavaScript i MutationObserver zrobiłby to samo z 10-krotnie mniejszym bundle size i lepszą responsywnością.

Obserwacja z rynku: firmy, które najszybciej adaptują nowe technologie, nie mają jednego świętego frameworku. Mają natomiast kulturę wyboru narzędzi pod problem, a nie problemu pod narzędzia.

Jak znaleźć złoty środek?

Standaryzacja ma ogromne zalety – redukuje koszty szkoleń, ułatwia współpracę między zespołami, pozwala budować wspólne biblioteki komponentów. Ale musi być mądra:

1. Standardy technologiczne, a nie frameworkowe – zamiast „używamy React”, lepiej „używamy komponentowego podejścia z jednokierunkowym przepływem danych”. To pozostawia przestrzeń na zmianę narzędzia, gdy pojawi się lepsze rozwiązanie.

2. 20% czasu na eksperymenty – niektóre firmy (np. Spotify, Netflix) formalnie rezerwują część czasu developerskiego na testowanie nowych technologii. To nie jest czas stracony – to inwestycja w przyszłą elastyczność.

3. Proof of Concept jako obowiązek – dla każdej nowej, znaczącej funkcjonalności warto zrobić PoC w 2-3 różnych technologiach. Często okazuje się, że „standardowy” framework wcale nie jest najlepszym wyborem.

4. Architektura warstwowa – izoluj logikę biznesową od frameworka. Jeśli cała logika jest w Redux/Vuex, zmiana frameworka oznacza przepisanie całej aplikacji. Jeśli logika jest w czystym JavaScripcie/TypeScript, zmiana warstwy prezentacji to tygodnie, a nie miesiące pracy.

Perspektywa biznesowa

Dla founderów i CTO: nadmierna standaryzacja frameworków to ryzyko technologicznego długu, który nie widać w raportach. Zespół może dostarczać funkcje na czas, kod może być czysty, ale za 2-3 lata może się okazać, że:

• Konkurencja używa nowszych, wydajniejszych technologii
• Koszty hostingowe są wyższe (większe bundle size = wyższe zużycie transferu)
• Rekrutacja jest trudniejsza (najlepsi developerzy chcą pracować z nowymi technologiami)
• Innowacje są wolniejsze (każda nowa funkcja musi być „wtłoczona” w istniejący framework)

W JurskiTech.pl przy każdym projekcie zaczynamy od pytania „jaki problem biznesowy rozwiązujemy?”. Dopiero potem wybieramy narzędzia. Czasem to React, czasem Vue, czasem Svelte, a czasem – co może zaskakiwać – vanilla JavaScript z odrobiną Web Components. Bo framework to tylko narzędzie, a celem jest zawsze biznesowy efekt.

Podsumowanie

Standaryzacja w IT jest konieczna, ale musi służyć biznesowi, a nie mu przeszkadzać. Kiedy framework staje się ważniejszy niż problem, który rozwiązuje, tracimy z oczu cel. Najlepsze zespoły developerskie to nie te, które perfekcyjnie znają jeden framework, ale te, które potrafią wybrać najlepsze narzędzie do zadania – i mają odwagę czasem wyjść poza „standard”.

W erze szybko zmieniających się technologii, elastyczność technologiczna staje się konkurencyjną przewagą. I to jest prawdziwy standard, do którego warto dążyć.