news

Wczoraj na Google Campfire One został oficjalnie zaprezentowany Google Web Toolkit w najnowszej wersji 2.0. Nowości i zmian jest naprawdę sporo, a jedną z istotniejszych jest wprowadzenie narzędzia Speed Tracer.

Speed Tracer jest dodatkiem do przeglądarki Google Chrome, który umożliwia analizę wydajnościową aplikacji webowych (nie tylko tych tworzonych w GWT). Speed Tracer pozwala na bardzo dokładne przyjrzenie się działającej aplikacji, wliczając w to np. obserwację zdarzeń JavaScript’owych. Zamiast wymieniać następne funkcjonalności narzędzia Speed Tracer, lepiej obejrzeć krótki (1:40) tutorial, gdzie wszystko jest bardzo ładnie pokazane. Warto zwrócić uwagę na naprawdę rewelacyjny interfejs aplikacji (zrobiony oczywiście w GWT ).

Myślą przewodnią nowej wersji GWT są szybsze aplikacje webowe. Szybsze zarówno w sensie szybkości ich działania, jak i szybkości developmentu. Lista zmian i nowości jest naprawdę duża. Zwrócę więc uwagę tylko na te najważniejsze (moim zdaniem).

Wersja 2.0 zdecydowanie poprawia cykl edycja/odświeżenie przez wprowadzenie tzw. development mode, który pozwala uruchomić w trybie debug projekt GWT w dowolnej przeglądarce, a nie jednej, dedykowanej (jak to było wcześniej). Oznacza to, że nareszcie można używać Firefoksa albo Chrome’a przy tworzeniu aplikacji GWT, a wraz z nimi -- pakietu ulubionych rozszerzeń na czele z Firebugiem . Nie obeszło się przy tej okazji bez zmiany Google Plugin for Eclipse, którym teraz można całkowicie kontrolować development mode z poziomu naszego ulubionego IDE . Jeszcze trochę z ciekawostek: development mode działa przez sieć. Można więc “przypiąć się” do zdalnej sesji przeglądarki. Wydaje się to szczególnie przydatne dla Linuksiarzy, którzy mogą tylko zgadywać jak wygląda ich aplikacji w IE pod Windows. (Nawet z GWT pewnych rzeczy się nie przeskoczy…)

Kolejna wielka zmiana, która dla mnie osobiście wydaje się być szalenie interesująca, to wprowadzenie nowego, deklaratywnego sposobu konstruowania interfejsu użytkownika o nazwie UiBinder. Założenie jest takie, by uczynić łatwą (a przy okazji trochę wymusić) separację warstwy widoku od logiki aplikacji. Pomysł polega na tworzeniu dwóch plików dla każdego komponentu warstwy prezentacji. Aspekty widoku zawarte są w pliku .ui.xml, który stanowi “mieszankę” normalnego HTML’a oraz komponentów widoku (ang. widgets). Sama implementacja logiki aplikacji pozostaje natomiast w osobnym pliku .java. Pozwala to na bardzo wyraźną separację tych dwóch zagadnień i np. bardziej efektywną współpracę programistów oraz web designerów. Dodatkowo, w czasie kompilacji sprawdzane są wszystkie referencje między powyższymi plikami, więc nie ma mowy o żadnych literówkach i tego typu błędach. Naturalnie, Google Plugin for Eclipse wspiera to rozwiązanie w 100%, wliczając refactoring, uzupełnianie kodu itd.

Najnowszy Google Web Toolkit wprowadza również tzw. layout panels, pozwalające na dokładne rozmieszczenie elementów w obrębie strony. Nie ma co ukrywać, że używając HTML i CSS jest to duży problem, który najczęściej wymusza użycie pewnych “sztuczek”. Nawet we wcześniejszych wersjach GWT czasami trzeba było pokombinować, żeby coś wyglądało tak jak trzeba we wszystkich przeglądarkach. Nowe rozwiązanie bazuje tylko na standardzie CSS, co ma dać layout nie tylko bardziej stabilny i przewidywalny, ale również szybszy (znane są dość spore problemy wydajnościowe przy zmianie rozmiaru okna przeglądarki we wcześniejszych wersjach GWT). Layout panels, jak łatwo się domyślić, doskonale sprawdzają się w połączeniu z UiBinder.

Kluczową nową funkcjonalnością w GWT 2.0 jest programowe rozdzielanie kodu (ang. code splitting). Polega to na wskazaniu (w kodzie źródłowym), które komponenty muszą być wczytane “z góry” i są konieczne do załadowania aplikacji, a które można doczytać chwilę później. To tak trochę jak oglądanie filmu na YouTube: nie trzeba przecież wczytać całości, żeby rozpocząć oglądanie. Moim zdaniem to świetne rozwiązanie. Mamy do czynienia przecież z aplikacjami webowymi; tutaj nie może być poczucia, że coś jest “instalowane”. Taką aplikację otwieramy i już ma być; każąc użytkownikowi czekać 15 sekund na pojawienie się pierwszego ekranu, możemy go łatwo stracić. Świetne wyniki tutaj uzyskał zespół Google Wave. W chwili obecnej skompilowana, pełna funkcjonalność tej aplikacji to “ważący” prawie 1500 kB JavaScript, który trzeba przecież ściągnąć od razu. Dzięki zastosowaniu rozdzielania kodu, początkowo użytkownik ma do pobrania 200 kB (a po kompresji już tylko 80 kB), a reszta jest “dociągana” w czasie, gdy zastanawia się gdzie by tu kliknąć. Różnica właściwie o rząd wielkości! Częściowo zasługa w tym również nowej wersji kompilatora, który tak czy inaczej “odchudza” kod nawet o ponad 20%. Można bez problemu skompilować starsze aplikacje. W moim ostatnim projekcie w GWT dało to oszczędność 14% (właśnie sprawdziłem ) tak po prostu, bez dotykania kodu źródłowego.

Z mniejszych zmian, nastąpiło ulepszenie mechanizmu paczek (ang. bundles). Teraz zamykać w paczki można nie tylko grafiki, ale pliki dowolnego rodzaju. Jest również specjalny rodzaj paczki dla plików CSS, który automatycznie optymalizuje dołączone arkusze stylów.

Podsumowując, GWT 2.0 wydaje się być znaczną aktualizacją tego produktu. Poprawiono zarówno efektywność pracy z technologią (co w konsekwencji zmniejsza koszt tworzenia oprogramowania), jak i wydajność samych aplikacji. Google Web Toolkit niewątpliwie potwierdza swoją mocną pozycję na rynku nowoczesnych technologii front-end’owych dla aplikacji webowych. Dla mnie osobiście, jest to już od dawna faworyt w tej kategorii, który coraz bardziej rośnie w siłę. Gorąco zachęcam do pobrania nowej wersji biblioteki i przyjrzenia się wprowadzonym zmianom. Zainteresowanych kieruję na stronę produktu.