Jetzt mit GWT 2, was sind die Vorteile gegenüber Wicket und ähnlich?

Die Vorteile sind im Grunde, dass GWT ein Werkzeug ist, um JavaScript-basierten Client zu erstellen, daher ist es am besten geeignet, wenn Sie einen Javascript-basierten Client wollen.

Wicket zentriert sich auf dem Server, und während es das Einbetten von JavaScript in zustandslose Seiten recht einfach macht, ist die serverseitige Statusbehandlung der natürlichere Ansatz.

Man muss beachten, dass die Architekturen sehr unterschiedlich sind.

Mit GWT wird Ihre Architektur zu einem Client-Server, einem Thick-Client im Browser, der Aufrufe von 'Prozeduren' (Services) an den Server, das Senden und Empfangen von Daten .

Mit Wicket (und anderen serverseitigen Komponenten-Frameworks, wie JSF und Tapestry) ist die Architektur eine "traditionelle" 3-Layer-Architektur, und was gesendet und empfangen wird, sind Seiten oder Fragmente der Seiten, keine reinen Daten.

Sie können zwar beide kombinieren, um sich an die andere Architektur anzupassen, aber es wäre einfach nicht sehr natürlich.

Menschen neigen dazu, sich darauf zu konzentrieren, "was einfacher zu benutzen ist" (was völlig subjektiv ist, abhängig von Ihrem Hintergrund), oder "das ist schöner und hat mehr Komponenten", aber man sollte den architektonischen Unterschied nicht unterschätzen die Vorgehensweise, die Sie ergreifen müssen, um Aspekte wie Sicherheit und Skalierbarkeit zu behandeln.

Ich war in den letzten Monaten an einem GWT-basierten Projekt beteiligt. Ich war, seit Jahren Teil des Wicket-Entwicklungsteams, freue mich auf eine Veränderung und erwartete viel von GWT (was ich immer als ein weiteres großartiges Java-Framework angepriesen habe).

Ehrlich gesagt, ich bin enttäuscht, wenn es um die Zusammenarbeit mit GWT geht. Ich fühle - mein gesamtes Team -, dass die Produktivität stark getroffen wurde. Theoretisch ist GWT großartig. Aber wenn man die Macken und Einschränkungen des Frameworks berücksichtigt, mittelmäßige Fehlerberichte (besonders wenn es um Serialisierungsfehler geht), die langen Kompilierzeiten (irgendwo zwischen 3 - 10 Minuten und unser Projekt ist noch nicht einmal so groß), Die Tatsache, dass Sie schließlich noch alle Browser testen müssen und Tweaks und Workarounds finden müssen, die Tatsache, dass es einen riesigen anfänglichen Download erzeugt (fast ein MB, den wir schrittweise zurücknehmen, aber mit einer Menge der Anstrengung), etc, usw., fühle ich Wicket ist viel einfacher und schneller mit zu arbeiten.

Ich hasse es nicht, mit GWT zu arbeiten. Es ist immer noch viel besser als die meisten Java-Frameworks. Ich habe nur viel mehr davon erwartet, damit zu arbeiten; Ich habe sogar erwartet, dass es vielleicht schöner ist als Wicket. Aber am Ende ist es einfach nicht imho. Hoffentlich wird GWT 2.0 eine Menge Dinge verbessern, und hoffentlich werden einige der Eigenheiten des Eclipse-Plugins bald ausgeräumt werden.

Es ist nicht fair, GWT mit Wicket (oder ähnlich) zu vergleichen, da sie wirklich aus zwei verschiedenen Lagern kommen. Ersteres ist ein Framework zum Erstellen von JavaScript-Frontend-Anwendungen, während Letzteres ein klassisches Java-Webanwendungs-Framework ist.

Die folgenden Punkte sind also nicht so sehr wie GWT vs. Wicket, sondern eine allgemeine Liste, die zusammengestellt wurde, als wir uns entschieden, GWT für eine erweiterte JavaScript / AJAX-Webanwendung zu verwenden:

• verbirgt Nachteile von JavaScript und Cross-Browser-Unterstützung, indem es erlaubt Entwickeln Sie in Java und kompilieren Sie automatisch zum Browser-spezifischen Geschmack von JavaScript (Das ist nicht vollständig wahr wegen des Gesetzes der tropfenden Abstraktionen, aber es ist ein Hauptgrund, warum GWT an erster Stelle geschaffen wurde - siehe In Constraints schwelgen );
• Java wird von vielen Java-Entwicklern bevorzugt, wenn es auf die fortgeschrittene JavaScript / AJAX-Benutzeroberfläche kommt;
• Java-Entwicklungsumgebung und -Tools werden vollständig unterstützt: Eclipse-Plugin, Debugger, Refactoring, gehosteter Modus in Eclipse;
• JUnit-Tests werden sowohl mit Scheinobjekten als auch im gehosteten Modus unterstützt;
• Saubere Integration mit dem Java-Backend (GWT-RPC);
• Relativ umfangreiche UI-Widgets mit einheitlichem Aussehen und Verhalten;
• Verfügbarkeit von Widgets, Frameworks, Mustern und Beispielen von Drittanbietern (immer noch begrenzt und mit einer langen Wunschliste);
• Der Google-Support fördert sowohl eine breitere Akzeptanz / Popularität als auch eine schnelle Weiterentwicklung des Frameworks;
• Reifung mit 1.6+ und den kommenden 2.0 Releases: (Eventbus, Eventhandler, GUI - Architektur mit MVP - Pattern, Compileroptimierung, etc.)

Meiner Meinung nach ist der größte Vorteil von GWT, dass Sie mit einer Programmiersprache arbeiten können - Java, mit all den Vorteilen, die es bringt.

Zusammen mit CSS bilden sie ein starkes Paar.

Um es anders auszudrücken: Sie können meistens Javascript und HTML vergessen.

Ob das ein Vorteil ist oder nicht, hängt hauptsächlich von Ihren Fähigkeiten und Anforderungen ab. Wir hatten dieselbe Debatte intern und am Ende hat sich ein Team für Wicket und ein anderes GWT entschieden.

Ein Vorteil von Wicket gegenüber GWT wäre, dass Wicket den Fall behandeln kann, in dem Sie einen Fallback für Clients bereitstellen möchten, für die Javascript nicht aktiviert ist. GWT ist komplett für Javascript, Wicket ermöglicht es Ihnen, graziös zu degradieren.

Ich kann mir mehrere Gründe vorstellen, warum GWT für typische Business-Web-Apps eine bessere Wahl ist als Wicket:

1. GWT stammt von Google. Dies kann unfair sein, aber eine große und angesehene Softwarefirma hinter einem Tool zu haben ist ein großer Vorteil (sicherer darauf zu wetten, mehr Bücher und Online-Ressourcen, mehr Support von Drittanbietern, bessere IDE-Unterstützung, ...).
2. Server-zentrierte Web-Frameworks wie Wicket sind veraltet. Moderne Webbrowser sind sehr leistungsfähig und werden immer mehr, daher sollte Ihnen ein modernes Web-Framework dabei helfen, das zu nutzen.
3. Die direkte Kodierung in HTML und Javascript kann niemals so produktiv sein wie die Kodierung in Java (zumindest aus meiner Erfahrung). Außerdem gibt es bessere Tools für Java-Code (Debugger, statische Analyse, Komponententests und Code-Coverage, etc.).

Das Genie hinter GWT ist, dass Sie ausschließlich mit Java arbeiten. Sie haben mit RPC eine großartige Arbeit geleistet, die es für den Programmierer fast transparent machte. Viele Male haben Sie das Gefühl, dass Sie eher wie eine Desktop-Anwendung statt einer Anwendung mit einer wirklich definierten Client- und Serverseite programmieren.

Es gibt einige andere Vorteile von Wicket gegenüber GWT, die ich finde.

1. GWT funktioniert nicht mit einem Browser, in dem Javascript deaktiviert wurde. (Dies ist jedoch selten). Wicket greift immer auf normale HTTP-Anfragen zurück, wenn JavaScript nicht verfügbar ist.
2. GWT-Anwendungen sind einseitige Anwendungen, die das Setzen von Lesezeichen und die Verwendung von Browser-Tabs stark vereinfachen. Mit Wicket können Sie eine Seitenanwendung oder mehrere Seitenanwendungen erstellen. Sie können die Seiten bei Bedarf mit einem Lesezeichen versehen.
3. In GWT ist das Erstellen eigener Komponenten nicht immer einfach. In Wicket, da Sie mit Roh-HTML, CSS und sogar Javascript arbeiten benutzerdefinierte Komponenten ist sehr flexibel. Sie können eine vorhandene jQuery- oder Dojo-Komponente sehr einfach umbrechen.
4. Da GWT das Kompilieren von Java zu JavaScript umfasst, können Sie nur die Java-Klassen verwenden, die vom GWT-Compiler emuliert wurden. Dies kann einschränkend sein. Wicket ist ein serverseitiges Framework und Sie können alle gewünschten Java verwenden.
5. Die Arbeit mit CSS und Web-Designern ist viel einfacher mit Wicket als GWT.