# Welches Framework für Webentwicklung?



## Javalist (12. Sep 2011)

Hallo,

ich möchte mich an einer Community für einen recht speziellen Bereich versuchen.

Als Basisfunktionen soll das vorhanden sein, was in den üblichen Social Community mit Profilen etc auch zur Verfügung steht. Ggf auch Chat. Hinzu kommen dann noch für die Zielgruppe spezielle Funktionen.

Eigentlich war die Entscheidung schon für Vaadin gefallen, aber dort ist zum einen die Serverbelastung recht hoch, zum anderen sind die Ladezeiten recht hoch.  Trotzdem ist dort die Programmierung recht angenehm, weil wenig bis gar nicht mit HTML/CSS oder PHP gearbeitet werden muss.

Welches Framework für die Weboberfläche würdet ihr Empfehlen?


----------



## Antoras (12. Sep 2011)

GWT oder RAP wenn alles in JavaScript sein soll.


----------



## brauner1990 (12. Sep 2011)

Jquery ... mit JqueryUI haste dann auch Styling


----------



## Gast2 (13. Sep 2011)

http://www.java-forum.org/web-tier/120978-suche-java-framework.html


----------



## nillehammer (13. Sep 2011)

Tapestry (Apache Tapestry Home Page)


----------



## dermoritz (14. Sep 2011)

also mit deinen Vorgaben ganz klar GWT (ich arbeite gerade sehr intensiv damit).

Vorteile:
- kein Javascript kein HTML
- ui programmierung auch in java (ähnlich wie swing) oder in XML ("ui-binder")
- Browserkompatibilität ist geschenkt
- bietet im Kern alles was man braucht
- es gibt jedoch auch unzählige "Add-Ons" für Widgets und andere Funktionen
- sehr gute IDE Unterstützung (Eclipse, Netbeans und IntelliJ)
- sehr gute Community (google-group)-> man sollte sich nicht scheuen Fragen zu stellen
- freie Wahl zwischen "client-/server- centric" wobei einem es sehr leicht gemacht wird fast alle Logik auf den Client zu schieben
- ab Version 2.1 und später gibt es viele sehr hilfreiche (aber schlecht dokumentierte) neu Funktionen "RequestFactory"(für DB-Interaktionen), "Activities/Places"(für Historymanagement)
- bei gutem Entwurf (Pattern MVP und Dependency Injection benutzen!) kann man den größten Teil der UI-Logik mit klassischem JUnit testen. Bei reinen Ui-Klassen hilft "GWTTestCase".

Nachteile
- nur für Java-Erfahrene (Experten?!)
- schlechte Doku (Doku kommt mit der rasanten Weiterentwicklung nicht mit) -> nach schnellem Einstieg sehr steile Lernkurve
- zumindest bei Eclipse ist das Zusammenspiel mit Maven "bescheiden". Beim neuen Eclipse ist das nochmal ein Stück schlechter geworden. (https://groups.google.com/forum/#!topic/codehaus-mojo-gwt-maven-plugin-users/IgDLATLOq88)


----------



## Noctarius (14. Sep 2011)

Warum nicht Vaadin - thinking of U and I - vaadin.com ?


----------



## Web-Frameworkrt (14. Sep 2011)

Super frage eventuell mehr denn Anforderungsbereich eingrenzen ansonsten:


Play framework - Home
http://seamframework.org/
Apache Wicket - Welcome to Apache Wicket
Google Web Toolkit - Google Code

--------------------------------------------
JSF
PrimeFaces
ICEfaces - Open Source Ajax, J2EE Ajax, JSF Java Framework
RichFaces Project Page - JBoss Community

--------------------------------------------
SpringSource.org |
Grails - The search is over.
Welcome
Home - Stripes - Stripes Framework

kannste du dich todsuchen...


----------



## dermoritz (14. Sep 2011)

vaadin ist "server-centric". es ist eher für intranet dinge. für jede interaktion im browser wird der server kontaktiert. der server übernimmt zum größten teil die steuerung der ui.

Prinzipiell stellt sich jedoch die Frage wieviele "Communifunktionen" es nicht schon fertig implementiert gibt (Chat, Forum...).

Wenn man diese fertigen Bausteine "nur" integrieren will, ist der use-case eventuell etwas anders.
Gibt es eventuell schon integrierte community-seiten-software?


----------



## Noctarius (14. Sep 2011)

dermoritz hat gesagt.:


> vaadin ist "server-centric". es ist eher für intranet dinge. für jede interaktion im browser wird der server kontaktiert. der server übernimmt zum größten teil die steuerung der ui.



Stimmt - und? Wir haben damit ein großes externes System laufen. Macht kein Problem und lässt sich zur Laufzeit dank OSGi updaten.


----------



## dermoritz (14. Sep 2011)

ich hatte noch etwas ergänzt^^

das problem mit server-centric ist die skalierbarkeit. die serverlast ist dann nicht nur von backend / geschäftslogik zugriffen abhängig sondern von der art der benutzung der ui.
Wenn z.B. zufällig viele Benutzer aufeinmal auf die Idee kommen Drag&Drop zu machen (die aktualisierung er positionen und das rendern der "gedragten" elemente macht da der server) hat man eine hohe auslastung am server.
das schöne bei gwt ist: ich kann mir aussuchen wo ich welche aufgaben mache und so die skalierbarkeit/performance im nachhinein ändern (es ist nur ein bisschen schwieriger als eine klasse von einem paket(server) in das andere(client) zu schieben)

wo vaadin ganz klar punktet: es ist out of the box schicker und hat nen haufen fertig implementierter use-cases. bei gwt muss man entweder alles selber machen oder auf irgendwelche widget bibliotheken setzen (die richtig guten smartgwt und extgwt sind nur "halbumsonst" )


----------



## Noctarius (14. Sep 2011)

Wird halt mit Loadbalancer vernünftiges Clustering betrieben. Mit sticky Sessions ist das kein Problem.

Zusätzlich wird die Geschäftslogik intern auf JBoss ausgeführt und die Tomcats machen echt nur Frontend.

PS: Was meinst du mit fertige Module in der Ergänzung?


----------



## dermoritz (14. Sep 2011)

Je nachdem was diese Community-Seite alles bieten soll gibt es bestimmte Funktionalitäten(Module, Bausteine) schon fertig: Forum, Chat, Blog (da gibt es nen Haufen Open Source Produkte)
Eventuell gibt es auch was was mehrere verbindet. Dies Gesamtseite müsste dann diese Bausteine einfach zusammenknoten. Bei diesem Ansatz wäre wichtiger zu wissen in welcher Technologie gibt es alle/viele Bausteine schon fertig (.net, java, php). Basierend darauf müsste man dan eine Entscheidung für die "Gesamtseite" treffen.

Nun zur Skalierbarkeit,

Die Optionen des Loadballancings/Clusterings hat man bei GWT ja auch. Nur hat man eben nur bei GWT die Option die Rechenlast zum Client zu verlagern. 
Vor einigen Jahren war das noch kritisch (IE6). Aber mit der Verbreitung moderner JS-Engines und schnellerer HW ist das eine sehr gute Option.


----------



## Noctarius (14. Sep 2011)

Joar leider nutzen immer noch viele Kunden (zu mindestens bei uns noch über 15%) den IE6 ~_~
Die Rechenarbeit für die "GUI" an den Client verlagern ist ja an sich auch eine nette Idee, aber dir wird halt die Möglichkeit genommen zur Laufzeit Module ein- oder auszubinden bzw. zu aktualisieren, da GWT einfach pre-compiled arbeitet.

Vaadin nutzt im Hintergrund auch den GWT Compiler und damit auch fertige JS-Module, die aber zur Laufzeit zusammengestöpselt und zum Client übertragen werden. Wenn irgendwo ein Flaschenhals ist, dann sicher an dieser Stelle und nicht unbedingt an der Datenkommunikation.

PS: Sicher gibt es fertige Module für Communitysysteme  Ich hätte da z.B. welche *g*


----------

