Spór o skrośne kompilatory: GWT przyszłością aplikacji webowych?

Kilka dni temu Bob Balfe z firmy IBM na łamach swojego bloga postawił dość mocną tezę o tym, że Google Web Toolkit jest przyszłością programowania aplikacji webowych, ponieważ przynosi bezpieczną typizację, pozwala wykorzystać istniejące umiejętności programistów Javy i ma wbudowane fajne widżety. Twierdzenie to jednak nie wszystkim się spodobało i wywołało ciekawe głosy krytyczne.

Jak wiadomo, Google Web Toolkit to skrośny kompilator Javy do JavaScriptu, który pozwala na tworzenie ajaksowych aplikacji, nie wymagając od dewelopera jakiejkolwiek znajomości tej technologii. Po napisaniu kodu w Javie, GWT przetwarza część kliencką na JavaScript, HTML i CSS, zaś część serwerowa zostaje skompilowana do serwletu Javy, gotowego do uruchomienia na serwerze aplikacyjnym. Zaletą takiego rozwiązania jest znacznie łatwiejsze wykrywanie błędów, oraz uwolnienie się od zmory dopasowywania aplikacji do poszczególnych przeglądarek – o wszystko zadba już framework.

Możliwości GWT są naprawdę duże – zrobiono w nim aplikacje takie, jak Gmail, a ostatnio Google Wave. Czy jednak oznacza to, że deweloperzy powinni brać się za solidną naukę Javy i liczyć, że google'owe narzędzie przerobi je na aplikację uruchamianą w przeglądarce? William Shields, australijski deweloper, który specjalizuje się właśnie w Javie – więc trudno go podejrzewać o jakąś niechęć wobec języków o statycznej typizacji – uważa, że GWT w żadnym stopniu nie stanowi przyszłości dla tworzenia aplikacji webowych. Oto streszczenie jego argumentów:

Dynamiczna typizacja nie jest niczym strasznym. Pierwszym popularnym językiem o dynamicznej typizacji był Perl, który rozpowszechnił się wśród uniksowych administratorów w latach '90 zeszłego wieku – w czasach gdy niepodzielnie jeszcze rządziły C i Java. Choć koncepcja swobodnego zmieniania typów zmiennych, albo porzucenia konieczności ich deklarowania była wówczas herezją, to jednak przyjęła się nieźle – dzięki realnym korzyściom, jakie Perl dawał na maszynach o niewielkiej mocy. Nic strasznego wraz z proliferacją Perla, a później PHP, Pythona czy Ruby'ego się nie stało.
Jak chcesz napisać podręcznik po niemiecku, nie piszesz go wpierw po angielsku, a potem tłumaczysz na niemiecki. Niektórych rzeczy nie sposób przetłumaczyć – zarówno w językach ludzi, jak i maszyn. JavaScript ma wiele własności, których brak Javie – domknięcia, anonimowe obiekty, metody rozszerzenia. Skrośne kompilatory napotykają ten sam problem, co wykorzystanie ORM-ów – niezgodność impedancji. Regularnie marnuje się wiele czasu na ustalenie, która to kombinacja parametrów i własności wygeneruje odpowiednio wydajną kwerendę SQL-a. GWT „wmawia” zaś naiwnym deweloperem, że nie muszą uczyć się JavaScriptu. Co więcej, GWT traktuje JavaScript jako bug, który trzeba naprawić.

«poprzednia 1 2 3 następna »

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

15 skomentuj »

Komentarze

#1 tomekk 2009-10-30 08:09:11 0
Ten spór przypomina mi spór o wyższości assemblera nad kodem w C, czy późniejszej wyższości C nad kodem w Java/C#. Każde podniesienie poziomu abstrakcji powodowało zmniejszenie szansy optymalizacji etc. (a w zasadzie przerzucenia jej na kompilator) Jednak w 99.9% aplikacji wynik generowany przez kompilatory jest zadowalający a jakość kompilatorów z upływem czasu się poprawia. Finalnie jakość generatów osiąga poziom złożoności optymalizacji niemożliwy do ręcznego utworzenia.

Dziś mało kto koduje w asseblerze (nie mówię tutaj o sterownikach ale zwykłych aplikacjach), a coraz więcej aplikacji desktopowych napisanych jest w Java lub C#.

GWT to rewelacyjna biblioteka. Moim zdaniem pozwala ona na kolejny duży skok. Przekształcenie statycznych stron WWW z odrobiną JavaScriptu w prawdziwe złożone aplikacje. Wystarczy porównać wygodę obsługi dynamicznej aplikacji jaką jest GMail z klientami pocztowymi z przed kilku lat o obcją 'odśwież' etc.

Myślę że dzięki GWT wchodzimy w nowy etap: 'aplikacje webowe' zamiast 'strony www'. GWT to kluczowa technologia by idea systemu internetowego Google Chrome OS miała sens. Java pozwala na stworzenie zdecydowanie bardziej rozbudowanych aplikacji niż to jest możliwe w JavaScript (problem z opanowaniem dużych ilości kodu).

Nie trzeba chyba nikomu mówić że pod Google Chrome (a dokładniej pod silnikime V8) aplikacje wygenerowane przez Google GWT działają kilkukrotnie szybciej niż pod innymi silnikami jak TraceMonkey (Firefox). Google posiada idealny zestaw. Kompilator piszący i optymalizujący kod JavaScript oraz silnik który go wykonuje. Tym samym Google Chrome staje się niejako maszyną wirtualną dla kodu Java (z JavaScript po drodze jako warstwa pośrednia)

Google GWT + Google Chrome V8 :)
IP: 90.156.104.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#2 jaaa 2009-10-30 10:32:09 0
Popieram tomekka. Wyższy poziom abstrakcji to przejrzystszy kod, mniej błędów i większa wydajność tworzenia oprogramowania.

Napisanie bardzo dużej aplikacji w samym javascripcie wydaje mi się (prawie) niemożliwe. Niewiele firm podjąłby się takiego ryzyka biznesowego.

Z rozwiązań w javie polecam doskonały framework wicket. W przeciwieństwie do GWT nie ma kompilacji, a javascript generowany jest "w locie"

http://wicket.apache.org/
IP: 85.222.104.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
#3 sudlik^® 2009-10-30 18:56:19 0
Zastanawiam się jak się odnieść do argumentu "Idiomatyka".

Chodzi mi o kwestię programowania zorientowanego obiektowo w PHP, czy rzeczywiście lepiej posługiwać się paradygmatem skryptowym (+ funkcyjnym) w tym języku.
IP: 77.255.71.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
#4 apohllo 2009-10-31 00:15:38 0
@tomekk: Porównywanie różnicy pomiędzy JavaScriptem a Javą do różnicy między assemblerem a C, jest dla mnie najdziwniejszym rzeczą pod słońcem. JavaScript pod pewnymi względami (jako język) jest na wyższym poziomie abstrakcji niż Java (np. wspomniane w artykule domknięcia, czy dynamiczna typizacja) - tzn. to samo co w Javie, można osiągnąć w JS pisząc mniej kodu. Rożnica nie bierze się z języka, lecz niekompatybilności jego implementacji i "bogactwa" widgetów GWT.

Jeśli ktoś jednak zakosztował rozwiązań typu jQuery, Prototype, albo całych frameworków takich jak Ruby on Rails, czy Django, nigdy nie będzie twierdził, że kod w Javie jest na wyższym poziomie abstrakcji - bo jest dokładnie przeciwnie. I taka jest teza artykułu. Jeśli ktoś wątpi, nich napisze aplikację korzystającą z Google Maps API bezpośrednio w JS (z wykorzystaniem np. Prototype + Ruby on Rails) vs. w GWT - stawiam skrzynkę piwa, że w tym pierwszym wypadku kodu będzie o 30% mniej.

Swoją drogą dziwi mnie fakt, że Google, którego pierwsza wersja wyszukiwarki powstała w Pythonie, postawił na Javę, język bardzo nieobiektowy i nieelegancki.
IP: 83.230.47.[...] Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090914 Gentoo Firefox/3.5.2
#5 apohllo 2009-10-31 00:17:28 0
"różnica nie bierze się z języka" - miało być "różnica we względnej efektywności pisania nie bierze się z języka"
IP: 83.230.47.[...] Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.2) Gecko/20090914 Gentoo Firefox/3.5.2
#6 hipertracker^® 2009-10-31 07:16:08 1
@apohllo, Google wie co robi. Java to nie tylko język, to głównie bardzo dobra platforma z b. wydajną maszyną wirtualną. A samych języków do JVM jest ponad 240 języków. Nie potrzeba używać składni języka Java aby używać platformy Javy. Równie dobrze można użyć Scali, Clojure czy nawet JRuby.

Jak się domyślam, głównym celem GWT jest nie elegancja i minimalizm kodu JavaScript ale możliwość budowania skomplikowanych aplikacji webowych z wykorzystaniem dopracowanych narzędzi dla Javy do analizy, refactoringu czy debugowania kodu.

Chyba z podobnych powodów Lift (komponentowy, webowy framework napisany w Scali) czyni podobnie. Cała warstwa klienta, włącznie z Ajaksem, odwrotnym Ajaksem (Commet) i w ogóle wywołaniem HTTP jest zasłonięta przez framework umożliwiając pracę z aplikacją webową (bezstanową z definicji) tak jak ze stanową, aplikacją desktopową. Podobne podejście jest też w smalltalkowym frameworku Seaside.
IP: 78.16.214.[...] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; pl; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4
#7 java 2009-10-31 13:52:20 0
@apohllo

" postawił na Javę, język bardzo nieobiektowy i nieelegancki"

Chodziło ci pewnie nie o Javę która jest oczywiście w pełni obiektowa a o Java Script (ludzi często to mylą).

Przyznam się że też mnie dziwi dlaczego Google postawiło na JavaScript pisząc własną przeglądarkę i system operacyjny. JavaScript to język nieobiektowy, nieprzejrzysty i o praktycznie zerowej wydajności. Kompilacja JavaScript to trochę jak wyciąganie trupa z szafy. Moim zdaniem Google powinno zintegrować swój system oraz przeglądarkę z JVM i dodać api Javowe do modyfikacji struktury DOM.

Wykorzystywanie w tym celu JavaScriptu zmusza firmę do napisania własnego interpretera z kompilacją w locie do C, bibliotek GWT do kompilacji normalnych programów do JavaScript etc. Mnóstwo pracy dla idei.
IP: 90.156.104.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#8 java 2009-10-31 14:10:18 0
Słowo "Google" w nawiasach kwadratowych przekształciło całą treść w jedno wielkie zapytanie. To chyba jakiś błąd w obsłudze komentarzy.
IP: 90.156.104.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#9 slawek22 2009-11-02 01:49:25 0
@apohllo: java nieobiektowa i nieelegancka. Również ja odnoszę takie wrażenie.

Dla mnie to właśnie java to taki dzisiejszy assembler. Okropnie toporna, z mnóstwem często powtarzanych konstrukcji przeznaczonych do wykonania najprostszych czynności. Głupi odczyt pliku w javie można zrobić chyba na kilkadziesiąt sposobów.

To ma się nijak do lekkości javascriptu, dziedziczenia prototypowego, automatycznej konwersji typów, domknięć czy modyfikacji metod na każdym etapie działania skryptu.

Kiedy widzę jak łatwo w JS operować stringami, tablicami asocjacyjnymi czy nawet całymi klasami to napisanie czegokolwiek w Javie to prawdziwa katorga.
IP: 79.185.220.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#10 GWT 2009-11-06 12:03:45 0
GWT Rox !!!
IP: 193.178.240.[...] Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/532.3 (KHTML, like Gecko) Chrome/4.0.223.11 Safari/532.3
#11 Mikołaj 2009-11-07 22:00:38 0
@Sudlik mnie też zdziwił ten argument "Idiomatyka"

Głupota na głupocie. Wg. autora OOP jest tylko modnym sloganem o.O Albo, że PHP nie jest językiem zorientowanym obiektowo. Zorientowany obiektowo to może być kod, a język może tylko dostarczać odpowiednich struktur do tworzenia obiektowo zorientowanego kodu. I PHP (przynajmniej od wersji 5) takich dostarcza.

Jeszcze sprawa dynamicznej typizacji, która to przyczyniła się do optymalnego działania aplikacji w perlu na komputerach o słabej mocy.? Kurde ja to zawsze myślałem, że dynamiczna typizacja wymaga więcej zasobów..chyba szybciej można porównać dwie zmienne wiedząc z góry, że obie to liczby chociażby..
IP: 83.31.101.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.15) Gecko/2009101601 Firefox/3.0.15 GTB6 (.NET CLR 3.5.30729)
#12 slawek22 2009-11-07 22:35:00 0
Chyba źle zrozumiałeś wątek o dynamicznej typizacji w Perl.

Nie chodzi o to, że program szybciej ma się wykonywać, tylko o to, że dużo szybciej można go napisać, a dynamiczna typizacja nie spowalnia w znaczący sposób jego działania.

Na serwerach wydajność nie jest taka ważna. Za godzinę pracy dobrego programisty czy admina możesz wydzierżawić serwer na cały miesiąc. Teraz odpowiedz sobie na pytanie: lepiej pisać o 2 ms szybsze skrypty w C poświęcając na to 2 tygodnie, czy w 10 minut zrobić to samo w Perlu?

>Głupota na głupocie PHP nie jest językiem

>zorientowanym obiektowo.

A co powiesz na to, że w niektórych językach prawie wszystko jest obiektem a cała biblioteka standardowa jest zrobiona na klasach? W PHP nie masz ani jednego ani drugiego. Nawet tak podstawowa sprawa jak obsługa stringów to luźne funkcje.
IP: 83.10.77.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/3.0.195.27 Safari/532.0
#13 poczatkujacy uwodziciel bez sukcesow 2009-11-07 23:42:20 0
1. javascript jest jezykiem obiektowym. tylko skladnia jest odmienna niz w javie stad niektorym moze sie wydawac inaczej :).

2. tak naprawde javascript jest jezykiem niesamowicie zwinnym i poza c++ poki co nie spotkalem niczego co by dawalo wieksze poczucie ze "inteligencja jest potrzebna" :).

3. java to jezyk "biznesowy" - a wiec umozliwiajacy pisanie duzych aplikacji przez zespoly o zroznicowanym poziomie kwalifikacji. i dlatego zdziwilbym sie gdyby jakakolwiek duza firma (a taka jest google) pozwolila sobie go zignorowac.

4. python w google jest uzywany jako "jezyk frontu" - zas engine to c++. i tak bylo od poczatku.

5. innowacyjny kod powstaje w c++. w javie pisze biznesowa infrastrukture - nie odkrywcza ale przynaszaca powazne zyski - chyba juz latwo zgadnac gdzie na rynku pozycjonuje sie gwt - duze ale schematyczne aplikacje ajaxowe pisane przez slabo zmotywowane hordy programistow w korporacjach ;)
IP: 188.33.53.[...] Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
#14 GWTApp 2010-07-18 15:03:43 0
Tworzenie aplikacji w GWT za pomocą szablonów HTML zamiast tworzenia wszystkich elementów okienek na wzór Java Swing - http://gwtapp.org/
IP: 83.27.147.[...] Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4
#15 beastieboy 2011-05-03 21:20:54 0
Bylo kiedys takie powiedzenie, ze jak ktos chce i lubi to moze przejsc quake z toporkiem w reku w single player. Panowie, javascript jest jezykiem drugiej kategorii ze wzgledu na niezgodnosc przegladarek i standardow. Zawsze tak bylo, moze kiedys sie to zmieni, ale komu bedzie cie chcialo juz wtedy w tym cos pisac... Nikt tworzacy aplikacje biznesowa z gui uzywajacym wstawek w javascript, nie wywinie sie z napisania javascriptu dla ie, niezaleznie od tego jakim bylby fanem ff czy chrome. Chyle czola przed ludzmi z google za stworzenie gwt. Na google io 2009 pokazali czego mniej wiecej uzywaja u siebie z gwt - wzorzec mvp i command pattern dla obslugi rpc. Uzycie tych dwoch wzorcow w tworzonym od podstaw projekcie zalatwia wiekszosc bolaczek jakie do tej pory mieli ludzie probujacy w tym pisac. Mozna uwolnic sie w koncu od dziesiatek (setek) metod service, projekt gwt jest latwy do podzielenia na moduly (uff...) i tym samym miedzy pracownikow, kod przejrzysty i latwy do utrzymania. Aplikacja inicjuje sie wreszcie w sensownym czasie (code splitting). Najbardziej rozbawil mnie tutaj argument o czasochlonnosci kompilacji. W poprawnie skonfigurowanym projekcie gwt wystarczy zapisac edytowany plik z kodem java i wcisnac ctrl+f5 w przegladarce...
IP: 89.75.188.[...] Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.