W pracy siedzi dzwóch kumpli aż w końcu jeden postanowił zapytać drugiego.
- Ej Ty! Po której jesteś stronie ?
A ten odpowiedział:
- Serwera!
[Java + GWT] Horrible
Jako programista miałem jakieś 1,5 roku temu przyjemność, albo raczej nieprzyjemność (wyjaśnie w dalszej części posta) poznania technologii GWT co oficjalnie oznacza Google Web Toolkit. W wielkim skrócie polega to na tym, że piszemy w większści w javie i raczej nie wiele jest plików jsp css js. Zwłaszcza tych ostatnich ponieważ kod JAVA jest kompilowany do JavaScript.
Najcześciej argumentem przeważającym wybór technologii jest między innymi to że w plikach konfiguracyjnych możesz określić na ile silnikow przeglądarek chcesz kompilować. Czas kompilacji jest tym dłuższy im wiecej jest silników przeglądarek.
Biblioteki takie jak GWT, GXT, framework MVP4G zawierają odpowienio mechanizmy i komponenty ktore mają ułatwiać i szybciej tworzyć aplikacje webowe oparte o GWT.
Do komponentow tych należą comboboxy (select w html) inputy konkretnych typów takich jak TextField, NumberField, itp.
Osobiście na początku nie przeszkadzało mi w tym nic, prócz czasu kompilacji i uruchomienia serwera podczas tworzenia aplikacji z tutoriala.
Kolejnym dużym zaskoczeniem był czas kompilacji w projekcie dość rozbudowanym nad jakim pracowałem zawodowo. Potem po jakimś czasie zaczęło mi to naprawdę przeszkadzać, a potem już tylko denerwować. Nie znam wszystkich projektów w świecie opartych o GWT, ale te dwa, które poznałem wykorzystują dodatkowo framework Spring. Nie znając innych frameworkow wydawało mi się, że spring jest genialny. Aż przeszedłem do zupełnie nowego i lekkiego projektu opartego o Spring MVC. Byłem mile rozczarowany ile rzeczy można prościej zrealizować.
Przede wszystkim w tym nowym projekcie było coś co zawsze rozwija i co bardzo lubię. Separacja plikow .css .js .jsp (zawierających html) i .java. Nie chodzi tu o samą separację, bo w projektach GWT też pliki były odseparowane, ale bardziej chodzi mi o to, że zaczynasz mieć większą kontrolę nad kodem który tworzysz a przede wszystkim dotykasz plików, króre w technologiach webowych i wszelkich podstawach tworzenia stron WWW są kluczowe i bardzo rozwijające. Zwłaszcza że tworzymy już w HTML5!
Uważam za największą przyjemność tworzenie i modyfikcję plików CSS JS HTML osobno, ponieważ efekt zmian jest automatyczy po odświerzeniu przeglądarki co powoduje krótszy czas realizacji oraz daje przyjemność z tego że od razu możesz zobaczyć to co napisałeś i czy działa / wygląda tak jak tego oczekiwano.
Lubie patrzeć na efekty swojej pracy a nie oczekiwać minuty i godziny na kompilacje a potem jeszcze na np. restart servera tomcat jak to jest w przypadku GWT. Jeśli liczy się czas wykonania zadania uważam, że java i cały Spring jest zbyt ciężkie w połączeniu z GWT albo z wadliwym GXT czy nieźle pojechanym MVP4G. Jeszcze nie miałem okazji poznać Vaadina, ale na samą myśl, że jest to oparte o GWT już mi się źle robi.
Inne nieprzyjemności wynikające z korzystania z GWT to :
- Kodu JS skompilowanego przez GWT nie jest sie w stanie wydebugować w przeglądarce. HTML wygenerowany przez GWT jest bardzo skomplikowany i nie jest łatwy w debugowaniu. Chyba ze kazdemu komponentowi przypiszesz id lub klasę. Ale w dwóch projektach z którymi miałem styczność nikt o to nie dbał.
- Do debugowania kodu klienta musisz używać devmode jednak wymaga on uruchomieniu serwera a potem podpina sie pod kod.
- Zmiana interfacu na klasach wymaga kompilacji. Kolejna strata czasu. (nowe metody, klasy itp.)
- Metody komponentów nie działają wedle życzenia. Np. W Comboboxie są chyba metody setValue setFieldValue i setRawValue()
W tak przygotowanym interfasie nie wiesz ktorej z metod użyć a takich kwiatków jest więcej. - Programując w GXT musisz znać podatawy, że ładowanie do comboboxa danych wywoływane jest asynchronicznie poprzez jakiś loader o ktorym też musisz wiedzieć. Wybranie jednego rekordu z listy wymaga nadpisania metody ładującej bo inaczej domyślny mechanizm nie załaduje Ci opcji z selecta.
Dlaczego trzeba mieć tak ogromną wiedzę do tego wszystkiego ? Musisz wiedzieć o isnieniu loadera, proxy, Rpc, asyncCallback, Interfaceach servisow i ich implementacji i asynchronicznych wersji interface'u. - W GWT i GXT musisz cały czas liczyć pixele. Bawić się wysokością i znów masz metody setHeight() setSize i setMinHeight() którą z nich wybrać?
- Zanika twoja choćby najmniejsza umiejętność pisania w JS i przestajesz sie rozwijać. Tracisz umiejętność lub wiedzę na temat komunikacji z Http, bo wszystko robisz w javie. Nawet jak stworzysz serwlet czy kontroller w springu to i tak nie masz pelnego odwzorowania.
- Jeden kod na wszystkie przeglądarki to mit ponieważ są momenty w których musisz stosowac hacki takie jak konstrukcje sterujące if (IE) {...} else if (Chrome) {...} itp.
- Często zdarzają się problemy z renderowaniem widoku czy problemy behavioralne z w działaniu aplikacji których przyczyną jest GWT lub GXT nie z winy programisty użytkownika. W takich chwilach trzeba zastosować jakiś workaround albo przegrzebywać klasy GXT i override na metodę, która akurat zapomniała czegoś wykonać.
- GWT wymaga sporej mocy obliczeniowej i zajmuje dużo pamięci. Im więcej rdzeni i RAM tym kompilacja i uruchomienie staje się łatwiejsze. Strasznie jest zasobożerne i często trzeba zmagać się z ustawianiem parametrów na tomcacie, w argumentach GWT itp.
- Aktualność - tu straszna lipa. Wychodzą coraz nowsze wersje przeglądarek. Np. Firefox, do którego należy instalować coraz to nowszy plugin GWT a często jest tak że najnowszej wersji pluginu GWT nie ma. Jesli potrzebujesz uruchomić devmode to lepiej nie aktualizuj FireFox'a.
Oto 11 powodów dla którch technologię GWT uznaje za naprawdę uciążliwą. Odradzam wszystkim i już nigdy nie wrócę do tej technologii. Reasumując nazywam to Gówno Wartą Technologią!
Z całym szacunkiem do Google, ale naprawdę wydaje mi się to strzałem w stopę. Dziś zamiast aplikacji okienkowej w przeglądarce modny i godny polecenia jest Twitter Bootstrap. Sam go używam zarówno w projekcie zawodowym jak i prywatnym :-)
Osobiście wolę wyrwać sie z Javy i iść w stronę PHP, bardzo przyszłościowym JS, HTML5 i w końcu poznać Pythona ! To są języki którymi warto się zainteresować!
Polecam i jeśli macie jakieś argumenty za i przeciw zachęcam do komentowania :-)
Subskrybuj:
Posty (Atom)