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

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?

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.

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