konto usunięte
Temat: JavaServer Faces (JSF) 2.* vs Spring MVC vs Google Web...
WitamOstatnio słyszałem sformułowanie, że Java jest kiepska gdyż siadając do tworzenia serwisu www trzeba odpowiedzieć sobie na masę pytań by wybrać którego frameworka użyć. Może jest to jakiś problem ale jak dla mnie wolę mieć do wyboru multum rozwiązać danego problemu niż być z góry skazanym na jeden. A w związku z tym proponował bym luźną dyskusję jaki dla was framework webowy spisuje się najlepiej. Wiem, że to zależy od środowiska, zastosowania i odbiorcy dlatego postaram się sprecyzować temat. Powiedzmy, że tworzymy spory portal podobny do Facebook-a. Jakiego frameworka byście użyli ?
Proponuję porównanie 4 frameworków jak w temacie (wydaje mi się, że jednych z napopularniejszych).
JSF
Plusy(+)
Oracle wybrało JSF jako podstawową technologię dla widoku dla JEE. Wnioskować po tym można, że będzie kładziony duży nacisk na jego rozwój i może pojawić się wiele ciekawych rozwiązań. Patrząc po wstępnych wersjach JSF 2.2 to Flow Faces zapowiada się całkiem całkiem.
Faclety – mi się osobiście podoba sam pomysł templateów. Dzięki temu nie trzeba powielać kodu.
Wiele gotowych elementów za którymi w wielu przypadkach stoją molochy technologii. Np. richfaces, primefaces, icefaces itd…
Razem z managed beans i CDI stanowią fajny zespół. Oczywiście jest tu jeszcze wiele do zrobienia acz kolwiek np. gdy potrzeba nam coś trzymać dla to robi się to banalnie.
Konwertery – bardzo podoba mi się pomysł definiowania konwerterów. Bez problemu mogę przygotować konwersję danych wprowadzanych przez user-a i zamieniać je tak jak chcę.
Walidatory – to samo co wyżej. Weryfikacja poprawności pola, dopięcie jej do komponentu itd… Moim zdaniem, bardzo fajny pomysł.
Bez problemu radzi sobie z Spring Security itd…
Znalazł się także w Spring Roo dla primefaces
Minusy(-)
Jak na razie trochę kulejące wsparcie dla HTML5 ale podobno ma być to poprawione w JSF 2.2
W przypadku bardziej zaawansowanych komponentów, których nie znajdziemy w gotowcach chyba łatwiej jest zrobić kawałek JQuery niż naciągać pod swoje potrzeby istniejące komponentu.
Dosyć dużo kodu. Wiele elementów można by uprościć by nie wymagały tyle kodu.
Jeśli nastawiamy się na CDI to potrzebujemy już serwera aplikacji.
Jeszcze taki mały minusik (nie wiem czy do JSF ale skoro mam podjąć decyzję jaki framework to jest to na minus). Osobiście korzystam z JetBrains IDEA i rozmawiałem z ludźmi z JetBrains na temat JEE 7. Wsparcie dla JEE 7 będzie dopiero w wersji 13, która będzie wydana pod koniec 2013 roku. Tak więc jeśli chcecie korzystać z HTML 5 i flow faces to albo trzeba się przenieść na NetBeans (jest wersja developerska wspierająca wstępną wersję JEE 7) albo poczekać do końca 2013.
Spring MVC
Plusy(+)
Korzystanie z wszelkich dobrodziejstw Springa
Web flow
Spring roo i podstawowa aplikacja gotowa. W przypadku małych prostych zleceń oszczędza masę czasu od formatek począwszy a na bezpieczeństwie skończywszy.
Minusy(-)
Brak gotowych kontrolek typu rich text editor. Trzeba napisać samemu.
Oparty na JSP. Moim osobistym zdaniem Oracle będzie mniej przychylne do rozwoju JSP idąc bardziej w kierunku JSF-a.
GWT
Plusy(+)
Dynamiczne generowanie elementów.
Możemy zrobić szablon w HTML-u a do niego wpinać GWT-owe elementy.
Kwestia szablonów tu pojawia się w innym kontekście. Można by powiedzieć, że dynamicznie zmieniamy kawałek strony, który nas interesuje (lub np. zastępujemy go innym) a wszystko bez ruszania reszty strony.
Walidacja po stronie klienta. Robi się to genialnie.
Wspierane przez Spring Roo.
Minusy(-)
Z racji, że ogólnie latamy po RPC to odpadają nam takie rzeczy jak lazy loading a dochodzą DTO. Trzeba dodatkowo porównywać obiekty gdy wracają na serwer.
Nie zgrywa się tak dobrze ze Spring Security i innymi rozwiązaniami do bezpieczeństwa co Spring MVC i JSF.
Mało gotowych komponentów a i ponowne użycie własnych nie jest za specjalnie wygodne.
Jeśli chcesz mieć możliwość dodawania do ulubionych (URL) to wymaga to dodatkowych zabiegów.
Gdybyśmy chcieli użyć jQuery to jest taka możliwość ale nie wymaga to troszkę roboty.
Play Framework
Plusy(+)
Dynamiczne przeładowywanie klas. (Można by powiedzieć, że taki okrojony JRebel za free)
Bardzo fajnie zrobione template. O wiele mniej złożone niż w JSF co nie odbija się na ich funkcjonalności.
Proste generowanie wstępnego kody, testy, przełączanie między wersją deweloperską a produkcyjną.
Minusy(-)
Z tego co wiem to brak możliwości wykorzystania spring security. Ma oczywiście własny mechanizm zabezpieczeń ale nie ma jeszcze tyle możliwości co Spring Security.
Brak gotowych komponentów.
Podsumowanie
Zapraszam wszystkich do wypowiedzi. Jeśli mieli byście dziś przepisać Facebook-a na Javę to jaki framework wybrali byście i dlaczego lub jaki na pewno byście nie wybrali i dlaczego. Dla mnie osobiście Play odpada z racji, że jestem zbyt przywiązany do dobrodziejstw, które daje spring. W potyczce JSF z Spring MVC wybrał bym JSF z racji, że są bardzo podobne do siebie (w JSF mogę użyć tego co w Spring MVC) a dodatkowo wiele gotowców do szybkiego wytwarzania i sądząc po ruchach Oracle to mam wrażenie, że to czegp brakowała w Java EE i zostało dodane przez Spring-a teraz jest uzupełniane np. przez CDI itp. Oczywiście do Spring-a jeszcze trochę brakuje ale sądzę, że idzie to w kierunku by wszystko co potrzebne znalazło się w JEE bez potrzeby bibliotek z zewnątrz. Co do GWT to daje naprawdę fajne możliwości i bardzo fajnie sprawdza się przy wielu aplikacjach natomiast nie wybrał bym go do realizacji FB. Jeśli ja miał bym dokonać takiego wyboru to dla widoku wybrał bym:
JSF 2.1-2.2 (Jeśli nie Flow Faces to Web Flow)
Managed Beans
CDI
HTML5
CSS3
JQuery
Primefaces
W reszcie użył bym Spring-a, Hibernate itp.. Postawił bym to na GF 4 z racji, że on będzie pierwszym serwerem aplikacji, który będzie wspierał JEE 7.