Angular czy JSF ( biblioteka Primefaces) ?

0

W czym zrobić frontend JSF ( biblioteka Primefaces) czy Angular 4?

10

JSF

1

Od strony klienta, to ja wolę strony zrobione w JSF, czy innej jednoprzebiegowej technologii. Są stabilniejsze i lepiej chodzą na słabszych komputerach.

1
jarekczek napisał(a):

Od strony klienta, to ja wolę strony zrobione w JSF, czy innej jednoprzebiegowej technologii. Są stabilniejsze i lepiej chodzą na słabszych komputerach.

Tylko, że to nic nie ma wspólnego z *nowoczesnym *JSF (typu Primefaces) gdzie AJAX miesza sie z przeładowaniem strony w najgorszy możliwy sposób. W efekcie dostajesz ciężkie strony, które dodatkowo co chwila się przeładowują.

0

Co to znaczy przeładowanie w najgorszy możliwy sposób? Masz na myśli redirecty? Dla wewnętrznych aplikacji które nie mają setek tysięcy użytkowników nie jest to straszny problem. AJAX PrimeFaces do prostych rzeczy w zupełności daję rade: w kontekście 1 widoku. Do SPA JSF się nie nadaje. Zaletą JSF jest duża liczba gotowych komponentów (i jeśli nas zadowalają tylko wtedy może mieć to sens).
Na komponenty do Angulara 13 będzie trzeba jeszcze poczekać i pytanie czy będą kompatybilne z Angularem 14.

Dla mnie Angular i cały JS ma jedną poważną wadę: dziś jest, jutro będzie wyglądał zupełnie inaczej. Cena innowacyjności. Dość dobrze natomiast migrowało się legacy projekty nawet z JSF 1.2 do JSF 2.2 i stare Icefaces do PrimeFaces.

Poza tym nie trzeba wystawiać REST API: szybciej się dostarcza. Jak dla mnie Google i jego produkty są nieprzewidywalne, przykład GWT.

Może trzeba uczyć się Reacta? Ale pewnie za dwa lata i tak zniknie jak większość ze śwata JS bo będzie inny hype.

3

@margor90
Brałem udział w kilku projektach JSF zespołowych - liczba problemów była dramatyczna (fakt, że dołączałem do tych projektów jak już były w d...e). Gigantyczne zużycie pamięci na serwerze, wszystkie beany session scope - bo tłuszcza programistyczna inaczej nie umi,
kompletnie niezrozumiałe dla przeciętnego programisty fazy renderowania, ciężkie strony wywalające przeglądarki (jak Ci serwer taką tabelkę wygeneruje to nic nie poradzisz), a i tak prawie zawsze kończyło się tym, że trzeba było jakies haki w JavaSkrypcie pisać.... O stylowaniu (CSS) też szkoda gadać, a zwykle klient chce mieć oczywiście swoją korpoczcionkę i korponiebieski niepasujący nijak do całej reszty primefaces.

A co do gotowych komponentów w JSF... nie wiem czy wiesz o czym piszesz. Porównaj z komponentami do Angulara właśnie.

Poza tym nie słyszałem o angularze 13 czy 14. Wolę coś co dziś jest dośc dobre, a jutro będzię dostepna nowa lepsza wersja. To nadal lepsze niż framework, kóry jest stabilnie beznadziejny od 15 lat.

Poza tym nie tylko ja mam takie zdanie o JSF -> https://www.thoughtworks.com/radar/languages-and-frameworks/jsf

Kiedyś przycztałem kilka książek o JSF i jak pisałem projekty sam sobie - to byłem zadawolony: a) nie znałem wtedy lepszych alternatyw , b) nie musiałem głupot tego frameworku nikomu tłumaczyć

0

Uczenia się JSF z książek to bezsens to jak dla mnie kompletne oderwanie od praktyki. Ładowanie wszystkiego do SessionScope skończyło się w JSF 1.2 (a nawet wtedy było coś takiego jak extended RequestScoped dla starych IceFaces, aby nie trzeba było wszystkiego robić na session scope). Jedyne źródło wiedzy to:
https://stackoverflow.com/users/157882/balusc (oraz blog tego Pana)

Dorobienie drobnej zmiany w JS / jQuery to zasadniczo nie jest specjalnie nic złego: jak masz gotowe komponenty nieważne od frameworka hakowanie i modyfikacja DOM to jest coś nietrywialnego (w Angular to może być jeszcze trudniejsze, bo nie ma tam w standardzie jQuery).

Jakie komponenty do Angulara 4 polecasz ze swojej praktyki projektowej? Raczej nie ma ich zbyt wiele, skoro Angular 4 ma kilka miesięcy. Jak dla mnie nieważne jakich komponentów użyjesz decydując się na framework komponentowy z gotowcami i tak będziesz miał problemy zmieniając czcionki/kolory/style komponentów zaprojektowanych przez kogoś innego.

Jedyna rzecz, która mi mocno przeszkadzała przez 4 lata pracy z JSF to trudność testowania frontendu. Jest to mocno nietrywialne i znacznie łatwiej robić to w Angularze: mam na myśli kompletną izolację backend i frontend tzn. dwie niezależne aplikacje całkowicie w różnych językach.

3
margor90 napisał(a):

Uczenia się JSF z książek to bezsens to jak dla mnie kompletne oderwanie od praktyki. Ładowanie wszystkiego do SessionScope skończyło się w JSF 1.2 (a nawet wtedy było coś takiego jak extended RequestScoped dla starych IceFaces, aby nie trzeba było wszystkiego robić na session scope). Jedyne źródło wiedzy to:
https://stackoverflow.com/users/157882/balusc (oraz blog tego Pana)

No to mnie zadziwia. Bo właśnie dramaty i walka z listenerami, scope itp. brała się z tego, że nikt w zespole nie czytał jak działa JSF tylko na URRRAA kopiowali ze stackoverflow. Kilka miesięcy takiej pracy, 5 osób i projekt nawet nie wiadomo jak pozbierać żeby działał..

Dorobienie drobnej zmiany w JS / jQuery to zasadniczo nie jest specjalnie nic złego: jak masz gotowe komponenty nieważne od frameworka hakowanie i modyfikacja DOM to jest coś nietrywialnego.

Tyle, że w Angularze czy czymkolwiek pracujesz z przewidywalnym DOM, na który masz bezpośredni wpływ. W JSF coś Ci się generuje, na co nie masz wpływu i do tego robisz haki. Tzw. ogień pośredni - zmieni Ci sie wersja PrimeFaces i jesteś w prdeli z twoim hakiem ( a czasem wystarczy, że ktoś nieznacznie ruszy strukturę komponentów).

Jakie komponenty do Angulara 4 polecasz ze swojej praktyki projektowej? Raczej nie ma ich zbyt wiele, skoro Angular 4 ma kilka miesięcy. Jak dla mnie nieważne jakich komponentów użyjesz decydując się na framework komponentowy z gotowcami i tak będziesz miał problemy zmieniając czcionki/kolory/style komponentów zaprojektowanych przez kogoś innego.

Żadnych nie polecam. Polecam wziąć te których potrzebujesz w projekcie:
https://github.com/brillout/awesome-angular-components

poza tym w cholerę Webcomponentow, które łatwo się integruje z angularem
https://www.webcomponents.org/elements

Dodatkowo dorobienie własnych komponentów jest proste. Zwykle bierze się jakiś istniejąc komponent w JS (a jest tego tony....) i dorabia prostą dyrektywę/component w Angularze jako wrapper.

Przykładowo: mnie rozczuliło jak się okazało, że pod angulara (fakt, że starego) mam gotowy komponent typu edytor kodu, z kolorowaniem składni i toną opcji (CodeMirror). zrobiłem sobie z tego własne IDE webowe do prezentacji :-)

1

Fakt JSF to przedpotopowa technologia i strasznie toporna. Nawet primefaces to troche szajs. Ale wszystko ma swoje wady i zalety, wada angularow jest to że za 2 lata wszystko sie zmieni i wyjdzie angular 32 albo 64 który bedzie całkiem inny od poprzednich. To jest tragedia w utrzymaniu.

2

ja też się dorzucę.
Z JSF jest jak z każdą technologią - jak dasz to małpie to spierdoli w koncertowym stylu. Jak opisane powyżej Sesison scopy wszędzie, albo nie rozumienie, jak ma być wykorzystany listener, a jak action. No ale nie przekreślałbym technologii z powodu idiotów jej używającej - nie pistolety zabijają, tylko ludzie.

PrimeFace akurat jest słabym rozwiązaniem - zwłaszcza z powodu podejścia samego twórcy i beznadziejnej dokumentacji. Co prawda się to zmieniło na plus w ostatnich dwóch latach, no ale cóż - u mnie niesmak pozostał. Czysty JSF 2.2 do tego Bootstrap, i ogarnięty DEV to jest przepis na sukces. No ale tych ogarniętych jest mało, a sytuacja najczęściej wygląda jak opisana powyżej - na huuuura lecimy, kopiujemy, i po wypłatę.

Polecam zapoznać się z blogiem Bauke Schultz aka BalusC - gość ma doktorat w JSF i bardzo ładne tłumaczenie wszystkich zagadnień, z powołaniem się na dokumentację, cykl życia widoku, etc.

5

Jeden Straszny Fakap, tyle w temacie. Utworzenie frontendu w Angularze 4, React.js czy innym rozwiązaniu JS ma kilka zalet:

  1. Piszesz kod po stronie serwera i nie zastanawiasz się jak to będzie wyświetlane. Session Bean, a co to? Zwracasz dane w postaci JSONa i niech się frontend martwi jak to ogarnąć.
  2. Wymusza na kliencie utrzymywanie aktualnych, albo przynajmniej w miarę świeżych, przeglądarek. Działy bezpieczeństwa dużo gadają zazwyczaj o różnych strasznych zagrożeniach, ale nieaktualny soft jakoś dziwnie nie jest jednym z nich…
  3. Skalowalność wynikająca z braku sesji. Potrzebujesz nagle 10x więcej mocy. Proszę bardzo, wstajesz i działa. Odpada skomplikowana operacja wpinania się w klaster. Wystarczy zaktualizować informacje w loadbalancerze.
  4. Z tego wynika też możliwość delegowania konkretnych elementów aplikacji na konkretne maszyny.

Oczywiście są też wady:

  1. Musisz nająć kogoś, kto ogarnia jakiś framework JS, albo samemu się doszkolić.
  2. Stosunkowo krótki czas życia niektórych frameworków.
  3. Musisz jakoś sobie poradzić z problemami związanymi z zarządzaniem autoryzacją i autentykacją. Jest dużo różnych rozwiązań, ale trzeba umieć określić swoje potrzeby.
1

Mnie w długoterminowym projekcie na JSF najbardziej uwierało jak trudno pozbyć sie starych bibliotek do tworzenia GUI w moim przypadku IceFaces. W rezultacie aplikacja utknęła na JDK 1.7, a przeciętny biznes średnio chce płacić za migracje (woli za rozszerzenia). Całkowita izolacja backendu od frontendu rozwiązuje ten problem. Czasem jednak dodatkowy .jar, który siedzi w projekcie może nieźle blokować znaczną część systemu przed aktualizacjami. Backendy migruje się oczywiście znacznie łatwiej. Fajne mieć możliwość przepisania frontu bez ruszania backendu.
Dla mnie wystawianie jednak REST API, aby zrobić bardzo PROSTE gui, stronę logowania, gdzie jest kilka labelków, prosta tabelka i kilka przycisków to armata na muchę. Czasem potrzebna jest nisza pośrednia pomiędzy desktop, a web. JSF w tym przypadku działa.
Najlepiej pozbyć się serwerów aplikacyjnych. W praktyce rzadko zaczyna się projekt całkowicie od zera, a długoletnie projekty to zwykle wiele kompromisów (przy takich projektach można się też więcej nauczyć).

Jakbym miał coś robić na Angularze wybrałbym JHipster. Zwłaszcza, że TypeScript jest bardzo fajny. Najlepiej mieć dedykowanego frontend developera, ale do prostych rzeczy nie zawsze trzeba.

2
margor90 napisał(a):

[...] Backendy migruje się oczywiście znacznie łatwiej. Fajne mieć możliwość przepisania frontu bez ruszania backendu.

Ponieważ w poprzedniej firmie wyciągałem dwa duże projekty z Javy 6 na 8 to nie do końca się zgodzę. Magiczne application servery (np, konkretnie Websphere), albo dodatki do Springa (konkretnie Spring-OSGI :-( ) potrafią stanowić duży problem). Bo np. skanują classpath i nie kumają bytecode dla Java 8.

Rok cisłem (razem z kilkoma osobami) zanim się udało (trzeba np. było przemigrowac się do nowego websphera co kosztowało koszmarne pieniądze (testy wydajnościowe, konfigi itp)).

Btw. wystawianie REST-API ( z JavaEE lub Ratpack) + Angular do prostych projektów typu konsole administracyjne - to to co dokładnie w poprzedniej firmie robiliśmy. Super prosto. A nasz najtwardszy JavaEE programista został mistrzem TypeScriptu - po tym jak zrobił pierwszy serwis w ten sposób to nie chciał już inaczej...

0

Moje pozytywne doświadczenie odnośnie migracji dotyczyło GlassFisha. Generalnie EJB 3.0 do 3.2 bez problemu poszło. Trochę kasowania kodu. Ku mojemu zaskoczeniu nawet zaskakująco dobrze zadziałało z CDI. Tylko te IceFaces. Jak dla mnie WebSphere, WebLogic czy SAP NetWeaver to jest totalny beton i ostateczność. W moim przypadku stare IceFaces to był taki nowotwór, który można było tylko podleczyć i unieszkodliwić (zarządzanie długiem technicznym). Czasem można bardzo poprawić sytuację i nie trzeba nic więcej.

Ale jak projekt jest duży, ma tysiące tabel to ciężko spodziewać się łatwej migracji. I tak uważam, że podczas tego typu procesów zdobywa się masę wiedzy. Ponieważ jest to trudne jest to wymagająca robota dla prawdziwych programistów za lepsze stawki. Projekt GreenField uczy innych rzeczy. Trzeba mieć mieszane doświadczenie.

W tym WebSphere mieliście backend i front oddzielnie? Czy biblioteki 3rd party to był kwas? Może to banał ale, aby migrować serwer aplikacyjny to trzeba oczywiście czekać na certyfikacje (wcześniej nie będzie działać).

Komercyjne middleware to zło.

0

JSF to badziew. A odnośnie nauki to zacznij od JavaScriptu i jquery. Tak zrób po prostu prostą stronkę w jquery, która przeładowuje se co trzeba ajaxem.
Ewentualnie pomyśl nad Thymeleaf.

3

Tak tak tak bo w zasadzie wszystkie bolączki systemów rozwiązuje JavaScript i Angular. Aktualnie rozwijamy aplikację w AngularJS która ma 7 lat i jest kiepsko, problemy z wydajnością, wyciekami pamięci, błędami które są tylko u klientów ( w sever side mieliśmy na konsoli), stanami w które wchodzi aplikacja które są teoretycznie niemożliwe...ogólnie syf który ładuje do przeglądarki 60MB

Do łatwych rzeczy prawie wszystko się nadaje.....

3

Jak mam porównać to wolę walczyć wyciekami i powolnością w aplikacji SPA w stylu angularjs lub nawet JQUERY -> niż w generowanym JS przez GWT lub PrimeFaces. Tam to jest koszmar bo nawet jak znajdziesz czemu muli to powstaje kolejny problem, a co teraz można zmienić żeby taki JS się nie generował. (ogień pośredni).
To, że strony w stylu 1999 bez javaskryptu w wygenerowanym html są o niebo łatwiejsze to prawda... tylko, że jak dla mnie to syf dla klienta coś jak robienie menu w konsoli terminala - nie chce nawet takich robić :-)

0

"Wymusza na kliencie utrzymywanie aktualnych, albo przynajmniej w miarę świeżych, przeglądarek. " życie nie jest takie proste. Weź pod uwagę, że niektórzy klienci mogą mieć do wymiany po kila tysięcy stacji i zwykle nie da się tego zrobić adhoc.

1 użytkowników online, w tym zalogowanych: 0, gości: 1