Powody, dla których NIE należy używać JSF [zamknięte]

64

Jestem nowy w StackExchange, ale pomyślałem, że będziesz w stanie mi pomóc.

Tworzymy nową aplikację Java Enterprise, zastępującą starsze rozwiązanie JSP. Z powodu wielu wielu zmian interfejs użytkownika i elementy logiki biznesowej zostaną całkowicie przemyślane i ponownie wdrożone.

Naszą pierwszą myślą było JSF, ponieważ jest to standard Java EE. Na początku miałem dobre wrażenie. Ale teraz próbuję wdrożyć funkcjonalny prototyp i mam poważne obawy dotyczące jego używania.

Po pierwsze, tworzy najgorsze, najbardziej zagracone nieprawidłowe pseudo-HTML / CSS / JS, jakie kiedykolwiek widziałem. Narusza każdą zasadę, której nauczyłem się podczas tworzenia stron internetowych. Ponadto łączy w sobie to, co nigdy nie powinno być tak ściśle powiązane: układ, projekt, logika i komunikacja z serwerem. Nie rozumiem, jak mógłbym wygodnie rozszerzyć tę wydajność, czy to stylizowanie za pomocą CSS, dodawanie cukierków w interfejsie użytkownika (takich jak konfigurowalne skróty, przeciąganie i upuszczanie widżetów) czy cokolwiek innego.

Po drugie, jest to zbyt skomplikowane. Jego złożoność jest znakomita. Jeśli mnie zapytasz, jest to słaba abstrakcja podstawowych technologii sieciowych, w końcu okaleczona i bezużyteczna. Jakie mam świadczenia? Brak, jeśli pomyślisz. Setki komponentów? Widzę dodatkowo dziesięć tysięcy fragmentów kodu HTML / CSS, dziesięć tysięcy fragmentów kodu JavaScript i tysiące wtyczek jQuery. Rozwiązuje naprawdę wiele problemów - nie mielibyśmy, gdybyśmy nie korzystali z JSF. Lub w ogóle wzór przedniego kontrolera.

I wreszcie, myślę, że będziemy musieli zacząć od nowa, powiedzmy za 2 lata. Nie rozumiem, jak mogę wdrożyć wszystkie nasze pierwsze makiety GUI (poza tym; nie mamy Eksperta JSF w naszym zespole). Może moglibyśmy to jakoś zhakować. A potem będzie ich więcej. Jestem pewien, że moglibyśmy zhakować nasz hack. Ale w pewnym momencie utkniemy. Ze względu na wszystko powyżej warstwa usług kontroluje JSF. I będziemy musieli zacząć od nowa.

Moją sugestią byłoby zaimplementowanie interfejsu API REST przy użyciu JAX-RS. Następnie utwórz klienta HTML5 / Javascript z MVC po stronie klienta. (lub jakiś smak MVC ..) Przy okazji; i tak będziemy potrzebować interfejsu API REST, ponieważ opracowujemy również częściowy interfejs Androida.

Wątpię, czy JSF jest obecnie najlepszym rozwiązaniem. Ponieważ Internet ewoluuje, naprawdę nie rozumiem, dlaczego powinniśmy korzystać z tej „prowizji”.

Jakie są zalety / wady? Jak mogę podkreślić, że nie używam JSF? Jakie są mocne strony, aby użyć JSF w porównaniu z moją sugestią?

— Bruno Schäpper
źródło

24

To dobrze napisane pytanie od nowego użytkownika. Rozważ pozostawienie komentarza podczas głosowania w dół.

— ThiefMaster

2

Ponieważ przepisujesz wszystko, nie tylko rozważę nieużywanie JSF, ale w ogóle nie będę używać Java. Nowoczesne języki skryptowe (tj. Nie PHP lub Perl) są całkiem ładne i przyjazne dla programistów.

— ThiefMaster

11

Nie głosowałem za głosem, ale to nie jest pytanie, to rant. Vain zdecydował, że nienawidzi JSF, teraz prosi o więcej powodów, aby go nie używać?

— Michael Borgwardt

4

Java jest najlepszym wyborem, jeśli twoja aplikacja będzie duża (złożona i / lub skalowalna) i / lub rozproszona, z wykorzystaniem wielu usług; jeśli twoja aplikacja nie mieści się w tej kategorii (nie jest tak skomplikowana i nie musi być skalowalna), to lepszym wyborem byłyby Python (Django) lub Ruby (Rails). Złożoność JSF ma zalety mocy, z którą się wiąże; jako alternatywę należy spojrzeć na inne frameworki WWW, takie jak Spring MVC lub Struts 2, jeśli Java jest obowiązkowa.

— m3th0dman

14

To jest rant szukający kopii zapasowej, a nie pytanie jako takie.

26

Jest co najmniej jeden bardzo dobry powód do rozważenia JSF.

Jest to standardowa część stosu Java EE i dlatego będzie dostępna - i działa - we WSZYSTKICH kontenerach Java EE przez bardzo, bardzo długi czas. I również utrzymane, bez konieczności robienia tego, jeśli ściśle przestrzegasz specyfikacji Java EE.

Jeśli dotyczy to ciebie, powinieneś to rozważyć. Większość oprogramowania żyje dłużej, niż myślą jego projektanci, zwłaszcza jeśli jest brane pod uwagę podczas pisania.

4

Nie jestem co do tego pewien. W przypadku J2EE słowa „standardowy” i „pracujący” nie są napisane w kamieniu, szczególnie gdy mówimy o systemie, który będzie / powinien być obsługiwany przez wiele lat, w tym zmiany w używanej wersji j2ee.

— magallanes

7

W moim (ograniczonym) doświadczeniu z JSF ten argument faktycznie nie ma zastosowania. Widziałem, jak aplikacje utknęły w jednej wersji JSF i nie ma rozsądnej ścieżki migracji do nowszej wersji. Pewnie, że serwer aplikacji nadal go wykonał, ale dotyczyło to całego wsparcia, jakie można uzyskać, jeśli nie masz dużych pieniędzy na wypłatę na zawyżonych umowach o wsparcie.

— Jens Schauder

@JensSchauder moje doświadczenie polega na tym, że możesz pisać aplikacje przenośne, migrować i aktualizować ich wersje jsf. Wymaga to znajomości specyfikacji i kodowania jej, a nie implementacji. Działa, ponieważ koduje JPA zamiast Hibernacji. Robiłem to od lat.

— ymajoros

14

Jakie są zalety / wady? Jak mogę podkreślić, że nie używam JSF? Jakie są mocne strony, aby użyć JSF w porównaniu z moją sugestią?

Wydaje się, że już podjąłeś decyzję o wadach, a ja muszę zgodzić się z niektórymi z nich (nie dzieli wystarczająco układu i logiki, a wynikowy HTML jest często okropny), ale nie zgadzam się z innymi (jeśli używasz Facelets, które bardzo poleciłbym, to wynik powinien zdecydowanie być ważny).

Oto kilka zalet:

Istnieje kilka bardzo rozbudowanych bibliotek komponentów, takich jak PrimceFaces lub RichFaces, które oferują wiele funkcji od razu po wyjęciu z pudełka. Mogą zaoszczędzić ci dużo pracy, jeśli pokrywają twoje wymagania (nie tyle, jeśli masz nie podlegające negocjacjom wymagania, które nie są nimi objęte).
Kompozytowe komponenty oferują bardzo czysty sposób na modularyzację stron
JSF bardzo dobrze integruje się z resztą Java EE
AJAX poprzez ponowne renderowanie komponentów jest naprawdę łatwy i wygodny

Ale z pewnością żadna z tych zalet nie jest tak duża, że powinieneś używać JSF w stosunku do innych struktur, z którymi Twój zespół ma już doświadczenie.

— Michael Borgwardt
źródło

1

To nie są identyfikatory, to nieprawidłowe atrybuty. Podobnie jak „rola” i „rozwinięta aria” w widoku karty. Czy wiesz jak to naprawić?

— Bruno Schäpper,

1

@Vain: nope, wydaje się być innym problemem, być może z komponentem, którego nie używałem lub który jest nowy. Możliwa jest zmiana danych wyjściowych HTML komponentów JSF poprzez podanie alternatywnego mechanizmu renderującego (który idealnie zastępuje jedną lub dwie metody domyślnego mechanizmu renderującego), ale oczywiście nie jest to coś, co powinieneś zrobić, aby uzyskać poprawny znacznik.

— Michael Borgwardt,

1

Okropny HTML wynika z zastosowanej implementacji. Rozumiem, że tryb debugowania referencyjnej implementacji JSF jest w tym szczególnie zły. Czy znasz lepsze ustawienia do tworzenia lepszego HTML?

1

@ Thorbjørn Ravn Andersen Tak, problem z nieprawidłowym kodem HTML jest w rzeczywistości problemem PrimeFaces. Używamy go, ponieważ jest oparty na interfejsie jQuery-UI. Jaka jest Twoja rada; powinienem użyć innej biblioteki? Naprawdę lubię poprawny HTML. Dla mnie to po prostu MUSI.

— Bruno Schäpper

1

Powracając do mojego pierwszego pytania tutaj, chciałbym podzielić się doświadczeniem na temat twoich profesjonalistów: Współpracujemy z JSF i przy tym doświadczeniu nie wybralibyśmy go ponownie. Prawie wszystko działa zgodnie z oczekiwaniami i jest gotowe. Tak, istnieją potężne biblioteki. Ale ostatecznie sami wykonaliśmy wszystkie nasze komponenty, ponieważ nie działałyby tak, jak tego potrzebowaliśmy. To zadziwiające, jak szybko mieliśmy własny „DataTable” z leniwym ładowaniem podczas przewijania. Kompozytowe komponenty nie działały dla nas, nie mogę powiedzieć dlaczego, są chyba wadliwe. Renderowanie AJAX jest w rzeczywistości kłopotem dla JS po stronie klienta.

— Bruno Schäpper

9

JSF to odpowiedni stanowy framework internetowy dla Javy, który jest standardem, co oznacza, że jest obsługiwany od samego początku przez wielu głównych dostawców (w tym FOSS). Ma silne wsparcie bibliotek zewnętrznych (PrimeFaces, IceFaces itp.). Jednak zasadniczo „zrywa sieć” ze względu na jej stanową naturę (i kilka innych rzeczy). Zobacz porównanie przez Matta Raible'a frameworków internetowych opartych na JVM , JSF zwykle jest bliski końca.

Edycja - za pomocą JSF 2.2 - możesz zacząć argumentować, że nie psuje sieci tak bardzo jak kiedyś. W rzeczywistości integracja z HTML5 nie jest wcale taka straszna :-).

— Martijn Verburg
źródło

1

Rzeczywiście „zrywa sieć”. I dzięki za porównanie Matta Raible'a nie wiedziałem o tym.

— Bruno Schäpper,

3

Zauważ, że JSF niekoniecznie jest stanowy. Zgadzam się, że często tak jest, ale istnieje całkiem niezłe wsparcie dla bezstanowych żądań opartych na GET, a jeśli nie użyjesz formularza, nie będzie żadnego stanu.

— Arjan Tijms

Racja, Arjan, chyba właśnie widziałem wiele stanowych zastosowań.

— Martijn Verburg

Link do prezentacji Raible

— zaidaus

6

Mieliśmy starszą aplikację JSP / Struts 1.0. Ominęliśmy Struts 2, JSF i wszystko inne, co wydarzyło się od Struts 1 i wskoczyliśmy do Spring 3.0. Obsługuje (i aktywną społeczność) naszą listę życzeń - Eclipse IDE, MVC i REST. Poza tym porzuciliśmy naszą klasyczną wersję Javascript / ajax dla jquery.

YMMV, ale Spring był dla nas płynną migracją.

— jqa
źródło