Vaadin - Was läuft eigentlich wo?

[miketech]

Hallo zusammen,

ich gehe gerade meine ersten Schritte mit Vaadin. Bei GWT sage ich ja recht deutlich, was beim Client läuft und was auf der Serverseite. Wie ist das bei Vaadin? Hier ist das weniger transparent. Woher weiß ich, wo was läuft?

Mir geht es hier natürlich auch um geschäftskritische Funktionen, die bspw. unbedingt auf Serverseite bleiben sollten, während andere Dinge, um den Server nicht zu sehr zu beanspruchen gerne im Browser laufen können.

Kann ich das steuern?

Viele Grüße

Mike

 

[Noctarius]

Das Rendern der Komponenten läuft auf dem Client, die Komponentenverwaltung und alles andere auf dem Server.

 

[miketech]

Hi,

danke für Deine Antwort. Und kann ich irgendwie angeben, dass bspw. eine bestimmte Funktionalität vollständig beim Client laufen soll? Wäre natürlich was feines, sollte mit GWT als Compiler ja möglich sein.

Ideal wäre sowas wie:

@ClientSide 
public void doSomething() {

usw.

}

Gibt es eigentlich eine Statisik, inwieweit Vaadin verbreitet ist? Ich kenne nur die von OIO (Vergleich von Java Web-Frameworks wie GWT vs. JSF) Die zeigt, dass JSF und GWT am häufigsten genutzt werden. Aber es gibt auch einen großen Anteil "Sonstige" (21%). Hier wäre es natürlich interessant zu wissen, wie stark hier Vaadin vertreten ist.

Denn insgesamt macht Vaadin einen sehr angenehmen Eindruck. Gilt natürlich abzuwarten, was Google nun noch mit GWT 2.5 im Juni nachliefert

Gruß

Mike

 

[Noctarius]

Soweit ich weiß geht das nur, wenn du die Clientlogik einer Komponente änderst und dann entsprechend die Komponenten neu erstellen lässt. Also theoretisch ja, die Handler sind ja auch clientseitig registriert und werden dann zum Server übertragen.

Ein fertiges Feature dafür kenne ich nicht außer eben Komponente ableiten, Logik ändern, rekompilieren.

 

[miketech]

Ok prima, danke. Dass erstmal alles Serverseitig abgearbeitet wird, entspricht ca. 90% meiner Anforderungen. Passt daher sehr gut.

Gruß

Mike

 

[Noctarius]

Viele haben da Angst vor Geschwindigkeit, aber bisher habe ich da noch nie Probleme sehen können, zur Not muss man halt skalieren

 

[miketech]

Yup. Sieht insgesamt gut aus, wie gesagt, derzeit schlage ich mich nur mit dem Compiler rum. Weil performant ist das ja nicht zum produktiv arbeiten. Oder mein Computer ist einfach schon zu alt

Gruß

Mike

 

[Noctarius]

Nein der Compiler ist tatsächlich sehr langsam / rechenintensiv. Das ist aber bei GWT das Selbe. Vor allem liegt es daran, dass das JavaScript in alle möglichen OS-Browser-JS Permutationen transformiert wird und das sind üblicherweise 6 oder 7.

 

[miketech]

Ah ok. Aber dennoch ist es bis jetzt wirklich beeindruckend. Ich bin aktuell noch sehr angetan davon. Es geht schnell und gut

 

[JohannisderKaeufer]

Nein der Compiler ist tatsächlich sehr langsam / rechenintensiv. Das ist aber bei GWT das Selbe. Vor allem liegt es daran, dass das JavaScript in alle möglichen OS-Browser-JS Permutationen transformiert wird und das sind üblicherweise 6 oder 7.

Da muß ich zustimmen, daß das ganze sehr träge ist. Während der Entwicklungsphase kann man aber auch Einstellen, daß nur für einen bestimmten Client Compiliert wird, so daß das ganze etwas zügiger geht.
Außerdem kann man noch Optimierungen abschalten (draftCompile), die noch ein wenig mehr Geschwindigkeit rausholen.

Eigentlich sollte man auf das JS-Compilieren während der Entwicklung verzichten können und mit dem Google Web Toolkit Developer Plugin arbeiten können. Damit habe ich allerdings das Problem, daß dies nicht mit Fierfox 12.0 kompatibel sein soll, so daß mir nur das compilieren übrig bleibt.

Oder doch mal chrome ausprobieren???:L

 

[Noctarius]

Keine Ahnung habe den Compiler mit im Maven Build Cycle von daher läuft der sowieso ;-)