• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Angular czy React w 2026 roku??

Mały hosting, OGROMNE możliwości
+1 głos
622 wizyt
pytanie zadane 1 marca w Inne języki przez Edd Obywatel (1,400 p.)
edycja 1 marca przez Edd

Angular czy React w 2026 roku?? Co jest Waszym wyborem, co lepiej się sprawdza?

Interesuje mnie też rynek pracy!

Generalnie: React jest najpopularniejszy w średnich i małych projektach. Angular w korpo - a więc tych dużych i największych projetkach. Ale to generalnie, bo wiadomo, że od wszystkiego są wyjątki.

Gdyby nie rynek pracy, to oczywiście są ciekawsze rozwiązania, jak Vue (+ Nuxt) czy polecany przez @WojAbuk - funkcyjny Elm. Także Svelte i SvelteKit.

Czytałem, że Vue jest szybszy od Reacta i sporo szybszy od Angular jeśli chodzi o start, pokazanie się pierwszej strony w przeglądarce.

Ogólnie, chciałbym zawęzić poszukiwania do Angular i React, mimo, że doskonale wiem, że są ciekawsze biblioteki czy frameworki.

5 odpowiedzi

+4 głosów
odpowiedź 1 marca przez Comandeer Guru (607,960 p.)
wybrane 1 marca przez Edd
 
Najlepsza
Why not both? W 2026 roku coraz częściej używa się AI do wspomagania developmentu i – bez względu na to, jakie się ma do tego podejście – framework ma coraz mniejsze znaczenie. O wiele ważniejsze są umiejętności projektowania architektury i rozwiązywania konkretnych problemów biznesowych, a sam framework (czy nawet szerzej: kod) staje się szczegółem implementacyjnym.

Jeśli ma się dobre umiejętności z nazywania problemów, ich dokładnego definiowania (a więc z podstaw inżynierii oprogramowania), to kwestia wyboru frameworku sprowadza się do przeczytania dokumentacji i naklepania prostej apki, żeby poznać mindset. Albo po prostu zmiany jednego słowa w prompcie, jeśli chcemy używać AI.
komentarz 1 marca przez Edd Obywatel (1,400 p.)
Masz rację, ale (chyba) połowicznie :)  Poprawcie mnie jeśli się mylę.....

AI napisze kod front-endu w dowolnym frameworku, ale nie wystarczy do robienia frontu znać tylko nazw framework-ów  :)  (nazwy mam już opanowane, ale wewnętrznie czuję, że to za mało :D ).

Oczywiście AI generuje coraz lepszej jakości kod, ale boję się, że może mieć:

- sporo błędów różnego typu

- luki bezpieczeństwa

- kod niezgodny z wzorcami, dobrymi praktykami, etc.

Appka frontu może działać (od strony funkcjonalniej) po kilku poprawkach, ale może przy tej okazji być niedopracowana na całej szerokości :) Nie mam racji?
komentarz 1 marca przez Comandeer Guru (607,960 p.)
Jasne, AI działa najlepiej, gdy się wie, co się robi. Niemniej jeśli zna się zasady działania platformy sieciowej i ma myślenie architektoniczne, zna podstawy inżynierii oprogramowania itd., to można w miarę sensownie określić, czy dany kod robi to, co ma robić, i czy jest zadowalającej jakości.

Wszystko też zależy od tego, jaka jakość Ci jest potrzebna. Jeśli to ma być utrzymywane przez długi czas, to tak, wypada mieć większe pojęcie o danym frameworku niż tylko jego nazwa. Ale jeśli to np. landing page lub szybki prototyp, które mają po prostu działać, to nazwa może być wystarczająca.
komentarz 1 marca przez Edd Obywatel (1,400 p.)

Do jakich czasów dożyliśmy :D :D Wystarczy nie być analfabetą i można "trzaskać"  projekty IT ;)  Po tym co napisałeś to AI puści z torbami chyba wszystkich :) 

 

Może masz rację, spróbuję obydwu framework-ów z pomocą AI i podszkolę się mocniej w tym, który mi się bardziej spodoba.

komentarz 7 marca przez cadbit Nowicjusz (120 p.)

@Comandeer, 
dodam od siebie dwa różne podejścia do "kodowania z AI":
- spec coding
- vibe coding

Pierwszy tak jak pisze @Comandeer musisz wiedzieć co chcesz zrobić i wiedzieć jak rozwiązać problem + projektowania architektury + testy itp. (w podejściu backendowym)
Drugi to proste wykorzystanie AI na zasadzie: napisz mi aplikację która robi to i to, ma wyglądać tak i tak.

Dodam że znaczenie ma wielość konteksu i ilość iteracji.

Nie bójmy korzystać się z narzędzi, tylko róbmy to świadomie i z odpowiednią wiedzą.

+3 głosów
odpowiedź 2 marca przez marcin99b Szeryf (86,140 p.)

No to zależy co chce się robić i jaki ma się styl pracy

React jest najpopularniejszy w średnich i małych projektach. Angular w korpo - a więc tych dużych i największych projetkach. Ale to generalnie, bo wiadomo, że od wszystkiego są wyjątki.

Czytałem, że Vue jest szybszy od Reacta i sporo szybszy od Angular jeśli chodzi o start, pokazanie się pierwszej strony w przeglądarce. 

Jeśli patrzysz pod kątem własnego projektu, to szybkość ma znaczenie. Jeśli patrzysz pod kątem robienia projektów dla innych, to już ta szybkość jest kosztem kogoś innego, kto ją wybrał strategicznie.

Osobiście wole reacta, bo pracuje głównie w backendzie, teoretycznie jestem fullstackiem i czasami zaglądam do frontu, ale rzadko i mało, więc wolę coś co jest proste i intuicyjne. Angular mi się nie podobał bo z tego co pamiętam, wymagał większej wiedzy o tym jak działa angular sam w sobie (system modułów, system templatek, relacje między templatkami a komponentami... nie chciało mi się tego uczyć), a react jest prosty dla kogoś komu nie chce się w niego zagłębiać, działa, spełnia swoją funkcję.

Pracuje w dużym korpo które ma projekty frontendowe w różnych frameworkach, niektóre zespoły mają angulara, inne reacta, w jednym projekcie widziałem vue. Dominuje podejście, gdzie w zespołach nie ma typowych frontendowców, a aplikacje robią programiści .NET którzy przy okazji mają zadania frontendowe (fullstack z przewagą backendu) i w takich zespołach dominuje react.

Co jest w sumie dość ciekawe, bo pamiętam jak lata temu słyszałem, że react słabo nadaje się do takiego zastosowania i w tym scenariuszu najlepiej sprawdziłby się angular (podobno dlatego, statystycznie częściej, korporacje wybierają angulara) - argumentem było to, że angular jest "bardziej obiektowy", a react ma "swoje udziwnienia" (np hooki). W praktyce mam wrażenie, że prościej jest zrozumieć w jeden dzień jak używać hooków, niż uczyć się specyfiki angulara.

Do prywatnych projektów też zawsze biore reacta, bo już znam go wystarczająco przez pracę, a nie chce mi się angażować w naukę frontendu

1
komentarz 2 marca przez marcin99b Szeryf (86,140 p.)

Jeśli patrzysz pod kątem własnego projektu, to szybkość ma znaczenie. Jeśli patrzysz pod kątem robienia projektów dla innych, to już ta szybkość jest kosztem kogoś innego, kto ją wybrał strategicznie.

W sensie

Czasami ktoś może celowo wybrać coś wolniejszego, bo przykładowo praca jest wygodniejsza, efekty są wcześniejsze, problemów jest mniej, więc będzie musiał wrzucić dodatkowe dajmy na to 10% do budżetu na serwery, ale zaoszczędzi tyle kasy na innych rzeczach, że wyjdzie na duży plus finansowy.

A są też odwrotne projekty, w których 10% budżetu na serwery to taka ogromna kasa, że warto poświęcić czas ludzi

Więc to decyzja strategiczna, zależna od tego, czym dokładnie ma być projekt i na jaką skale ma działać, w jakich warunkach, jakie są wymagania itd

komentarz 2 marca przez Edd Obywatel (1,400 p.)

Dzięki Marcin za obszerną odpowiedź! Zwróciłeś uwagę na interesujące problemy.

Trzeba jeszcze pamiętać, że Angular to framework, a React potrzebuje jeszcze masę dodatków albo Next.js lub coś podobnego.

--

Pracujesz w korpo - jesteś zadowolony z tej pracy? O korpo wiem niewiele, słyszałem, że pracuje się tam na dużych projektach i w wielu zespołach. Że kasa jest zwykle większa, ale też wymagania są większe i często pracuje się na legacy code, czyli utrzymaniówce. Projekty greenfield (zwykle gorzej opłacane, ale często ciekawsze) są domeną mniejszych firm czy zaczynających dopiero startupów. Ktoś pisał, że w korpo jesteś drobnym trybikiem, który nie jest szczególnie zauważany (doceniany) i zwykle trudniej jest awansować oraz ma się mniejszy wpływ na technologie, używany stack (który zwykle jest narzucony). Nie wiem, tylko słyszałem takie rzeczy. Nie pracowałem w korpo, robię dla Januszexów, Bartoszexów, Michałexów, a ostatnio Tymoteuszexów :)

1
komentarz 2 marca przez marcin99b Szeryf (86,140 p.)
edycja 2 marca przez marcin99b

Angular to framework, a React potrzebuje jeszcze masę dodatków

Czy ja wiem czy masę dodatków

  • react-router-dom warto dorzucić, ale to już chyba jest standard w gotowych templatkach
  • coś do zarządzania stanem, jak nie chcesz mechanizmu wbudowanego w reacta (tak zwany Context - według mnie on jest wystarczający do 90% sytuacji, no ale niektórzy są przyzwyczajeni do reduxa, a ostatnio modny sie robi zustand)
  • ewentualnie coś co formularzy, ale to są standardowe wybory, np formik + yup

I to w sumie tyle, nie przypominam sobie żeby coś jeszcze było konieczne. W dodatku te standardowe wybory są aż tak standardowe, że wszystkie biblioteki są sprawdzone, bezproblemowe i już podpięte w popularnych gotowych templatkach. Polecam https://create-react-app.dev/docs/getting-started/ do tworzenia nowych projektów. A w firmach zazwyczaj jest tak, że nie tworzy się co chwile nowych projektów które trzeba konfigurować, bo żeby projekty miały sens, to powinny być rozwijane przez większość czasu, a nie konfigurowane. Często konfiguracja to pierwszy tydzień, a przez następne miesiące lub nawet lata, głównie aktualizuje się wersje bibliotek albo podmienia te mniej istotne na lepsze alternatywy (ale to rzadko, niby zastępowanie zależności to popularny temat na rekrutacjach, bo jest dobrą okazją do pogadania sobie o tym co jest opisywane w mądrych książkach, ale w rzeczywistości nie zdarza się to zbyt często).

Next.js - ale to jest narzędzie do SSR, a nie ulepszacz reacta. Co prawda zmienia sposób pisania projektu, no ale to wynika z tego że korzystasz z SSR zamiast CSR. Wiem że next dodaje dużo rzeczy, ale to właśnie takie specyficzne dla aplikacji która jest takim pół frontendem pół backendem (np server components itp). To nie jest typowy frontend i inne frameworki frontendowe domyślnie tego nie mają (a przynajmniej nic o tym nie słyszałem i wątpię żeby to miały).

Pracujesz w korpo - jesteś zadowolony z tej pracy? O korpo wiem niewiele, słyszałem, że pracuje się tam na dużych projektach i w wielu zespołach

W dużym skrócie, każdy zespół jest inny, więc ciężko wymyślić jakiś odgórny opis pracy w korpo. Nawet w ramach jednej firmy, zespoły potrafią się skrajnie różnić.

Że kasa jest zwykle większa, ale też wymagania są większe i często pracuje się na legacy code

To jest to właśnie "każdy zespół jest inny", bo nie ma tutaj żadnej odgórnej zasady. Możesz mieć mikro firme która robi super niszowe narzędzie do cybersecurity, zatrudniają 5 drogich programistów, ale to eksperci którzy piszą mega skomplikowany kod i firma zarabia na tym grubą kase, a możesz mieć też zespół w korpo który głównie dodaje nudne formularze do jakiejś prostej i nudnej aplikacji, zarabiają mało bo to proste i powtarzalne zajęcie. Tak samo możesz mieć małą firme która bierze głównie nudne powtarzalne zlecenia, w których nie ma rozwoju bo ciągle robisz to samo i ciągle przerywasz na tym samym etapie, a możesz mieć zespół w korpo, który robi krytyczne rzeczy w architekturze korporacyjnej, przykładowo własne narzędzia do komunikacji między mikroserwisami.

Ktoś pisał, że w korpo jesteś drobnym trybikiem, który nie jest szczególnie zauważany

W każdej współpracy biznesowej sprzedajesz jakąś usługe, za jakąś cenę, którą obie strony akceptują. Awanse są raczej prostsze w korporacji, bo jest więcej zespołów, więcej projektów, jest większa szansa że zwolni się miejsce na jakiejś pozycji, albo powstanie nowy projekt, którym ktoś będzie musiał zarządzać. W małych firmach jest mało ludzi, mało projektów i są ludzie którzy siedzą na swoich stanowiskach od wielu lat, i nic nie wskazuje na to że się zwolnią niedługo.

 oraz ma się mniejszy wpływ na technologie

Jest więcej ludzi więc idąc czystą demokracją, twój głos ma mniejsze znaczenie, ale jeśli to jest poboczny projekt który nie ma dużego znaczenia, to ewentualne eksperymenty w korpo przyniosą mniejsze straty niż w małej firmie. Mała firma zazwyczaj ma mały budżet, więc każda decyzja jest ważna, każdy projekt ma duże znaczenie, każdy kontrakt ma realny wpływ na funkcjonowanie firmy. A w korporacji... projekt nad którym 10 osób pracowało przez rok może być do wyrzucenia i nikt nie poniesie za to konsekwencji.

Na pewno w korporacji jest dużo większe myślenie o bezpieczeństwie, więc trudniej jest używać mało popularnych bibliotek, ale jeśli przez wpływ na używany stack masz na myśli korzystanie z popularnych rzeczy, po prostu różnorodnych, to nie ma z tym problemu, a nawet w korporacji takie skakanie jest prostsze, bo jest więcej projektów, więcej zespołów.

jesteś zadowolony z tej pracy

Ciężko powiedzieć, ale pracowałem w firmach o różnej wielkości i nie miałem wrażenia żeby jakiś konkretny rozmiar był lepszy albo gorszy. W obecnej nie jestem na tyle szczęśliwy żeby uważać ją za super spędzony czas i świetną decyzję w życiu, ale było kilka fajnych projektów, dobrze mnie traktują, płacą mi okej.

Gdyby inna firma zaproponowała mi lepsze warunki, to bym je rozważał, ale w ostatnich latach wszystkie propozycje które dostawałem, były gorsze niż to co mam teraz.

1
komentarz 2 marca przez marcin99b Szeryf (86,140 p.)

https://create-react-app.dev/docs/getting-started/ - chociaż podobno to już nie jest aktualne i są jakieś nowsze, lepsze alternatywy polecane przez twórców reacta (nie śledze tematu bo tak jak pisałem na samym początku, frontend to dla mnie coś co trzeba zrobić żeby użytkownik mógł sobie klikać, a nie element kariery którym się przejmuje)

komentarz 5 marca przez Edd Obywatel (1,400 p.)

@marcin99b, Dzięki za przybliżenie korpo (i reacta)!

Jak wystarczy mi sił i chęci ;) to nauczę się obu (tak jak radził tu drugi kolega), zacznę od Angulara :)

+2 głosów
odpowiedź 1 marca przez WojAbuk Gaduła (3,460 p.)
To jest czysta kwestia preferencji. Też pytanie do czego. Ja przy tak zadanym pytaniu raczej wybrał bym React, ale podkreślam że jest to kwestia preferencji. Z interesujących są jeszcze Flatter i Elm. Mówiąc szczerze ja wybierał bym właśnie między Flatter i Elm w zależność od konkretnego projektu, ale to też kwestia moich preferencji, bo ja nie lubię ECMAScript. Flatter użył bym tam gdzie mam zamiar stworzyć aplikację, a Elm tam gdzie chcę stworzyć tylko stronę internetową.
komentarz 1 marca przez Edd Obywatel (1,400 p.)
Flutter to WASM, trochę inne podejście, nie wiem jak z jego prędkością w web i jak ciężki jest plik do ściągnięcia, tam byle małe SPA liczone jest w MB.

Zaskoczyłeś mnie tym Elm, wiem, że jest super, ale mało kto go używa (mam na myśli firmy), do swoich projektów - super sprawa!

Słyszałem, ze Elm jest bardzo bezpieczny, tzn. nie pozwala (utrudnia) developerowi zrobić błędy - nie wiem jak to działa w praktyce, może przybliżysz forum działanie Elm...?
+2 głosów
odpowiedź 22 marca przez neo1020 Stary wyjadacz (10,470 p.)
Jeśli miałbym wybierać, to biorę Next.js. Ten routing oparty na folderach zjada czystego Reacta na śniadanie, nawet jeśli zupełnie nie dotykam SSR.

Co do Angulara... próbowałem go kiedyś bez wsparcia AI i po prostu mnie odrzucił. Przy dzisiejszym rozwoju AI wybór konkretnego frameworka traci na znaczeniu. Pamiętam czasy nauki PHP, szukania błędów po nocach i czekania dniami na odpowiedź na forum. Robiłem w korpo apkę żeby pokazać, że da się coś zrobić lepiej z logowaniem kartami RFID, szyfrowane hasła bo mi kierownik i informatyka przypominali że to musi być bezpieczna aplikacja ble ble ble a ludzie między halami zamawiają towar na grupie na fb, a potem 'zakładowy programista' dowozi soft, gdzie hasła 20 osób wiszą w ustawieniach plaintextem... i wszyscy to widzą xD korpo <3

Dzięki AI przejechałem przez Next.js, Vue, Nuxta, Javę, C#, a teraz siedzę we Flutterze i piszę backendy w Go (Express i Node odstawiłem), a ostatnio nawet testuję Rusta czy skrypty LUA, Redis, Redis Stream. Kiedy darmowy hosting zablokował mi API antybotem, po prostu skopiowałem logi do modelu i po 3 sekundach miałem rozwiązanie, potem dopiero wszedłem na forum hostingu a tam burza o antybota.

Zauważyłem, że Next dodał w dokumentacji przycisk 'Copy Page'? To jest ewidentnie ukłon w stronę AI (IMO). Mój CLI w Go napisałem w podobny sposób.

Więc tak jak wspomniał @Comandeer - ważniejsza jest znajomość architektury, inżynieria oprogramowania i świadomość bezpieczeństwa niż sam język. Trzeba po prostu znać specyfikę narzędzia, np. wiedzieć, że w Go context to nitka życia requesta, albo że wiekszości jezyków Stringi są immutable i wiszą w pamięci dopóki Garbage Collector łaskawie jej nie usunie itp , a resztę dowiezie Ci sprawny prompt, dokumentacja czy próby penetracyjne.

Jeśli wejdziesz w świat systemów bankowych, militarnych czy rządowych, to tam nikt nie pyta, czy "lepiej pisać w Next czy Angularze". Tam pytają, czy Twój kod spełnia normy takie jak PCI DSS, ISO/IEC 27001, czy standardy OWASP ASVS a lepiej ASVS L3 czy tylko słyszałeś o OWASP top 10 :)

No i na koniec, co z tego, że Twoja architektura jest nie do przejścia, zerujesz każdy bit w RAM-ie, skoro ktoś może się po prostu zatrudnić w firmie jako 'insider', albo przeprowadzić skuteczny atak na człowieka przez telefon? No wchodzę na X i czytam wiadomośći z Policji a tam piszą że z jakimś gościem skontaktował się pracownik banku, i kazał mu przelać 65 000 zł na konto awaryjne banku a że żona zajmuje się finansami to zrobiła 2 przelewy na 40 i 25 tys zł. W korpo jeszcze jak pracowałem to przychodziły emaile z podobnej domeny niż nasza firmowa różnica była w 1 literze i temat  'płaca  wszystkich pracowników za rok 2023' i załącznik, i ludzie to otwierali, do dzisiaj się zastanawiam czy to informatyka testowała pracowników
0 głosów
odpowiedź 5 marca przez Edd Obywatel (1,400 p.)

Oto szczegółowy podział udziału i popularności w 2026 roku:

  • React: Pozostaje niekwestionowanym liderem rynkowym z udziałem rzędu 40-45%. Jego dominacja wynika z ogromnej społeczności, ekosystemu (React Native) i adopcji przez duże korporacje.
  • Vue.js: Utrzymuje silną drugą pozycję, ceniony za swoją "progresywność" i łatwość nauki, z udziałem w rynku szacowanym na ok. 15-22%.
  • Angular: Stabilny, "gotowy dla przedsiębiorstw" (enterprise-ready) framework, często używany w dużych projektach, z udziałem ok. 12-18%.
  • Svelte: Zyskuje na popularności jako nowa generacja frameworków (compiler-first), ceniony za wydajność i mniejszy rozmiar aplikacji, z szacowanym udziałem rzędu 7-11%.

 

Nie sądziłem, że Vue jest tak wysoko, a Angular tak nisko.

Podobne pytania

+1 głos
1 odpowiedź 1,304 wizyt
pytanie zadane 25 listopada 2017 w JavaScript przez sapero Gaduła (4,100 p.)
+2 głosów
2 odpowiedzi 4,201 wizyt
pytanie zadane 24 października 2016 w JavaScript przez dobrydiler Użytkownik (650 p.)
0 głosów
0 odpowiedzi 487 wizyt
pytanie zadane 15 listopada 2019 w JavaScript przez michal_php Stary wyjadacz (13,700 p.)

93,718 zapytań

142,630 odpowiedzi

323,262 komentarzy

63,265 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj

Twierdza Linux. Bezpieczeństwo dla dociekliwych

Aby uzyskać rabat -10%, użyjcie kodu pasja-linux, wpisując go w specjalne pole w koszyku.

...