Angular vs React w 2024

Obie biblioteki (Angular i React) rozwiązują w zasadzie ten sam problem - czyli obsługa warstwy UI klienckiej części aplikacji webowej. Stosują bardzo podobne podejście, propagacja propsów w dół, dzieci przekazujące akcję do rodzica (event w angularze, callback w reacie), router, optymalizacje dom (virtual dom w reacie, incremental dom w ng), komponenty, współdzielony stan (redux, ng store), etc. Pomijając składnię, to są swoje klony. Tak na prawdę jedyną istotną różnicą jest to że przy okazji Reacta, przez konwencję używa się JSX, natomiast markup w angularze osadza się jako template przy komponencie, ale jak już mówiłem, to są dwa sposoby osiągnięcia tego samego, czyli abstrakcja na budowanie drzewa html. W zasadzie ciężko mi wskazać pomiędzy nimi różnicę która nie byłaby szczegółem implementacyjnym.

PS: Wiem. React ma większe community chyba, przez co wsparcie jest większe, wydaje mi się.

Nie widzę problemu żeby nauczyć się obu.
React mi się wydaje lepszy do luźnych i mniejszych projektów / startupów - czyli większości projektów, a angular do korpotworów.
React jest względnie łatwiejszy - normalne że jest w nim więcej projektów, pracy ale też kandydatów. Wydaje mi się że w reactcie szybciej i łatwiej o spaghetti w kodzie a angular wymusza bardziej zorganizowany kod, stąd może większe zamiłowanie do niego w korpo.
Najlepiej umieć oba i nie ograniczać się w ofertach. Czasem można nawet pracować przy projektach w obu frameworkach w jednej firmie.

Riddle napisał(a):

W zasadzie ciężko mi wskazać pomiędzy nimi różnicę która nie byłaby szczegółem implementacyjnym.

a jednak koduje się w nich zupełnie inaczej i wymagają nawet innego myślenia do osiągnięcia tego samego.

Angular > React ale też nie zawsze i nie wszędzie.

Ja lubię Angulara, bo jak już go zrozumiesz to każdy codebase Angularowy ogarniesz (niezależnie od syfu i innych cudeniek).

Z Reactem jest to że co projekt to inne wymysły, moim zdaniem dev experience troche gorszy, no i ja fanem JSX nie jestem.

Angular ma swoj renesans teraz, jak ogarna zoneless change detection to już w ogóle Angular FTW.

Ale zgadzam się z @obscurity, że Angular to raczej grube i duże rozwiązania.

No i jeszcze jedna rzecz że Angular jest stabilny, a w React to co chwila coś nowego, były klasy, później funkcję, pytanie co jest teraz

Ja z Angulara głównie zyje więc może być bias.

ktoś mi kiedyś powiedział ze angular to troche jak java vs javascript.
angular -> java, react -> javascript.
Angular jest trudniejszy, bardziej cie ogranicza, ale robi to w jakimś celu.
Generalnie nie ma znaczenia który framework wybierzesz. Najlepiej znać oba.

obscurity napisał(a):

Riddle napisał(a):

W zasadzie ciężko mi wskazać pomiędzy nimi różnicę która nie byłaby szczegółem implementacyjnym.

a jednak koduje się w nich zupełnie inaczej i wymagają nawet innego myślenia do osiągnięcia tego samego.

Przykład?

PS: Też pytanie czy przez faktyczne różnice czy przez konwencje?

Riddle napisał(a):

Przykład?

PS: Też pytanie czy przez faktyczne różnice czy przez konwencje?

przez konwencje, react wymusza stany immutable i tworzy cały komponent od nowa za każdym razem, trzeba kombinować żeby jak najmniej się renderowało po zmianie i nie wpaść w nieskończoną pętle, angular ma komponenty jako klasy i można programować w bardziej tradycyjny sposób. Angular ma serwisy i DI container a react raczej custom hooki, serwisy praktycznie jako takie się nie pojawiają a wstrzykiwanie jest ręczne i bezpośrednie, ewentualnie przez kontekst. W zasadzie podejrzewam że większość react devów nie słyszało terminu dependency injection.

obscurity napisał(a):

Riddle napisał(a):

Przykład?

PS: Też pytanie czy przez faktyczne różnice czy przez konwencje?

przez konwencje, react wymusza stany immutable i tworzy cały komponent od nowa za każdym razem, trzeba kombinować żeby jak najmniej się renderowało po zmianie i nie wpaść w nieskończoną pętle, angular ma komponenty jako klasy i można programować w bardziej tradycyjny sposób.

https://react.dev/reference/react/Component Początkowe komponenty react były na klasach, tak samo jak w angular.

To że teraz popularne są tzw. "functional components" to jakby uproszczona wersja tego, i one nie tyle wymuszają immutability, co po prostu nie da się mieć mutable state w FC, skoro każdy render to ponowne wywołanie funkcji; i to powoduje obejścia tego, jak hooki. Class-based components normalnie mutują state i to działa tak samo jak w Angularze.

obscurity napisał(a):

Angular ma serwisy i DI container a react raczej custom hooki, serwisy praktycznie jako takie się nie pojawiają a wstrzykiwanie jest ręczne i bezpośrednie, ewentualnie przez kontekst. W zasadzie podejrzewam że większość react devów nie słyszało terminu dependency injection.

Nazywa się to inaczej, ale zasada działania jest taka sama. Większość rozwiązań które widziałem dostarcza zależności do niższych poziomów przez HoF albo właśnie przez kontekst. W zasadzie jak przekażesz usługę przez kontekst do dziecka to jest to tożsame z DI, tylko składnia inna.

Treektus napisał(a):

Z tego, co wiem, React jest łatwiejszy w nauce i częściej stosowany w mniejszych projektach. Oznacza to, że na rynku jest więcej ofert pracy, ale jednocześnie panuje większa konkurencja.

Z tym łatwiejszy w nauce bym nie przesadzał. Owszem, jest niski poziom wejścia, jednak React wymaga pisania dużo dziwnego kodu.

Z Reacta dałoby się zrobić język programowania, a nie tylko bibliotekę. Niby to JavaScript, ale bardzo dziwny JavaScript. Trzeba pisać po reactowemu stosując jakieś dziwne abstrakcje (te hooki to jakiś żart). Myślę, że to miałoby więcej sensu, jeśli twórcy Reacta postanowili pójść ścieżką Svelte i te rzeczy po prostu skompilować. Ew. ścieżką Vue i te rzeczy wykrywać bardziej automatycznie.

No i każdą wersją twórcy Reacta rozwiązują bohatersko problemy, jakie sami stworzyli. Jak i społeczność wokół Reacta ciągle tworzy nowe biblioteki pomocnicze rozwiązujące problemy, które stworzyły starsze biblioteki pomocnicze. Ciągle też się zmieniają rozwiązania, bo po prostu wychodzą z mody. Czyli ogólnie jeden wielki burdel.

Choć nie jestem pewien, czy w innych frameworkach jest lepiej/gorzej, bo z React miałem najwięcej do czynienia.

@Riddle Projekt angularowy i podejście pod względem toolingu jest praktycznie taki sam. W przypadku reacta nie spotkałem dwóch projektów takich samych. React daje bardzo dużą swobode przy łączeniu rozwiązań co dla wielu bedzie plusem dla mnie jest to minus.

Co do ilosci ofert pracy to chyba subiektywne, bo ja teraz szukam na react develoepra, i wszedzie widze tylko ten angular... az sie zaczalem zastanawiac czy nie nauczyc sie tego angulara - ale pierw musze wiecej doswiadczenia zdobyc w react'cie.

Riddle napisał(a):

Obie biblioteki (Angular i React) rozwiązują w zasadzie ten sam problem - czyli obsługa warstwy UI klienckiej części aplikacji webowej. Stosują bardzo podobne podejście, propagacja propsów w dół, dzieci przekazujące akcję do rodzica (event w angularze, callback w reacie), router, optymalizacje dom (virtual dom w reacie, incremental dom w ng), komponenty, współdzielony stan (redux, ng store), etc. Pomijając składnię, to są swoje klony. Tak na prawdę jedyną istotną różnicą jest to że przy okazji Reacta, przez konwencję używa się JSX, natomiast markup w angularze osadza się jako template przy komponencie, ale jak już mówiłem, to są dwa sposoby osiągnięcia tego samego, czyli abstrakcja na budowanie drzewa html. W zasadzie ciężko mi wskazać pomiędzy nimi różnicę która nie byłaby szczegółem implementacyjnym.

PS: Wiem. React ma większe community chyba, przez co wsparcie jest większe, wydaje mi się.

Ale pierdo-lolo.

Parafrazujac:

Assembler i Java rozwiazuja w zasadzie te same problemy - czyli automatyzacja procesow, tak zeby niektore zadania wykonywal komputer, zamiast czlowieka - rzedy wielkosci razy szybciej od niego.
W obu przypadkach powstaja jakies algorytmy, ktore cos dostaja na wejscie i cos wypluwaja na wyjscie. Pomijajac skladnie, to sa to klony. Cala reszta to szczegol implementacyjny. To sa dwa sposoby osiagniecia tego samego.

Fiat 126p i S-klasa to to samo. W obu przypadkach chodzi o przemieszczenie sie z punktu A do B. Reszta to szczegol implementacyjny.

Czyli jak nie lubisz pisać w javascriptcie to lepiej iść w pangulara?

mitowski napisał(a):

Czyli jak nie lubisz pisać w javascriptcie to lepiej iść w pangulara?

Nie, w obu masz javascript. Porównanie do javy moim zdaniem nawiązuje do ilości boilerplate'u jaki framework wymusza.
Jak nie lubisz javascript to jest blazor