Kommentare zu: Entscheidungshilfe Webframework http://www.wicket-praxis.de/blog/2009/09/12/entscheidungshilfe-webframework/ erfahrungen mit wicket aus dem projektalltag Tue, 19 Apr 2011 10:23:47 +0000 hourly 1 http://wordpress.org/?v= Von: Benjamin Schmid http://www.wicket-praxis.de/blog/2009/09/12/entscheidungshilfe-webframework/comment-page-1/#comment-6552 Benjamin Schmid Tue, 19 Apr 2011 10:23:47 +0000 http://www.wicket-praxis.de/blog/?p=127#comment-6552 In diesem Zusammenhang ein Hinweis auf das nicth ganz so bekannte, aber in meinen Augen technologisch sehr überzeugende Echo 3 Framework : http://echo.nextapp.com/ Echo3 bietet ein JavaScript-Komponentenmodell und ein dazu gespiegeltes Java Komponentemodell an. Daher lassen sich Anwendungen von komplett in Java bis komplett in JavaScript und gemischt entwickelt. Da es JS pur einsetzt, ist der Entwicklungstrip für JavaScript relevanten Entwicklungen um Dimensionen leichter, durchschaubarer und managebarer als in GWT. Dalls man in die Situation kommt neue, eigenen Komponenten einzubinden (z.B. komplexe JS Komponenten a la jquery UI oder extJS). In meinen Augen die bessere, leichtgewichtigere klarer Alternative zu Vaadin. In diesem Zusammenhang ein Hinweis auf das nicth ganz so bekannte, aber in meinen Augen technologisch sehr überzeugende Echo 3 Framework : http://echo.nextapp.com/

Echo3 bietet ein JavaScript-Komponentenmodell und ein dazu gespiegeltes Java Komponentemodell an. Daher lassen sich Anwendungen von komplett in Java bis komplett in JavaScript und gemischt entwickelt. Da es JS pur einsetzt, ist der Entwicklungstrip für JavaScript relevanten Entwicklungen um Dimensionen leichter, durchschaubarer und managebarer als in GWT. Dalls man in die Situation kommt neue, eigenen Komponenten einzubinden (z.B. komplexe JS Komponenten a la jquery UI oder extJS). In meinen Augen die bessere, leichtgewichtigere klarer Alternative zu Vaadin.

]]> Von: michael http://www.wicket-praxis.de/blog/2009/09/12/entscheidungshilfe-webframework/comment-page-1/#comment-818 michael Mon, 12 Oct 2009 07:18:23 +0000 http://www.wicket-praxis.de/blog/?p=127#comment-818 Die Serverlast sollte sich gerade mit Java in Grenzen halten, so dass unter diesem Aspekt einer Migration nichts im Weg steht. Interessanter wird es bei der Komplexität der Anwendung. Wann ist die Komplexität sehr hoch? Lohnt sich nicht schon ein Umstieg, wenn die Komplexität nicht mehr besonders gering ist? Ich denke ja. Allerdings stehen der Migration dann noch andere Hindernisse im Weg, die man ungern überwindet: z.B. die Lernkurve. An dieser Stelle frage ich mich dann oft: Auf welche Themen möchte ich Einfluss haben, wenn ich eine Anwendung schreibe? Wenn ich durch die Wahl eines Frameworks mich genau auf diese Themen konzentrieren kann und mich idealer Weise mit keinem anderen Thema beschäftigen muss, kann es kaum einen besseren Kandidaten geben. Und so interessant die Entwicklung von Webandwendungen auch ist, gibt es doch eine Liste von Themen, die einfach funktionieren sollten (Request/Response, Encoding, Ajax, etc.). Das komplette Paket aus Bibliotheken, einer guten IDE, einer stabilen Sprache, einem ausgereiften Build-Tool, integrierten Unit-Tests etc. lassen für mich den Java-Stack um so viel geeigneter erscheinen. Aber das ist und bleibt schlussendlich auch eine persönliche Entscheidung. Insofern ist PHP natürlich nach wie vor eine Alternative. Die Serverlast sollte sich gerade mit Java in Grenzen halten, so dass unter diesem Aspekt einer Migration nichts im Weg steht. Interessanter wird es bei der Komplexität der Anwendung. Wann ist die Komplexität sehr hoch? Lohnt sich nicht schon ein Umstieg, wenn die Komplexität nicht mehr besonders gering ist? Ich denke ja. Allerdings stehen der Migration dann noch andere Hindernisse im Weg, die man ungern überwindet: z.B. die Lernkurve. An dieser Stelle frage ich mich dann oft: Auf welche Themen möchte ich Einfluss haben, wenn ich eine Anwendung schreibe? Wenn ich durch die Wahl eines Frameworks mich genau auf diese Themen konzentrieren kann und mich idealer Weise mit keinem anderen Thema beschäftigen muss, kann es kaum einen besseren Kandidaten geben. Und so interessant die Entwicklung von Webandwendungen auch ist, gibt es doch eine Liste von Themen, die einfach funktionieren sollten (Request/Response, Encoding, Ajax, etc.). Das komplette Paket aus Bibliotheken, einer guten IDE, einer stabilen Sprache, einem ausgereiften Build-Tool, integrierten Unit-Tests etc. lassen für mich den Java-Stack um so viel geeigneter erscheinen. Aber das ist und bleibt schlussendlich auch eine persönliche Entscheidung. Insofern ist PHP natürlich nach wie vor eine Alternative.

]]> Von: Martin http://www.wicket-praxis.de/blog/2009/09/12/entscheidungshilfe-webframework/comment-page-1/#comment-815 Martin Sun, 11 Oct 2009 11:45:23 +0000 http://www.wicket-praxis.de/blog/?p=127#comment-815 Guter Überblick, den ich nur zustimmen kann. Jedoch fällt mir ein Punkt nicht reell vor. Ich würde von PHP auf Wicket nur unter bestimmten Umständen migrieren. wenn: - PHP-Code ist nicht mehr wartbar - Anforderungen erfordern J2EE features - Komplexität ist sehr hoch Ansonsten ist eine solche Migration mehr viel mehr serverlast verbunden. Guter Überblick, den ich nur zustimmen kann. Jedoch fällt mir ein Punkt nicht reell vor.
Ich würde von PHP auf Wicket nur unter bestimmten Umständen migrieren. wenn:
- PHP-Code ist nicht mehr wartbar
- Anforderungen erfordern J2EE features
- Komplexität ist sehr hoch

Ansonsten ist eine solche Migration mehr viel mehr serverlast verbunden.

]]>