Vue 3 w małych projektach biznesowych: kiedy warto porzucić Angulara

Brief decyzyjny (pytania, które zwykle padają przy wyborze Vue 3 zamiast Angulara w małej aplikacji biznesowej)

• Czy problemem jest faktycznie Angular, czy raczej przerost architektury i złe granice odpowiedzialności w kodzie?
• Co w praktyce znaczy „mały projekt biznesowy”: jak wygląda UI i gdzie są ryzyka (formularze, uprawnienia, integracje, szybkie zmiany)?
• Czy Vue 3 realnie skróci czas dowozu, czy tylko przeniesie koszty w „ustalanie standardów” i dopinanie ekosystemu?
• Jakie są typowe pułapki migracji z Angulara na Vue (techniczne i organizacyjne) i jak ich uniknąć?
• Kiedy absolutnie nie porzucać Angulara, nawet jeśli zespół narzeka na „ciężar”?
• Czy sensowniejsza jest migracja całości, czy podejście etapowe (strangler pattern, mikrofrontendy, nowe moduły)?
• Jak porównać: formularze, stan (Pinia vs RxJS/NgRx), testy, routing, i18n, UI library – bez marketingu?
• Jak zabezpieczyć jakość w Vue 3, żeby „elastyczność” nie skończyła się spaghetti?

Frazy pomocnicze SEO: Vue 3 vs Angular w biznesie, mały projekt CRUD, migracja z Angulara na Vue, Composition API w praktyce, Pinia czy NgRx, formularze Angular vs Vue, standardy zespołowe Vue, strangler pattern frontend, mikrofrontendy Angular Vue, koszt utrzymania SPA, onboarding developerów, testy jednostkowe i e2e

Sytuacja wyjściowa: „mały projekt biznesowy” to nie rozmiar kodu, tylko typ ryzyk

Praktyczna definicja małej aplikacji biznesowej

„Mały projekt” w firmach rzadko oznacza „prosty”. Najczęściej to aplikacja o ograniczonym zasięgu organizacyjnym (jeden dział, kilka ról użytkowników), ale z intensywną dynamiką zmian. Typowy krajobraz to ekrany CRUD: listy z tabelami, filtry, sortowania, paginacje, szczegóły rekordu, formularze tworzenia/edycji i kilka „workflow” (statusy, akceptacje, komentarze, załączniki).

Do tego dochodzi to, co zwykle boli najbardziej: integracje (API, SSO, eksporty), uprawnienia (role, per‑pole, per‑akcja), audyt zmian, wymagania dostępności albo chociaż sensowny UX pod klawiaturę. W takiej aplikacji ryzyko nie polega na wydajności renderowania, tylko na regresjach, spójności zachowania formularzy i na tym, jak szybko zespół potrafi dopiąć kolejną zmianę „na wczoraj”.

Dlaczego „małość” uwidacznia koszty narzutu frameworka

W dużych produktach narzut Angulara (struktura, DI, testy, konwencje, „enterprise patterns”) potrafi się zwrócić, bo skala wymusza dyscyplinę. W małej aplikacji biznesowej ten narzut częściej jest odczuwalny jako koszt: więcej warstw, więcej plików, więcej konfiguracji, więcej miejsc, w których można zrobić inaczej. Jeśli biznes oczekuje krótkich iteracji, to „ceremonialność” szybko staje się realnym problemem, a nie kwestią gustu.

Jednocześnie Vue 3 kusi szybkością wejścia i mniejszą liczbą decyzji na starcie kodowania ekranów. Pułapka polega na tym, że w Vue brak narzuconych standardów oznacza, że to zespół musi je stworzyć i pilnować. Bez tego łatwo uzyskać sytuację „dowozimy szybko przez miesiąc”, a potem koszt zmian rośnie przez niespójne wzorce.

Dwa scenariusze, które wymagają innego myślenia

• Greenfield: start nowego panelu / admina / małego CRM. Największa dźwignia to czas do pierwszego stabilnego wydania i tempo iteracji.
• Istniejąca aplikacja Angular: „mieli się” rozwój, rośnie frustracja, brakuje przewidywalności zmian. Największa dźwignia to zmniejszenie kosztu utrzymania i ryzyka migracji.

Te same argumenty „Vue 3 jest prostsze” działają inaczej w greenfield, a inaczej w migracji. W migracji liczy się głównie to, czy potrafisz ograniczyć okres podwójnego utrzymania i czy masz plan na spójność UX (walidacja, komponenty, błędy, i18n) w dwóch technologiach naraz.

Pułapka: mylenie „małe” z „nieskomplikowane”

Najczęstszy błąd decyzyjny: uznanie, że skoro aplikacja ma mało ekranów, to będzie łatwa i w każdej technologii wyjdzie podobnie. W praktyce trudność wynika z reguł biznesowych: walidacji warunkowej, uprawnień, stanów pośrednich, zależności między polami i wymagań integracji. Framework może pomóc (przewidywalność i narzucone wzorce) albo przeszkodzić (ceremonialność i wolniejszy dowóz), ale nie zastąpi decyzji domenowych.

1) Jeśli najczęściej walczysz z narzutem i boilerplate’em — sprawdź, czy to Angular, czy architektura projektu

Objaw, który powinien zapalić lampkę

Dodanie prostego modułu „lista → szczegóły → edycja” zajmuje zaskakująco długo. W PR pojawia się dużo plików, dużo „klejenia” warstw, a realna logika biznesowa jest niewielka. Zespół czuje, że większość pracy to „szkielet”, a nie funkcja. To moment, w którym wiele osób mówi: „Angular jest za ciężki”.

To może być prawda, ale równie często to objaw przerośniętej architektury: zbyt wiele abstrakcji (fasady, adaptery, repozytoria na wszystko), brak jasnych granic między UI a domeną i kopiowanie wzorców z dużych systemów do małego panelu.

Gdzie Angular generuje ceremonialność, a gdzie daje realną wartość

Angular ma swoje mocne strony: narzuca strukturę, ma spójny ekosystem, DI ułatwia testowanie i wymusza myślenie o zależnościach. Ale w małych aplikacjach koszt wejścia w „pełny styl Angulara” bywa zbyt wysoki, szczególnie gdy:

• wszystko opiera się o serwisy, fasady i RxJS nawet tam, gdzie wystarczyłby zwykły async/await,
• dochodzi ciężki state management (NgRx) zanim pojawi się realna potrzeba,
• architektura ma więcej warstw niż funkcji biznesowych,
• zespół jest mieszany kompetencyjnie i nie wszyscy czują RxJS.

Vue 3 zwykle pozwala szybciej przejść od API do działającego widoku, bo Composition API i composables umożliwiają pakowanie logiki bez budowania „katedralnych” warstw. Tyle że Vue nie powstrzyma zespołu przed zrobieniem bałaganu, jeśli brakuje zasad.

Przykład: moduł „Zgłoszenia” i różnica w ciężarze implementacji

Wyobraź sobie wewnętrzny panel do obsługi zgłoszeń: tabela z filtrami (status, przypisanie, zakres dat), widok szczegółów, formularz edycji z walidacją i sekcją komentarzy. W Angularze często powstaje zestaw: komponent listy, komponent szczegółów, komponent formularza, serwis API, modele, czasem resolver, czasem fasada, czasem store. To bywa świetne, ale jeśli zespół dodatkowo wdrożył „standard”, że każdy ekran ma osobny moduł, osobną fasadę i osobny zestaw selektorów, to koszt rośnie.

W Vue 3 to samo można zamknąć w mniejszej liczbie plików: widoki + kilka composables (np. useTicketsTable, useTicketForm) + store Pinia dla stanu globalnego (np. auth, preferencje filtrów). To przyspiesza, dopóki zespół pilnuje, co jest „lokalne”, a co „globalne”.

Pułapka: zmiana frameworka jako ucieczka od problemu

Jeśli przyczyną wolnego dowozu jest bałagan domenowy (niejasne wymagania, brak decyzji o modelu danych, ciągłe przepychanki o UX), to migracja do Vue 3 nie pomoże. Co gorsza, może zaszkodzić: dojdzie koszt uczenia się nowego stosu, a chaos organizacyjny zostanie.

Rekomendacja praktyczna

• Wybierz Vue 3, jeśli największym kosztem jest ceremonialność i „narzut na proste ekrany”, a zespół potrafi utrzymać konwencje.
• Zostań w Angularze, jeśli problemem jest architektura i granice odpowiedzialności, a nie sama technologia; zacznij od odchudzenia wzorców.

2) Jeśli onboarding nowych osób trwa za długo — porównaj krzywą wejścia i koszt utrzymania standardów

Objaw: seniorzy są „bramką” dla wszystkiego

Nowa osoba potrafi szybko zrobić UI, ale blokuje się na wzorcach projektu: gdzie trzymać logikę, jak działa stan, jak pisać testy, jak działa walidacja formularzy. W efekcie seniorzy poprawiają PR-y, dopisują brakujące elementy i są wąskim gardłem. To klasyczny problem w małych zespołach utrzymujących 1–3 aplikacje.

Angular: spójność w cenie wiedzy o RxJS i idiomach frameworka

Angular jest przewidywalny: struktura katalogów, DI, lifecycle, routing, formularze, moduły/standalone, CLI. Jeśli ktoś zna Angulara, szybciej „wejdzie” w kod, bo większość projektów wygląda podobnie. Minus: próg wejścia jest realny, szczególnie przez RxJS, architekturę opartą o obserwable i częste wzorce „fasada + serwis + selektory”.

Vue 3: szybkie pierwsze efekty, ale potrzebujesz twardych zasad

Vue 3 pozwala wytłumaczyć nowej osobie podstawy szybciej, a Composition API jest często bardziej intuicyjne dla osób, które myślą „funkcjami” i hookami. Ale w zespole mieszanym pojawia się ryzyko, że każdy pisze inaczej:

• część logiki trafia do komponentu, część do composables,
• stan raz jest w Pinia, raz w ref w widoku,
• API jest wołane w pięciu różnych miejscach różnymi stylami,
• obsługa błędów raz jest globalna, raz lokalna.

Onboarding może być szybki, ale utrzymanie spójności wymaga „ram” równie mocnych jak te, które Angular daje wbudowane.

Pułapka: „Vue jest prostsze”, więc nie potrzebujemy konwencji

To najkrótsza droga do projektu, w którym po pół roku nikt nie wie, gdzie dopisać logikę. Jeśli Vue ma być realną oszczędnością, musisz od początku ustalić: strukturę katalogów, zasady nazewnictwa, granice odpowiedzialności, sposób obsługi API i błędów, standard formularzy, podejście do stanu.

Rekomendacja praktyczna

• Vue 3 ma sens, gdy priorytetem jest szybki dowóz i elastyczność, ale tylko przy jasnych standardach (linter, review checklist, baza komponentów).
• Angular jest bezpieczniejszy, gdy rotacja w zespole jest duża, a chcesz przewidywalności kosztem większego narzutu.

3) Jeśli dominują formularze i walidacja — wybór frameworka ma znaczenie bardziej niż się wydaje

Szybkość implementacji kontra przewidywalność zachowania

W aplikacjach biznesowych formularze są centrum świata: tworzenie/edycja rekordów, zależności między polami, warunkowe wymagania, tryby odczytu, autosave, walidacja asynchroniczna, blokady (np. zależne od roli). Tu różnice Angular vs Vue 3 są bardzo praktyczne.

Angular ma Reactive Forms – spójny model, który wielu zespołom daje poczucie bezpieczeństwa: kontrolki, grupy, walidatory, statusy, obserwacja zmian. Z drugiej strony, w małych projektach bywa to ciężkie, jeśli formularze są „żywe” i UI często się zmienia.

Vue 3 jest elastyczne: możesz budować formularze prosto (v-model + walidacja), albo sięgnąć po biblioteki (np. VeeValidate). Elastyczność jest plusem, dopóki nie okaże się, że każdy ekran waliduje inaczej, a obsługa błędów nie jest spójna.

Przykład: formularz „Oferta” z zależnościami i uprawnieniami

Załóżmy formularz „Oferta”, gdzie sekcje zależą od typu klienta, a część pól jest edytowalna tylko dla wybranych ról. W Angularze często wygrywa przewidywalność: walidatory warunkowe, włączanie/wyłączanie kontrolek, spójna obsługa statusów. Zespół ma „system”, który da się ustandaryzować.

W Vue 3 można to zrobić bardzo ergonomicznie przez komponenty sekcji i composables (np. useOfferPermissions, useOfferValidation), ale trzeba pilnować, aby reguły nie rozlały się po komponentach. Vue daje świetne narzędzia do komponowania, jednak nie narzuca granic.

Pułapka: niedoszacowanie kosztu wspólnego standardu inputów

W Vue 3 szybko zrobisz działający formularz, ale produkcyjna jakość wymaga wspólnej biblioteki pól: input/select/date, obsługa błędów, stany disabled/loading, dostępność, etykiety, i18n, formatowanie. Bez tego każdy widok będzie miał „swój” styl walidacji i komunikatów, co uderza w UX i utrzymanie.

Rekomendacja praktyczna

• Vue 3 wybieraj, jeśli potrzebujesz szybko iterować UI i masz gotowość do zbudowania standardu formularzy (komponenty bazowe + zasady walidacji).
• Angular zostaw, jeśli Reactive Forms jest fundamentem projektu, a spójność formularzy jest kluczowym ryzykiem biznesowym.

4) Jeśli stan aplikacji robi się trudny — oceń, czy potrzebujesz „frameworkowej dyscypliny”, czy lekkiego store

Objaw: dane „przeciekają” między ekranami i nikt nie wie, kto jest właścicielem stanu

W małych projektach stan zwykle zaczyna się niewinnie: trochę filtrów w URL, kilka flag w komponencie, cache listy w serwisie. Po kilku sprintach dochodzą: role i uprawnienia, preferencje użytkownika, koszyki robocze, „ostatnio wybrane”, wersjonowanie formularza, optimistic update i retry. Jeśli w tym momencie nie ma jasnej odpowiedzialności, pojawia się typowy zestaw symptomów: dublowanie requestów, widoki pokazujące „stare” dane, przypadkowe resetowanie filtrów i poprawki w stylu „dodajmy jeszcze jednego watcha”.

Angular: serwisy i RxJS jako domyślny kręgosłup (plus ewentualny store)

Angular daje naturalne miejsce na stan: serwis wstrzyknięty w odpowiedni scope, strumienie z RxJS, cache przez shareReplay, a gdy rośnie złożoność — NgRx/ComponentStore lub inna biblioteka. To jest dyscyplina, która ratuje, gdy w projekcie dużo się dzieje „pomiędzy” ekranami (np. kilka widoków korzysta z tych samych encji i reakcji na zdarzenia). Koszt jest oczywisty: więcej kodu infrastrukturalnego i większa liczba pojęć do utrzymania, zwłaszcza gdy ktoś próbuje wszystko opisać jako „efekty i selektory”, nawet dla prostych przypadków.

Vue 3: Pinia i composables — szybko, dopóki jasno rozdzielasz lokalne vs globalne

W Vue 3 najczęściej wygrywa podejście „composable jako jednostka logiki” + Pinia dla stanu współdzielonego. Jest to lekkie i czytelne, jeśli zespół trzyma proste reguły: stan lokalny zostaje w widoku/komponencie, stan domenowy idzie do store, a logika pobierania i mapowania danych ląduje w jednym miejscu (np. useTickets albo store). Gdy te granice się rozmyją, łatwo o projekt, w którym każdy ekran robi własny fetch, a cache jest „na oko” w trzech różnych miejscach.

Pułapka: „wrzućmy to do globalnego store” jako domyślna odpowiedź

Globalny store kusi, bo rozwiązuje problem „nie wiem, jak przekazać dane”. Tyle że potem dostajesz magazyn wszystkiego: UI state miesza się z domeną, testy stają się bardziej kruche, a refactor jednego widoku dotyka pół aplikacji. Lepsze kryterium jest proste: do store trafia to, co ma wielu konsumentów albo musi przetrwać nawigację; reszta powinna zostać lokalnie i znikać razem z widokiem.

Rekomendacja praktyczna

Jeśli stan zaczyna żyć własnym życiem, najpierw nazwij problem: czy to kwestia cache i synchronizacji, czy raczej brak spójnego modelu domeny. Potem dopiero dobierz narzędzie. Angular zwykle lepiej „trzyma w ryzach” złożone przepływy, Vue 3 zwykle szybciej dowozi, gdy da się utrzymać proste granice i nie ma potrzeby budowania ciężkiej machiny.

5) Jeśli testy są tarczą na regresje — porównaj koszt testowania, nie deklaracje

Objaw: każda zmiana w formularzu psuje coś obok

W małych systemach regresje rzadko wychodzą z „trudnego algorytmu”; częściej z drobnej korekty UI, która rozjeżdża walidację, uprawnienia albo kolejność wywołań API. Wtedy testy mają być amortyzatorem. Problem w tym, że łatwo wpaść w skrajność: albo testów jest tyle, że spowalniają rozwój, albo są symboliczne i nie łapią realnych błędów.

Angular: stabilne środowisko, ale testy komponentów potrafią być ciężkie

Angular ma mocny ekosystem testowania, jednak koszt wejścia w TestBed, mockowanie DI i walka z asynchronicznością RxJS bywają realne. Dla wielu zespołów kończy się to tym, że testuje się głównie serwisy i wybrane krytyczne ścieżki, a resztę „zostawia e2e”. To może działać, ale pod warunkiem, że logika biznesowa faktycznie siedzi w warstwach, które łatwo przetestować bez renderowania połowy aplikacji.

Vue 3: szybkie testy jednostek UI, ale łatwo testować „nie to, co trzeba”

W Vue 3 testy komponentów potrafią być lżejsze (Vue Test Utils + Vitest), bo nie ma ciężkiego kontenera DI. Zyskujesz na szybkości pisania i uruchamiania testów, szczególnie gdy większość logiki wyciągniesz do composables. Minusy pojawiają się gdzie indziej: jeśli logika jest porozrzucana po komponentach, testy robią się powierzchowne (sprawdzasz, czy „coś się wyrenderowało”), a regresje i tak przechodzą.

Praktyczny kontrast:

• Angular premiuje testowanie warstw (serwisy/pipe/guard) i integrację przez DI, ale komponenty bywają kosztowne w setupie.
• Vue 3 premiuje testowanie małych jednostek (composables, store, komponenty) — o ile konsekwentnie trzymasz logikę poza template’em.

Przykład: uprawnienia i blokady akcji

Klasyczna sytuacja z panelu admin: przycisk „Zatwierdź” ma być widoczny tylko dla roli, aktywny tylko gdy formularz jest poprawny i nie ma konfliktu wersji, a po kliknięciu ma zablokować UI do czasu odpowiedzi API. Jeśli testujesz tylko renderowanie przycisku, przegapisz regresje typu: przycisk jest aktywny, gdy API zwraca błąd 409, albo blokada nie schodzi po błędzie.

Lepsze podejście w obu światach jest podobne: wyodrębnij reguły do jednej funkcji/warstwy i testuj je bez UI:

• w Angularze: serwis typu PermissionService + testy dla reguł i guardów,
• w Vue 3: composable usePermissions / useApprovalRules + testy jednostkowe.

Pułapka: mylenie „łatwo napisać test” z „łatwo utrzymać pokrycie ryzyk”

Gdy migracja na Vue 3 ma uzasadniać się „bo testy będą prostsze”, często kończy się to zestawem testów snapshot i kilku klików w e2e. A ryzyka biznesowe zwykle siedzą w: walidacji warunkowej, uprawnieniach, obsłudze błędów i edge-case’ach synchronizacji. To jest niezależne od frameworka; różni się tylko ergonomia.

Rekomendacja praktyczna

• Jeśli logika biznesowa jest już dobrze wydzielona w Angularze (serwisy/fasady), zmiana frameworka nie da magicznie lepszych testów — poprawę da raczej porządny „design for testability”.
• Jeśli w Angularze testy UI są barierą i przez to nie testujesz krytycznych ścieżek, Vue 3 może pomóc, ale tylko jeśli ustalisz zasadę: logika w composables/store, komponent jako cienka powłoka.

6) Jeśli „porzucenie Angulara” ma być oszczędnością — policz koszt migracji w ryzykach, nie w liniach kodu

Dwie migracje, które ludzie wrzucają do jednego worka

„Przepiszemy na Vue 3” brzmi jak jeden projekt, a w praktyce są co najmniej dwa scenariusze:

• replatforming — zmieniasz framework, ale funkcjonalnie aplikacja ma pozostać bardzo podobna,
• rewrite z refaktorem — przy okazji zmieniasz model domeny, API, role, układ ekranów, czasem nawet proces biznesowy.

Drugi wariant jest kuszący („wreszcie zrobimy to porządnie”), ale to już nie jest tylko wybór Angular vs Vue 3. To zmiana produktu, a ryzyko rośnie wykładniczo.

Checklista kosztów, które zwykle wychodzą po fakcie

W małych projektach migracja potrafi „zjeść” czas nie przez komponenty, tylko przez elementy infrastruktury i brzegowe zachowania:

• autoryzacja i sesja: odświeżanie tokenu, retry, obsługa 401/403 i przekierowania,
• routing i stany URL: filtry, paginacja, deep-linking do zakładek,
• formularze: spójna walidacja, mapowanie błędów z API, formaty dat i liczb,
• i18n: pluralizacja, formatowanie, dynamiczne klucze w komponentach bazowych,
• telemetria: logowanie błędów, śledzenie zdarzeń (a nie tylko „console”),
• testy i pipeline: odtworzenie pokrycia krytycznych ścieżek,
• UI kit: odtworzenie zachowań, a nie tylko wyglądu (focus, a11y, disabled/loading, klawiatura).

Pułapka: „zrobimy migrację ekran po ekranie” bez strategii współistnienia

Najbardziej ryzykowny moment to etap pośredni, gdy masz dwa światy naraz. Bez jasnej strategii łatwo o:

• dwa sposoby obsługi błędów i dwa „toast systemy”,
• podwójne modele typów (np. DTO w dwóch folderach),
• różne reguły nawigacji i brak spójnego UX,
• problemy z autoryzacją i cache (jeden klient API robi retry, drugi nie).

Rekomendacja praktyczna

• Jeśli masz działającą aplikację i boli głównie tempo dowozu, częściej wygrywa podejście etapowe: nowe moduły w Vue 3 (albo mikrofrontend), stary rdzeń w Angularze, wspólne API/kontrakt i wspólny system błędów.
• Pełny rewrite ma sens, gdy i tak musisz ruszyć fundamenty (np. rozjechane API, brak kompatybilności z nowym procesem biznesowym) — wtedy zmiana frameworka jest „przy okazji”, nie jedynym celem.

7) Jeśli rozważasz podejście hybrydowe — zadbaj o granice: wspólne kontrakty, wspólny runtime, osobne UI

Hybryda działa, gdy integrujesz na poziomie „aplikacji”, nie komponentów

Najmniej bolesny wariant to taki, w którym Angular i Vue 3 spotykają się na poziomie nawigacji (moduł/obszar), a nie w środku komponentów. Innymi słowy: użytkownik przechodzi do sekcji „Zamówienia” i tam działa Vue, a „Ustawienia” dalej są w Angularze. Próby osadzania jednego komponentu w drugim zwykle kończą się problemami ze stylem, focus management i utrzymaniem.

Minimalny zestaw „wspólnego kręgosłupa”

Żeby hybryda nie zamieniła się w dwa różne produkty, potrzebujesz wspólnych zasad tam, gdzie użytkownik i tak oczekuje spójności:

• kontrakt API: typy/DTO generowane lub trzymane w jednym miejscu (monorepo albo paczka),
• uwierzytelnianie: jeden klient HTTP, jedna obsługa refresh/retry,
• obsługa błędów: wspólna konwencja mapowania błędów z backendu na komunikaty UI,
• design system: przynajmniej podstawowe komponenty i tokeny (kolory, spacing, typografia), nawet jeśli implementacje są osobne.

Pułapka: wspólny UI kit jako pierwszy krok

Często pierwszym odruchem jest „zbudujmy wspólną bibliotekę komponentów dla Angulara i Vue”. To bywa najdroższy sposób na start, bo różnią się modele komponentów, walidacja formularzy i integracje. Łatwiej zacząć od wspólnych tokenów (CSS variables), ikon i zasad UX, a dopiero potem — jeśli ma to biznesowy sens — iść w komponenty.

Rekomendacja praktyczna

• Hybryda jest sensowna, gdy chcesz zmniejszyć ryzyko i rozłożyć koszt w czasie, ale musisz zaplanować granice: gdzie kończy się Angular, gdzie zaczyna Vue, co jest wspólne, a co nie.
• Jeśli nie masz możliwości utrzymać wspólnych kontraktów (typy, auth, błędy), lepiej odpuścić hybrydę — chaos operacyjny zje oszczędności z „lżejszego frameworka”.

8) Jeśli Angular „przeszkadza”, sprawdź, czy problemem nie jest wersjonowanie i dług technologiczny

To, co boli w Angularze, często nie jest „o Angularze”

W małych systemach najczęściej przeszkadza nie sam framework, tylko miks: stara wersja Angulara, zależności bez opiekuna, ręcznie klejone interceptory, brak spójnego podejścia do RxJS i nieaktualne schematy modułów. Wtedy łatwo dojść do wniosku, że „Vue będzie prostsze”. Może będzie — ale równie dobrze wystarczy doprowadzić Angulara do sensownego stanu.

Sygnały, że najpierw opłaca się „naprawić”, a dopiero potem decydować

• większość bólu to build, konflikty zależności, trudne aktualizacje,
• architektura ma „legacy patterns” (np. wszystko w jednym module, brak warstwy API, subskrypcje bez sprzątania),
• problemem są konwencje (każdy robi inaczej), a nie narzut frameworka.

Jeśli to jest rdzeń problemu, porzucenie Angulara może tylko przenieść chaos do Vue 3 — szybciej się pisze, ale równie szybko robi się nieczytelnie.

Pułapka: migracja jako sposób na „reset” bez decyzji architektonicznych

Framework nie zastąpi odpowiedzi na pytania: jak modelujesz domenę, gdzie jest logika, jak wygląda klient API, jak obsługujesz błędy, jak definiujesz uprawnienia. Jeśli te decyzje nie zapadną, Vue 3 nie będzie oszczędnością — będzie nowym miejscem na stare problemy.

Rekomendacja praktyczna

• Gdy ból wynika z długu i wersji, najtańsza ścieżka to często: upgrade + uproszczenie architektury + ujednolicenie konwencji.
• Gdy ból wynika z narzutu procesu i boilerplate’u w małym zespole, Vue 3 może realnie skrócić czas dowozu — ale tylko przy świadomie zaprojektowanych „ramach”, żeby nie utracić spójności.

9) Jeśli zespół jest mały — w Vue 3 narzuć „minimalne ramy”, bo inaczej wygrasz szybkość tylko na starcie

Vue daje wolność; biznes potrzebuje przewidywalności

Angular zwykle wymusza styl (moduły, DI, konwencje), co bywa uciążliwe, ale stabilizuje kod w dłuższym czasie. Vue 3 (zwłaszcza z Composition API) jest elastyczne: można pisać bardzo czysto albo bardzo chaotycznie — i oba podejścia są „poprawne”. W małym projekcie biznesowym ta różnica wychodzi po 2–3 sprintach, gdy rośnie liczba formularzy, integracji i wyjątków.

Minimalny zestaw zasad, które robią różnicę

Żeby nie zbudować „spaghetti w Vue”, wystarczą proste reguły, które zastępują część frameworkowej dyscypliny Angulara:

• TypeScript jako standard: DTO i modele domeny w jednym miejscu, bez „any” w krytycznych ścieżkach (auth, płatności, uprawnienia).
• komponent jako powłoka: logika w composables i store, komponent ma składać UI i mapować zdarzenia.
• jedna warstwa API: np. apiClient + funkcje per-obszar (ordersApi), bez losowych fetch w komponentach.
• jedna konwencja błędów: ten sam format dla „field errors” i „global errors”, niezależnie od ekranu.
• jeden sposób na formularze: jedna biblioteka/abstrakcja, jeden styl walidacji i mapowania błędów z backendu.

Pułapka: „w Angularze było dużo plików, w Vue zrobimy wszystko w jednym”

To częsty odruch po cięższym stacku: scalić pliki, uprościć foldery, „mniej ceremonii”. Efekt uboczny: brak granic odpowiedzialności. W panelach B2B problemem nie jest liczba plików, tylko to, czy da się znaleźć reguły (uprawnienia, walidacja, mapowanie statusów) bez przekopywania komponentów.

Rekomendacja praktyczna

• Jeśli idziesz w Vue 3, ustal katalog „domain” (reguły biznesowe) i katalog „ui” (komponenty) jako twardą granicę. To zastępuje część „prowadzenia” Angulara.
• Jeśli nie masz czasu na konwencje i przeglądy PR, Angular paradoksalnie bywa bezpieczniejszy: wolniej, ale trudniej zejść na manowce.

10) Jeśli kluczowe są formularze i tabele — porównaj ergonomię narzędzi, nie „framework” jako taki

W biznesowych UI to formularze robią koszt, a nie routing

W małych CRM-ach i panelach administracyjnych największe tarcie siedzi w powtarzalnych rzeczach: walidacje warunkowe, pola zależne, edycja tabel, filtrowanie, tryb „create vs edit”, autosave, optymistyczne aktualizacje. Angular ma mocne, dojrzałe podejście do formularzy, ale czasem wymaga więcej kodu. Vue 3 daje szybsze prototypowanie, tylko trzeba świadomie dobrać narzędzia.

Przykład porównania: walidacja warunkowa i błędy z API

Załóżmy ekran „Edycja kontrahenta”: NIP wymagany tylko dla firm, numer VAT zależny od kraju, backend zwraca błędy per-pole.

• Angular: reactive forms + custom validators + jeden „adapter” mapujący błędy API na setErrors. Plus: spójny mechanizm stanu pól. Minus: więcej boilerplate’u i „plumbing”.
• Vue 3: typowo composable useContractorForm + biblioteka walidacji (albo własne reguły) + jedno miejsce mapowania błędów na strukturę formularza. Plus: szybciej wydzielić logikę. Minus: bez konwencji łatwo powielić logikę w wielu ekranach.

Pułapka: wybór UI library jako decyzja „na szybko”

W małych projektach często „bierzemy UI kit, żeby było szybciej”. A potem wychodzi, że najwięcej czasu idzie na dopasowanie zachowań: focus, klawiatura, rozbudowane tabele, edycja inline, wirtualizacja, a11y, integracja z walidacją. Framework jest wtedy mniej istotny niż to, czy biblioteka UI i formularze współpracują bez walki.

Rekomendacja praktyczna

• Jeśli aplikacja to głównie formularze z dużą liczbą reguł, nie przepisuj „na wiarę”. Zrób jeden ekran pilotażowy w Vue 3 i oceń: walidacja, błędy z API, wydzielanie logiki, testy.
• Jeśli masz w Angularze dobrze ogarnięte form base components i wspólną obsługę błędów, zmiana frameworka rzadko daje duży zwrot — większy daje uporządkowanie wzorców i redukcja duplikacji.

11) Jeśli myślisz o rekrutacji i utrzymaniu — porównaj dostępność kompetencji do rodzaju projektu, nie do „popularności”

Angular i Vue 3 przyciągają inne profile pracy

Wewnętrzne narzędzia biznesowe premiują konsekwencję, stabilny rytm dowozu i przewidywalne utrzymanie. Angular bywa naturalnym wyborem dla zespołów, które lubią „ustawione tory” i architekturę z domyślnymi wzorcami. Vue 3 jest częściej wybierane tam, gdzie liczy się szybkość iteracji i łatwe dokładanie ekranów — ale wymaga pilnowania standardów.

Pułapka: „przejdziemy na Vue, bo łatwiej znaleźć ludzi”

To argument, który działa tylko wtedy, gdy projekt rzeczywiście pasuje do profilu pracy. Jeśli masz ciężką domenę (uprawnienia, audyt, reguły zatwierdzania, nietrywialne stany), sama zmiana frameworka nie ułatwia wdrożenia nowej osoby. Często ważniejsze są: dokumentacja decyzji, spójny model domeny i zestandaryzowane wzorce obsługi błędów.

Rekomendacja praktyczna

• Jeśli utrzymujesz 1–3 aplikacje i rotacja ludzi jest realnym ryzykiem, wybierz stack, który minimalizuje liczbę „lokalnych wynalazków”. Angular robi to systemowo; Vue 3 wymaga świadomego narzucenia ram.
• Jeśli budujesz nowy produkt i zależy Ci na szybkim „time-to-first-value”, Vue 3 często ułatwia start — ale zaplanuj dzień na dopięcie standardów (lint, struktura folderów, store, API layer), zanim zrobi się tłoczno.

12) Jeśli masz wątpliwości — wybierz ścieżkę decyzyjną: zostać w Angularze, przejść na Vue 3, czy zbudować most

Trzy sensowne decyzje i ich konsekwencje

• Zostać w Angularze — gdy aplikacja ma już ułożoną architekturę, testy chronią krytyczne ścieżki, a ból wynika głównie z długu, wersji lub „legacy patterns”. Tutaj wygrywa upgrade i porządki, nie rewrite.
• Wejść w Vue 3 w nowym obszarze — gdy problemem jest narzut w małym zespole, tempo dowozu spada na prostych modułach, a domena pozwala na wyraźne granice (np. osobny obszar „Raporty” albo „Katalog”). To daje szybką weryfikację bez ryzyka totalnej migracji.
• Pełna migracja — gdy i tak musisz ruszyć fundamenty produktu (API, procesy, role) i „przepisanie” jest elementem większej zmiany. Wtedy wybór Vue 3 vs Angular to część nowego projektu, a nie próba oszczędności na utrzymaniu starego.

Pułapka: decyzja oparta na „uczuciu ciężkości”

„Angular jest ciężki” często oznacza: mamy bałagan w kodzie, zależnościach i konwencjach, a każda zmiana dotyka zbyt wielu miejsc. W Vue 3 da się to chwilowo ukryć, bo łatwiej dodać nowy ekran bez ułożenia fundamentów. Po kilku miesiącach wraca to samo, tylko z innymi nazwami plików.

Rekomendacja praktyczna

• Jeśli nie masz pewności, zacznij od modułu o średniej złożoności jako „pilot” w Vue 3: ma routing, formularz, listę z filtrami, uprawnienia i obsługę błędów. Po takim pilocie widać, czy oszczędność jest realna.
• Jeśli pilot wyjdzie dobrze, dopiero wtedy planuj skalowanie: design tokens, wspólne kontrakty, jedna warstwa API, zasady testowania. Bez tego Vue 3 jest szybkim startem, ale drogim utrzymaniem.

13) Jeśli zależysz od spójnych uprawnień i audytu — sprawdź, czy Vue 3 nie wymaga od Ciebie „dopisania Angulara” od zera

W panelach B2B „role i reguły” są cichym kosztotwórcą

CRUD da się zrobić w każdym frameworku. Problem zaczyna się, gdy do jednego widoku dochodzą: role, zakresy danych (np. tylko własny oddział), wyjątki (np. super-user), warunki na polach (np. możliwość edycji tylko do momentu akceptacji) i ślad audytowy. Angular w naturalny sposób prowadzi do centralizacji tych reguł (guardy, interceptory, DI, często wspólne serwisy). W Vue 3 też to zrobisz — tylko musisz świadomie zaplanować „jedno źródło prawdy”.

Przykład: jedna zasada, trzy miejsca, trzy różne interpretacje

Reguła: „Status Approved blokuje edycję pól finansowych, ale pozwala dodać załącznik”. Bez ustaleń w Vue 3 łatwo skończyć z:

• warunkiem w komponencie formularza (:disabled),
• warunkiem w store (blokada akcji),
• warunkiem w warstwie API (odrzucenie requestu po stronie klienta).

Każde miejsce jest „logiczne”, ale po kwartale różnice w szczegółach robią regresje. Angular częściej wymusza myślenie w kategoriach warstw i usług. W Vue 3 warto skopiować tę dyscyplinę: reguły domenowe w jednym module (np. domain/permissions albo domain/policy), a UI tylko pyta o decyzję.

Pułapka: guardy i middleware jako „zamiast modelu uprawnień”

Łatwo przesadzić w drugą stronę: zrobić wszystko w routerze (przekierowania, blokady, fallbacki) i uznać temat za zamknięty. W praktyce router rozwiązuje tylko wejście na ekran, a nie logikę wewnątrz ekranu (np. częściowa edycja, ukrywanie przycisków, read-only fragmenty). Jeśli masz dużo przypadków „może wejść, ale nie może kliknąć”, potrzebujesz warstwy policy/permissions niezależnej od routingu.

Rekomendacja praktyczna

• Ustal jedno API na decyzje uprawnień: np. canEditInvoice(user, invoice), canApprove(user, invoice). Nie rozrzucaj warunków po komponentach.
• Jeśli projekt ma audyt i compliance (kto, co, kiedy), zostaw w kodzie „ślady decyzji”: nazwy funkcji, enumy statusów, typy zdarzeń. Vue 3 tego nie daje „z pudełka”, ale TypeScript i porządny model domeny robią robotę.

14) Jeśli masz dużo integracji i „niespodzianek” w API — porównaj podejście do efektów ubocznych (RxJS vs composables)

W małych systemach najwięcej psuje się na granicy z backendem

Timeouty, retry, kolejkowanie żądań, anulowanie poprzednich wyszukiwań, synchronizacja filtrów z URL, cache listy podczas edycji — to nie jest „duży system”, to standard w wewnętrznych narzędziach. Angular często kończy z RxJS jako językiem opisu tych przepływów. Vue 3 częściej idzie w prostsze asynchroniczne funkcje i reaktywność, a bardziej skomplikowane scenariusze rozwiązuje się biblioteką od query/caching albo własnymi composables.

Przykład: wyszukiwarka z debounce i anulowaniem

• Angular: valueChanges.pipe(debounceTime(...), switchMap(...)) daje czytelny schemat, a anulowanie dzieje się „przy okazji” operatora.
• Vue 3: możesz zrobić watch + własny debounce, albo użyć biblioteki do zapytań (cache, statusy, retry). Zyskujesz prostotę w prostych przypadkach, ale musisz pilnować spójnych wzorców.

Pułapka: „w Vue nie potrzebujemy RxJS” jako zasada ogólna

To działa do momentu, gdy wchodzą złożone zależności między zdarzeniami: live search + paginacja + filtr + synchronizacja z URL + równoległe requesty. Wtedy albo wraca RxJS, albo powstaje mini-framework z watch i flagami. Obie opcje są OK, ale warto wybrać świadomie: RxJS to większa krzywa wejścia, za to bardzo mocne narzędzie do przepływów.

Rekomendacja praktyczna

• Jeśli w Angularze masz już dojrzałe wzorce RxJS (np. fasady, selektory, spójne zarządzanie subskrypcjami), migracja do „gołego async/await” w Vue 3 potrafi być krokiem wstecz.
• Jeśli zespół i tak unika RxJS (a logika przepływów jest prosta), Vue 3 + composables daje mniej tarcia. Warunek: jeden standard obsługi requestów (statusy, anulowanie, błędy) w całej aplikacji.

15) Jeśli zależy Ci na jakości i regresjach — porównaj, jak realnie pisze się testy w Twoim typie UI

Testy są praktyczne dopiero, gdy są szybkie i przewidywalne

W małych projektach biznesowych rzadko wygrywa „perfekcyjne pokrycie”. Wygrywa zestaw testów, które łatwo dopisać do nowego ekranu i które nie rozsypują się przy refaktorze UI. Angular ma długą tradycję podejścia testowego (w tym dependency injection i mockowanie), ale testy komponentów potrafią być cięższe w konfiguracji. Vue 3 ma prostszy model komponentu i często szybciej stawia się testy jednostkowe composables — o ile logika faktycznie jest wyniesiona z komponentów.

Przykład: „zapisz i pokaż błąd globalny”

• Angular: test serwisu/fasady (mock HttpClient) + test komponentu, czy reaguje na stan. Plus: DI ułatwia podmiany. Minus: łatwo wpaść w testy zbyt szczegółowe na strukturę DOM.
• Vue 3: test composable (mock apiClient) + cienki test komponentu, czy renderuje errorBanner. Plus: mniej infrastruktury. Minus: jeśli logika zostanie w komponencie „bo szybciej”, testy szybko robią się kruche.

Pułapka: „Vue będzie szybsze, więc testy mniej potrzebne”

Przy szybkim dowozie rośnie ryzyko długoterminowe: regresje w uprawnieniach, walidacjach i statusach. Vue 3 rzeczywiście potrafi przyspieszyć, ale tylko wtedy, gdy testy i konwencje trzymają tempo zmian. Bez nich koszt wraca jako „QA ping-pong” i poprawki po wdrożeniu.

Rekomendacja praktyczna

• Ustal minimalny zestaw testów per-ekran: np. walidacja krytycznych pól, mapowanie błędów z API, uprawnienia do akcji, jeden „happy path”. Resztę zostaw E2E lub testom integracyjnym.
• Jeśli przechodzisz na Vue 3, zadbaj o testowalność przez architekturę: logika w composables/store, a komponenty jako „klej”. Wtedy testy są krótsze i mniej zależne od UI library.

16) Jeśli planujesz migrację etapową — dobierz strategię tak, żeby nie utknąć w „dwóch światach”

Most bywa tańszy niż rewrite, ale potrafi zostać na lata

Etapowe przejście ma sens, gdy możesz odseparować obszar biznesowy i utrzymać spójne kontrakty (routing, auth, API). Problem zaczyna się, gdy powstają dwa zestawy wzorców: inne podejście do formularzy, inne do stanu, inne do błędów. Wtedy koszt „integracji między frameworkami” zjada zysk z migracji.

Trzy podejścia, które zwykle mają sens

• Nowa aplikacja (shell) + stopniowe przepinanie funkcji: Vue 3 jako host, stare ekrany w Angularze jako osadzone moduły przez iframe/remote lub podobny mechanizm. Dobre, gdy chcesz nowe UX i nowy routing, a stare moduły mają żyć jakiś czas.
• Mikrofrontendy: osobne deploymenty i wyraźne granice domeny. Dobre, gdy organizacja i procesy to udźwigną. Ryzyko: więcej DevOps i integracji.
• Przepisanie obszaru „po obszarze” w tym samym produkcie: najszybsze organizacyjnie, ale najłatwiej o chaos, jeśli nie zablokujesz „mieszania stylów” w jednym flow.

Pułapka: współdzielone komponenty UI między Angular i Vue

Brzmi kusząco: „zróbmy jeden design system i użyjmy w obu”. W praktyce adaptery, różnice w cyklu życia i obsłudze formularzy potrafią zjeść czas. Zwykle lepiej współdzielić:

• design tokens (kolory, spacing, typografia),
• kontrakty API i typy DTO,
• zasady błędów i walidacji (format),
• logikę domenową niezależną od UI (jeśli da się ją wynieść).

Rekomendacja praktyczna

• Jeśli robisz etapową migrację, ustal „granice odpowiedzialności”: który framework odpowiada za auth, routing, telemetry, obsługę błędów globalnych. Dwie równoległe implementacje tego samego to przepis na dryf.
• Zanim przepiszesz drugi moduł, dopnij standardy w Vue 3: struktura folderów, API layer, obsługa formularzy, store. Pierwszy moduł zwykle „wychodzi”, drugi ujawnia brak konwencji.

17) Jeśli nadal wahasz się między Angular a Vue 3 — użyj krótkiej listy decyzji zamiast „feelingu”

Kryteria, które faktycznie różnicują ryzyko

• Zostań w Angularze, gdy domena jest ciężka (uprawnienia, audyt, wieloetapowe procesy), zespół ceni narzucone wzorce, a problemem jest dług i brak porządków, nie sam framework.
• Wybierz Vue 3, gdy zespół jest mały, iteracje są szybkie, UI to głównie formularze i listy, a największy ból to boilerplate i tempo dostarczania prostych zmian — przy gotowości do narzucenia konwencji.
• Zrób podejście hybrydowe, gdy chcesz potwierdzić zysk na realnym module, a ryzyko przepisania całości jest biznesowo nie do przyjęcia. Warunek: twarde granice i wspólne kontrakty, inaczej utkniesz w „dwóch światach”.

Pułapka: mylenie problemu technologii z problemem procesu

Jeśli release boli, bo brak code review, brak konwencji i brak testów krytycznych ścieżek, to zmiana frameworka nie naprawi tempa — tylko zmieni miejsce, w którym pojawia się chaos. Vue 3 szybciej ujawnia potrzebę standardów. Angular wolniej pozwala na improwizację, ale też nie zastąpi dyscypliny zespołu.

Najważniejsze wnioski

• „Mały projekt biznesowy” to zwykle CRUD z dużym ryzykiem regresji (formularze, uprawnienia, integracje, szybkie zmiany), a nie „mało kodu” — kluczowe jest tempo iteracji i przewidywalność zachowania UI.
• Jeśli prosta ścieżka „lista → szczegóły → edycja” generuje dziesiątki plików i warstw, problemem bywa nie sam Angular, tylko przerośnięta architektura (fasady/adaptory/repozytoria na wszystko, nieczytelne granice UI–domena).
• Narzut Angulara (DI, konwencje, testowalność, spójny ekosystem) potrafi się zwrócić przy dużej skali, ale w małych aplikacjach często zamienia się w ceremonialność: RxJS tam, gdzie wystarczy async/await, albo NgRx zanim pojawi się realna potrzeba.
• Vue 3 zazwyczaj skraca drogę od API do działającego widoku — Composition API i composables pozwalają pakować logikę bez „katedralnych” warstw — ale koszt przenosi się na zespół: trzeba samemu ustalić i egzekwować standardy.
• Brak narzuconych wzorców w Vue jest pułapką: przez chwilę dowozi się szybciej, a potem rośnie koszt zmian przez niespójne podejścia (np. trzy różne sposoby walidacji formularzy i obsługi błędów).
• Argumenty za Vue 3 działają inaczej w greenfield niż w migracji: nowy panel/admin liczy „czas do stabilnego pierwszego wydania”, a przy istniejącym Angularze ważniejsze jest ograniczenie podwójnego utrzymania i spójność UX w dwóch technologiach (walidacja, komponenty, i18n).