Warum sollte man Vaadin einsetzen?

Oneixee5

Top Contributor
Warum sollte man Vaadin einsetzen? Vaadin bedeutet doch serverseitiges Rendering. Wozu sollte man die Rechenleistung auf den Server holen? Selbst die meisten Mobilgeräte verfügen heute über genügend Power um ausreichend schnell und komfortabel Webseiten zu rendern. Ist das dann nicht auch wie PHP? Der Vorteil der physischen Trennung von Backend und Frontend geht verloren. Irgendwann, im Laufe der Zeit, werden die Ebenen dann vermischt - einfach weil es möglich ist.
Ich stelle mir Vaadin immer als ähnlich aufwändig, starr, unbeholfen und als einen einzigen großen Kompromiss vor, wie JSP, JSF und PHP. Welche Argumente sprechen für Vaadin - außer das man alles in Java programmieren kann - was ich nicht als Vorteil sehe.
 
Ich glaube das Konzept des "Serverseitigen Renderings" geht hier in die falsche Richtng.

Vaadin funktioniert so, dass man etwas in JAVA implementiert und das wird dann cross compiliert nach JavaScript und Java. Das passiert einmalig beim Deployment.

Die fertige Anwendung liefert dann einen Teil, der dann im Browser "ausgeführt" wird und den passenden Serveranteil dafür. Der Vorteil ist, dass man als Nutzer oft die den Eindruck hat, als würde man eine Anwendung sehen, die dann selten die gesamte Seite neu läd. (sog. Single Page Anwendung).

Serverseitiges Rendering gibt es bei HTML nicht. Das würde bedeuten, dass der Server Bilder ausliefert von fertigen Seiten. Dem ist aber nicht so. Der Server liefert ein HTML DOM und der Client rendert es in Farben und Formen und Text. Was du meinst ist serverseitige Generierung. Hier würde ich von Vaadin aber nicht davon ausgehen. Der Anteil der Webseite ist JavaScript und viel wird dann über AJAX Calls gemacht.

Das ist der signifikante Unterschied zu PHP. PHP generiert vollständigen HTML DOM im Server und liefert diesen aus, wenn er fertig ist. Da wird im Client nicht gemacht. Da braucht man entsprechende rechenpower und das ist in der Regel aber kein Problem. Denn du musst auch bei Single Page Applications allen Input des Users verifizieren. Also DB Zugriff / ggf. Schnittstellenzugriff hast du hier auch. Du sparst ein bisschen Texterstellung. Allerdings musst du auch die Daten z.B. über JSON oder XML übertragen zum Client, also ist diese Textgenerierung auch nicht sonderlich unterschieldich.

Zusammengefasst: Es gibt Single Page Applikationen (react, vue.js, angular), die die DOM Monipulation im Client durchführen. Müssen aber Input Validieren. ggf. doppelt.
PHP und Java + Thymeleaf und ähnliche erstellen HTML DOM auf dem Server und liefern den aus. InputValidierung passiert an einer Stelle im Server.

Heute tendiert man zu Single Page Applikationen, weil das für den Nutzer die bessere Nutzererfahrung bietet.

Aber ich würde dafür nicht Vaadin nutzen, weil meiner persönlichen Meinung das recht alt ist und es heute bessere Frameworks (react, vue.js, angular) gibt.

Gruß,
Martin
 
Es stimmt und ist ein wenig umständlich, dass man Eingaben immer zwei mal validieren muss. Das Thema beschäftigt mich auch schon länger. Das wäre, meiner Meinung nach, ein echter Vorteil, wenn man diese nur einmal programmieren müsste. Als Beispiel: für eine bestimmte Schulart eines Schülers kann man nur bestimmte Zeugnisarten auswählen und muss daher die Liste der möglichen Zeugnisarten danach filtern.
 
Was du meinst ist serverseitige Generierung.
Was hier tatsächlich als Server-Side Rendering bezeichnet wird. Es geht darum, dass auf dem Server dynamische Inhalte als HTML "gerendert" ausgeliefert werden (to render sth = etwas leisten, machen, übergeben, wiedergeben, übersetzen, ...) Bei JSF wird z. B. ein XHTML-File genommen, daraus ein JSF-Objektbaum erzeugt und am Ende wird aus XHTML + JSF-Komponenten ein HTML-Dokument "gerendert", das an den Browser gesendet wird. Mit AJAX werden dann nur Teile der Seite ersetzt, wobei auch hier vom Server HTML geliefert wird.

Beim Client-Side-Rendering werden Daten vom Server abgerufen, der Client baut dann das HTML zusammen (modifiziert den DOM).

Wir bauen unsere Anwendungen mit JSF+Primefaces. Warum? Weil es für unsere Zwecke reicht und höchst produktiv ist. Für uns nicht interessant, im Web aber natürlich von Vorteil: für Suchmaschinen ist SSR optimal. Je nach Seite kann SSR zu schnelleren (aber auch langsameren) Ladezeiten ggü. CSR führen.

Hat halt alles zwei Seiten und man sollte nehmen, was sich für den Zweck am ehesten eignet.
 
Wir arbeiten in der Firma mit Vaadin und ich schätze es sehr. Vorteile meines Erachtens:

  • (Fast) Alles Java (+ggf was CSS). Man braucht nur eine Sprache und muss nicht von Javascript zu Java wechseln und ggf. Modelle duplizieren
  • Ich muss Dinge nur 1x programmieren. Ich brauche eine Validierung nur 1x programmieren, denn sie sie läuft ja auf dem Server

Ob da jetzt wirklich nennenswert mehr Last auf dem Server ist - wage ich mal zu bezweifeln.

Nachteile sind:
  • Mehr Round-Trips zum Server - da sehr viel serverseitig läuft (wie z.B. Validierungen) muss dafür immer ein AJAX Call an den Server stattfinden. Das sind ggf. mehr als bei echt clientseitigen Frameworks. Das dürfte vor allem Anwendungen betreffen die über langsame / schlechte Verbindungen genutzt werden sollen (z.B. Mobilfunk)
  • Wir nutzen Vaadin für Business-Backend Anwendungen - die sehen relativ "langweilig" aus. Für Fancy Endkunden UIs sehe ich es weniger
 
(Fast) Alles Java (+ggf was CSS). Man braucht nur eine Sprache und muss nicht von Javascript zu Java wechseln und ggf. Modelle duplizieren
Wir nutzen Vaadin für Business-Backend Anwendungen - die sehen relativ "langweilig" aus. Für Fancy Endkunden UIs sehe ich es weniger
Das sind die entscheidenden Punkte aus meiner Sicht: Mit Vaadin kann man relativ einfach rein in Java entsprechende UIs bauen. Man braucht also eben kein HTML/JS/CSS (oder entsprechend weniger).

Die Einschränkung ist dabei dann aber aus meiner Sicht, dass dies auf den zweiten Punkt hinaus läuft: Die UIs sind dann eher "einfach gehalten". Es mag zwar durchaus mehr möglich sein, aber dann geht man wieder direkt auf HTML/JS/CSS und dann ist dieser Vorteil von Vaadin weg und dann ist es aus meiner Sicht einfacher, sich komplett auf diese Technology zu konzentrieren (mit entsprechenden Frameworks wie React, Angular Vue, ...).

Ob da jetzt wirklich nennenswert mehr Last auf dem Server ist - wage ich mal zu bezweifeln.
Hier ist die Frage, was man für eine Skallierung braucht. Da deutlich mehr auf dem Server läuft, hat man da natürlich eine Last. Und wenn ich ein System mit YouTube, Facebook oder ähnliches sehe mit sehr vielen gleichzeitigen Usern, dann ist das aus meiner Sicht schon kritisch. Da ist es durchaus existenziell, dass vieles im Client läuft und nicht mehr auf dem Server. Aber bei einer Business Anwendung, bei der eben diese Last nicht vorhanden ist und man kaum über tausend gleichzeitig aktive User kommt, dann ist es einfach unkritisch / uninteressant.
 

Zurück
Oben