Kiedy nie korzystać z Google Web Toolkit? [Zamknięte]

55

Rozważam użycie GWT w dużym wewnętrznym projekcie rozwoju aplikacji internetowych, a mianowicie jego główną zaletą jest kompilacja krzyżowa do Javascript, która (przynajmniej teoretycznie) pomogłaby mojemu zespołowi zmniejszyć rozmiar stosu technologicznego o jeden .

Jednakże, będąc wcześniej spalonym (jak większość programistów), chciałbym usłyszeć od programistów, którzy faktycznie używali go w przypadku jakichkolwiek problemów z GWT, które mogłyby utrudnić lub ograniczyć jego użycie w określonej dziedzinie problemów.

Jakie są argumenty przeciwko używaniu GWT i dlaczego?

Jas
źródło
11
Myślałem, że GWT zmarł.
Aaron McIver
1
@Aaron, naprawdę?
Jas
10
Nie polecam GWT osobiście. Sposób myślenia zmusza cię do pracy w aplikacjach komputerowych, ale sprawi ci problemy podczas próby myślenia w ten sposób w funkcjach HTML. Jestem fanem dopasowywania paradygmatu kodowania do aktualnego problemu, a abstrakcja mi przeszkadza. Dlatego za każdym razem, gdy zaczynałem go oceniać, decydowałem się go nie używać.
Berin Loritsch,
2
@Jas Experience było kilka lat temu; w powijakach i było wtedy bardzo surowo. Czy to się zmieniło Być może .... ale powoli staram się poznać podstawy ram, zamiast polegać na samych ramach. Pod koniec dnia jest maszyną do mielenia mięsa JS; nie to, że jest to zła rzecz, ale nie gdzieś chcę włożyć swój wysiłek. Wiele z tych frameworków zostało wybranych ze względu na brak wiedzy na temat technologii X lub czegoś w tym rodzaju ... ale w końcu będziesz musiał zdobyć wiedzę na temat technologii X w pewnym momencie ... równie dobrze możesz pójść tą drogą.
Aaron McIver
10
Mam dużą wiedzę na temat JS, napisałem tam dość poważne rzeczy, jednak teraz prowadzę bardzo krytyczny projekt i nie mogę sobie pozwolić na marnowanie czasu przez młodszy personel z powodu błędów wywołanych przez przełączanie kontekstu z powiedzmy Java na JS. Więc proszę, jeśli masz jakiś przykład, dlaczego GWT nie działał dla ciebie, to opisz go, w przeciwnym razie nie marnujmy się nawzajem na hipotetyczne i subiektywnie kolorowe dyskusje.
Jas

Odpowiedzi:

84

Jestem zarówno dobry, jak i zły, aby odpowiedzieć na to pytanie - dobrze, ponieważ faktycznie go użyłem wcześniej, i źle, ponieważ miałem dość doświadczenia z HTML / CSS / JavaScript przed pracą z GWT. To spowodowało, że oszalałem na punkcie korzystania z GWT w sposób, w jaki mogli nie być inni programiści Java, którzy tak naprawdę nie znają DHTML.

GWT robi to, co mówi - wyodrębnia JavaScript i do pewnego stopnia HTML na Javę. Dla wielu programistów brzmi to znakomicie. Wiemy jednak, jak to ujął Jeff Atwood, że wszystkie abstrakcje są abstrakcjami nieudanymi (warto przeczytać, jeśli wziąć pod uwagę GWT). W przypadku GWT powoduje to w szczególności następujące problemy:

Używanie HTMLa w GWT jest do kitu.

Tak jak powiedziałem, do pewnego stopnia nawet streszcza HTML. Brzmi dobrze dla programisty Java. Ale nie jest. HTML to format znaczników dokumentów. Jeśli chcesz utworzyć obiekty Java w celu zdefiniowania dokumentu, nie użyłbyś elementów znaczników dokumentu. To jest szalenie gadatliwe. Nie jest również wystarczająco kontrolowany. W HTML istnieje zasadniczo jeden sposób pisania <p>Hello how are <b>you</b>?</p>. W GWT masz 3 węzły podrzędne (tekst B, tekst) dołączone do Pwęzła. Możesz najpierw utworzyć P lub najpierw utworzyć węzły potomne. Jeden z węzłów potomnych może być wynikiem funkcji. Po kilku miesiącach programowania z wieloma programistami próba rozszyfrowania wyglądu dokumentu HTML przez śledzenie kodu GWT jest procesem wywołującym ból głowy.

Ostatecznie zespół zdecydował, że być może użycie HTMLPanel dla wszystkich HTML jest właściwą drogą. Teraz straciłeś wiele zalet GWT polegających na tym, że elementy kodu Java są łatwo dostępne do łatwego wiązania danych.

Używanie CSS w GWT jest do bani.

Przez dołączenie do abstrakcji HTML oznacza to, że sposób korzystania z CSS jest również inny. Mogło się poprawić, odkąd ostatni raz użyłem GWT (około 9 miesięcy temu), ale w tym czasie obsługa CSS była nieładna. Ze względu na sposób, w jaki GWT sprawia, że ​​tworzysz HTML, często masz poziomy węzłów, o których nie wiesz, że zostały wstrzyknięte (każdy programista CSS wie, jak to może dramatycznie wpłynąć na renderowanie). Istnieje zbyt wiele sposobów osadzania lub łączenia CSS, co powoduje mylący bałagan przestrzeni nazw. Poza tym miałeś wsparcie dla sprite, które znowu brzmi dobrze, ale faktycznie zmutowało twój CSS i mieliśmy problemy z pisaniem właściwości, które następnie musieliśmy wyraźnie zastąpić później, lub w niektórych przypadkach udaremnialiśmy nasze próby dopasowania naszej ręki - zakodowałem CSS i po prostu przeprojektowałem go w taki sposób, aby GWT tego nie zepsuło.

Unia problemów, przecięcie korzyści

Każdy język będzie miał swój własny zestaw problemów i korzyści. Niezależnie od tego, czy go używasz, jest to ważona formuła oparta na tych. Kiedy masz abstrakcję, otrzymujesz połączenie wszystkich problemów i skrzyżowanie korzyści. JavaScript ma swoje problemy i jest często wyśmiewany przez inżynierów po stronie serwera, ale ma też sporo funkcji, które są pomocne w szybkim tworzeniu stron internetowych. Pomyśl o zamknięciach, stenografii składniowej, obiektach ad-hoc, o wszystkich czynnościach wykonywanych przez Jquery (jak zapytania DOM przez selektor CSS). Teraz zapomnij o użyciu go w GWT!

Rozdzielenie obaw

Wszyscy wiemy, że wraz ze wzrostem wielkości projektu zasadnicze znaczenie ma właściwe rozdzielenie problemów. Jednym z najważniejszych jest oddzielenie wyświetlania od przetwarzania. GWT bardzo to utrudniło. Prawdopodobnie nie jest to niemożliwe, ale zespół, w którym pracowałem, nigdy nie wpadł na dobre rozwiązanie, a nawet gdy myśleliśmy, że tak, zawsze jedno przeciekało do drugiego.

Desktop! = Internet

Jak napisał @Berin Loritsch w komentarzach, model lub sposób myślenia GWT jest zbudowany dla żywych aplikacji, w których program ma żywy obraz ściśle powiązany z silnikiem przetwarzania. Brzmi dobrze, ponieważ tak wielu uważa, że ​​brakuje sieci. Ale są dwa problemy: A) Sieć oparta jest na HTTP i jest to z natury różne. Jak wspomniałem powyżej, technologie oparte na HTTP - HTML, CSS, a nawet ładowanie zasobów i buforowanie (obrazy itp.) Zostały stworzone dla tej platformy. B) Programiści Java, którzy pracowali w Internecie, nie łatwo przełączają się na takie podejście do aplikacji komputerowych. Architektura na tym świecie to zupełnie inna dyscyplina. Programiści Flex prawdopodobnie bardziej pasowaliby do GWT niż programiści Java.

Podsumowując ...

GWT jest w stanie dość szybko tworzyć szybko i brudne aplikacje AJAX przy użyciu samej Javy. Jeśli szybkie i brudne nie brzmią tak, jak chcesz, nie używaj ich. Firma, w której pracowałem, była firmą, która bardzo troszczyła się o produkt końcowy, i ma poczucie polskości, zarówno wizualnej, jak i interaktywnej dla użytkownika. Dla nas, czołowych programistów, oznaczało to, że musieliśmy kontrolować HTML, CSS i JavaScript w sposób, który sprawił, że używanie GWT przypominało próbę gry na pianinie w rękawicach bokserskich.

Nicole
źródło
2
Znałem niektóre z powodów, dla których wybraliśmy Wicket zamiast GWT, czapki z głów przed prezentacją.
biziclop,
12
-1 dla FUD, moje doświadczenia z GWT stosowanym w aplikacjach na małą i dużą skalę były znacznie bardziej pozytywne niż negatywne. I nie spotkałem żadnego z tych „problemów”, dlatego komentarz FUD. Z powodzeniem osadzamy widżety wygenerowane przez GWT na bardzo złożonych stronach HTML przy bardzo małym wysiłku. Jeśli wiesz, co robisz, to wspaniale, jeśli nie chcesz brać pod uwagę, że może istnieć nowy lepszy sposób robienia rzeczy, postępuj zgodnie z „odpowiedzią” i zignoruj ​​ten komentarz.
9
@Jarrod Nie są to „problemy”, ale zwykły opis natury GWT. Tam gdzie to stosowne, dodatkowo zakwalifikowałem je jako negatywne, szczególnie w ramach celów naszego projektu. Jeśli masz alternatywne doświadczenie, napisz je. Do tego czasu jedynymi niepotwierdzonymi informacjami jest twierdzenie, że GWT jest „nowy i lepszy”. Nawiasem mówiąc - odkąd napisałem tę odpowiedź, firma (dla której już nie pracuję) rzuciła ponad rok pracy kilku inżynierów i przepisała projekt bez GWT. W krótszym czasie.
Nicole,
1
@JarrodRoberson Zgadzam się z NickC, wspaniale byłoby przeczytać równie szczegółowy opis swoich doświadczeń.
funkybro
8
@NickC „W krótszym czasie” na przepisanie projektu nie liczy się jako wielki cios dla GWT IMO; każdy projekt, w którym w zasadzie powtarzasz to, co zostało zrobione wcześniej, nawet w innym środowisku lub języku, powinien zająć „mniej czasu”.
funkybro
24

Używamy GWT do dużej aplikacji internetowej eGovernment (SOA w backend), która ma duże zastosowanie. Stary interfejs użytkownika był w formacie DHTML, ale mieliśmy problemy ze zgodnością przeglądarki, optymalizacją wydajności i procesem programowania, dlatego szukaliśmy alternatyw.

Nasze wymagania to:

  • warstwa interfejsu użytkownika po stronie klienta, aby zminimalizować obciążenie serwera
  • kompatybilność z przeglądarką
  • internetowy RIA
  • Łatwe optymalizacje wydajności
  • Instalacja wtyczek klienta nie jest konieczna, powinna działać z prostą instalacją systemu Windows

Wybraliśmy GWT i nigdy tego nie żałuję. Nowy zespół nie miał doświadczenia w DHMTL ani go nie miał, dlatego proces tworzenia oprogramowania Java przez GWT był bardzo pomocny. Co dostajesz z tego pudełka to:

  • kompatybilność z przeglądarką
  • Proces programowania oparty na Javie i ponowne użycie kodu
  • łatwe minimalizowanie żądań (pakiet obrazów, ...)
  • łatwe agresywne buforowanie (nowe aplikacje są całkowicie buforowane po stronie klienta)
  • łatwa kompresja wszystkich zasobów (nawet js na starszych błędnych IE)
  • i wiele więcej, wiele do wspomnienia tutaj

Podczas uruchamiania nasza aplikacja wysyła tylko jedno żądanie do serwera. Negatywną stroną jest to, że GWT (a także Android) mają kiepski wygląd po wyjęciu z pudełka, ale w każdym razie, jeśli zastosujesz swój własny wygląd i poczujesz, że musisz dostosować CSS. Alternatywnie możesz użyć różnych bibliotek komponentów dla GWT, które ułatwiają stosowanie odpowiednich stylów i tematów.

Dla mnie nie ma sensu, aby być może HTML DOM nie był tak dobry jak ręcznie, to nigdy nie było problemu. Kiedy rozwijam w C ++, nie patrzę na wygenerowany kod asemblera. Kiedy rozwijam się w GWT, nigdy nie miałem powodu, aby patrzeć na kod JS i tylko raz był to powód, aby patrzeć na DOM i przeprowadzić pewne refaktoryzacje.

Dla mnie GWT jest jedynym wyborem, jeśli chodzi o rozwój RIA i mam nadzieję, że GWT ma przed sobą świetlaną przyszłość. Zobacz misję na:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

Nie należy jednak wspominać, że Google nie korzysta z GWT w wielu swoich wewnętrznych projektach i że w tej chwili krążą pogłoski o przyszłości GWT, zobacz

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

ChrLipp
źródło