Ich bin sowohl gut als auch schlecht darin, diese Frage zu beantworten - gut darin, dass ich sie tatsächlich zuvor verwendet habe, und schlecht darin, dass ich vor der Arbeit mit GWT ziemlich viel Erfahrung mit HTML / CSS / JavaScript hatte. Das hat mich wütend gemacht, GWT so einzusetzen, wie es andere Java-Entwickler, die DHTML nicht wirklich kennen, vielleicht nicht getan haben.
GWT macht das, was es sagt - es abstrahiert JavaScript und bis zu einem gewissen Grad HTML in Java. Für viele Entwickler klingt dies brillant. Wir wissen jedoch, wie Jeff Atwood es ausdrückt, dass alle Abstraktionen fehlerhafte Abstraktionen sind (eine Lektüre lohnt sich, wenn man GWT berücksichtigt). Bei GWT führt dies speziell zu folgenden Problemen:
Das Verwenden von HTML in GWT ist zum Kotzen.
Wie ich schon sagte, abstrahiert HTML bis zu einem gewissen Grad sogar. Für einen Java-Entwickler klingt das gut. Aber es ist nicht. HTML ist ein Dokument-Markup-Format. Wenn Sie Java-Objekte zum Definieren eines Dokuments erstellen möchten, verwenden Sie keine Dokument-Markup-Elemente. Es ist unglaublich wortreich. Es wird auch nicht genug kontrolliert. In HTML gibt es im Wesentlichen eine Möglichkeit zu schreiben <p>Hello how are <b>you</b>?</p>
. In GWT sind 3 untergeordnete Knoten (Text B
, Text) an einen P
Knoten angehängt . Sie können entweder zuerst das P oder zuerst die untergeordneten Knoten erstellen. Einer der untergeordneten Knoten ist möglicherweise das Rückgabeergebnis einer Funktion. Nach einigen Monaten der Entwicklung mit vielen Entwicklern ist der Versuch, das Aussehen Ihres HTML-Dokuments durch Verfolgung Ihres GWT-Codes zu entschlüsseln, ein Prozess, der Kopfschmerzen verursacht.
Am Ende entschied das Team, dass vielleicht die Verwendung von HTMLPanel für alles HTML der richtige Weg ist. Jetzt haben Sie viele der Vorteile von GWT verloren, die darin bestehen, dass Elemente für Java-Code leicht verfügbar sind, um einfach Daten zu binden.
Das Verwenden von CSS in GWT ist zum Kotzen.
Durch die Anbindung an die HTML-Abstraktion unterscheidet sich auch die Art und Weise, wie Sie CSS verwenden müssen. Es hat sich möglicherweise verbessert, seit ich das letzte Mal GWT verwendet habe (vor ungefähr 9 Monaten), aber zu der Zeit war die CSS-Unterstützung ein Chaos. Aufgrund der Art und Weise, wie Sie mit GWT HTML erstellen, gibt es häufig Knotenebenen, von denen Sie nicht wussten, dass sie injiziert wurden (jeder CSS-Entwickler weiß, wie sich dies dramatisch auf das Rendern auswirkt). Es gab zu viele Möglichkeiten, CSS einzubetten oder zu verknüpfen, was zu einem verwirrenden Durcheinander von Namespaces führte. Darüber hinaus hatten Sie die Sprite-Unterstützung, die sich wieder gut anhört, aber Ihr CSS tatsächlich verändert hat, und wir hatten Probleme damit, Eigenschaften zu schreiben, die wir später explizit überschreiben mussten, oder in einigen Fällen unsere Versuche vereitelt haben, unseren handgemachten Anforderungen zu entsprechen. codiertes CSS und musste es nur so umgestalten, dass GWT es nicht vermasselte.
Union der Probleme, Schnittmenge der Vorteile
Jede Sprache wird ihre eigenen Probleme und Vorteile haben. Ob Sie es verwenden, ist eine gewichtete Formel, die auf diesen basiert. Wenn Sie eine Abstraktion haben, erhalten Sie eine Vereinigung aller Probleme und eine Überschneidung der Vorteile. JavaScript hat seine Probleme und wird häufig von serverseitigen Ingenieuren verspottet. Es verfügt jedoch auch über einige Funktionen, die für eine schnelle Webentwicklung hilfreich sind. Denken Sie an Closures, Syntaxkürzel, Ad-hoc-Objekte und all das, was Jquery macht (wie DOM-Abfragen mit CSS-Selektoren). Vergessen Sie jetzt die Verwendung in GWT!
Trennung von Bedenken
Wir alle wissen, dass mit zunehmender Größe eines Projekts eine gute Trennung der Anliegen von entscheidender Bedeutung ist. Eine der wichtigsten ist die Trennung zwischen Anzeige und Verarbeitung. GWT hat das wirklich schwer gemacht. Wahrscheinlich nicht unmöglich, aber das Team, dem ich angehörte, hat nie eine gute Lösung gefunden, und selbst wenn wir dachten, wir hatten immer eine undichte Stelle in der anderen.
Desktop! = Web
Wie @Berin Loritsch in den Kommentaren schrieb, ist das Modell oder die Denkweise, für die GWT entwickelt wurde, lebende Anwendungen, bei denen ein Programm eine lebende Anzeige aufweist, die eng mit einer Verarbeitungsmaschine gekoppelt ist. Das hört sich gut an, weil so viele das Gefühl haben, dass das Web fehlt. Es gibt jedoch zwei Probleme: A) Das Web basiert auf HTTP und dies ist von Natur aus anders. Wie bereits erwähnt, wurden die auf HTTP basierenden Technologien - HTML, CSS, sogar das Laden und Zwischenspeichern von Ressourcen (Bilder usw.) - für diese Plattform entwickelt. B) Java-Entwickler, die im Web gearbeitet haben, können nicht einfach auf diese Einstellung für Desktop-Anwendungen umsteigen. Architektur in dieser Welt ist eine ganz andere Disziplin. Flex-Entwickler wären für GWT wahrscheinlich besser geeignet als Java-Webentwickler.
Abschließend...
GWT ist in der Lage, schnell und einfach AJAX-Anwendungen mit nur Java zu erstellen. Wenn schnell und schmutzig nicht so klingt, wie Sie es möchten, verwenden Sie es nicht. Die Firma, für die ich arbeitete, war eine Firma, die sich sehr um das Endprodukt kümmerte, und die den Benutzer sowohl visuell als auch interaktiv aufpoliert. Für uns Front-End-Entwickler bedeutete dies, dass wir HTML, CSS und JavaScript so steuern mussten, dass die Verwendung von GWT dem Klavierspiel mit Boxhandschuhen ähnelte.