für eine Webanwendung bin ich noch auf der Suche nach dem richtigen JavaScript-Framework, mit dem ich das UI etwas aufhübschen und nutzbarer machen kann.
Dabei sind mir folgende Eigenschaften des Frameworks wichtig:
[ul][li]die Lizenz muss kommerziellen Einsatz zulassen, ohne dass der Quellcode offengelegt werden muss (GPL kommt also nicht in Frage)
[/li][li]accessibility und internationalization-support out of the box
[/li][li]einige Widgets (mindestens Dialoge, gerne auch DatePicker (ggf. nur als Fallback zu HTML5-Elementen)) mit graceful degradation
[/li][li]vernünftige AJAX-Unterstützung
[/li][li]WebSocket-Unterstützung[/ul]
[/li]
Die Anforderungen sind also eigentlich recht moderat. Natürlich habe ich jQuery schon ausprobiert - das gefällt mir aber nicht so gut.
Dojo mit dijit gefällt mir da schon deutlich besser. Die Formular-Widgets haben für mich aber ein entscheidendes Defizit, welches ich bisher nicht umgehen konnte: die ursprünglich im Quellcode angegebenen HTML-Elemente werden durch Templates ausgetauscht. Das hat zur Folge, dass Autovervollständigung nicht mehr funktioniert und bei Login-Dialogen die Zugangsdaten nicht mehr gespeichert werden können. Außerdem gibt es einen hässlichen Effekt beim Laden der Seite. Die Elemente werden nach dem Laden der Seite durch den Templatecode ausgetauscht, sodass sie (je nach Verbindungsgeschwindigkeit) erst nativ dargestellt werden und nach einem kurzen Augenblick erst in der Zieldarstellung.
Wenn man die Verwendung von Templates selektiv deaktivieren könnte, wäre dijit vielleicht die richtige Wahl.
Welche Alternativen gibt es noch? Oder kennt jemand einen Weg, die Defizite von dijit zu umgehen?
Nach einigem Quellcodelesen habe ich festgestellt, dass dijit mittlerweile auch pre-rendered-Templates unterstützt. Das bedeutet, dass ein möglicher Ansatz wäre, serverseitig die Templates mit Nashorn zu rendern. Dadurch würde sich das Design der Komponenten nicht mehr im Browser ändern und Formulare wären ganz normal nutzbar.
Die Frage wäre dann nur, ob das problemlos mit Java geht…
Hier ist ein Beispiel, wie mit dojo 1.8 und Node.js serverseitig Widgets vorgerendert werden. Mit dojo 1.9 wurde die Unterstützung von serverseitig vorgerenderten Widgets verbessert (bessere Abstraktion in der Klassenhierarchie), sodass es noch etwas einfacher sein sollte, die Widgets zu rendern.
Da ich thymeleaf nutze, sollte es mit Nashorn und gradle ohne weiteres möglich sein, die Templates im Buildprozess zu rendern, sodass zur Laufzeit kein Overhead anfällt, aber die Templates trotzdem an zentraler Stelle ausgetauscht werden können. Das DOM sollte man mit einem beliebigen Parser erstellen und an den JS-Anteil zum Rendern übergeben können.
Gerade die Accessibility ist bei Javascript ganz schlecht. Egal welches Framework du verwendest.
Das gibt’s für einige Frameworks. Diese Technik nennt sich isomorphic Javascript. Je nach Framework ist das attachen schwerer bzw. leichter.
Ich entwickle gerne mit Angular. Puncto i18n gibt’s schon fix fertig Module die du verwenden kannst. (Siehe z.B. hier.) Pregerenderte Elemente könntest du mit einem $injector in die App bekommen.
Das ganze ist allerdings ein MV*-Framework das viel vorgibt. Auch wie man entwickeln sollte. Vorteil: Gut testbarer, kleine Module die man zusammen stecken kann. Nachteil: Komplex.
Ich glaube, AngularJS ist zu viel für meinen Anwendungsfall. Ich möchte keinen schwergewichtigen Client im Browser haben, sondern nur an der einen oder anderen Stelle die Interaktion des Nutzers mit der ansonsten klassischen Webanwendung erleichtern. Beispiele dafür sind Input-Validation (degradation zu reiner serverseitiger Validierung) oder Popups zur Eingabe von Einstellungen (mit degradation zu separaten Konfigurationsseiten).
Falls Angular auch auf diese Weise verwendet werden kann, korrigiere mich bitte - ich habe mich nur kurz mit einem Intro-Video beschäftigt.
Das Stichwort isomorphic JavaScript liefert interessante Suchtreffer - da werde ich nochmal ein bisschen stöbern.
Meiner Erfahrung nach ist das alles Overkill: In dem Labyrinth der Javascript-Frameworks wirst du dich nur verirren…alle sind ganz toll, ganz tolle Features,…MVC…Templates…dies und das.
Die behaupten aber doch alle, dass sie ganz ganz leichtgewichtig sind?
Was hast du denn am Server? JSF hat da zum Beispiel schon ein paar eingebaute Sachen, die für ein paar Popups oder Validiereungen reichen würden…
Ja, sehr einfach sogar. Allerdings ist die Voraussetzung, dass du den ganzen Rahmen lernst (Controller, Direktiven, Scopes,…etc). Ist aber eigentlich nicht so schwer.
Du suchst wohl eher eine Alternative zu jQuery. Da gibt’s Prototype. Ich verwende fast immer Bootstrap, welches ja auf jQuery aufsetzt, also kann ich dir puncto Widgets nicht helfen.
Also Angular ist viel aber sicher nicht leichtgewichtig. Das einzige was für Angular trotz des sehr einfachen Anwendungsfall spricht ist die eingebaute, saubere Dependency Injection. Aber da hört es dann auch schon wieder auf.
Aber wo ich dir recht geben muss: Die meisten JEE-Entwickler tun sich relativ leicht mit Angular.
*** Edit ***
Gerade erst gelesen. Das gibt’s auch fix fertig für Angular mit dem Template-Cache. (Gibt’s sicher auch für Grunt, wir verwenden aber Gulp :-P)
In unseren jQuery-Lösungen verwenden wir Handlebars und kompilieren die Templates nach Javascript das wir dann an die Applikation anhängen um ein einziges JS auszuliefern.
Ja, was die behaupten und was es für einen Rattenschwanz nach sich zieht sind zweierlei Paar Schuhe
Serverseitig habe ich schon eine sehr schöne Validierung mit Spring und JSR-303. Clientseitig bietet HTML5 ja auch einiges. Interessant wären für mich also eigentlich nur fertige Widgets, die die Darstellung (insbesondere asynchron) aufhübschen. Nichts weiter als Dialoge, Autovervollständigung und serverseitige Validierung, die ohne Absenden vom Formular ausgeführt wird.
*** Edit ***
Dann werde ich mir Prototype heute Abend auch noch mal ein wenig genauer ansehen. Es gibt ja so viele JS-Frameworks, dass es schier unmöglich ist, sich schnell einen Überblick zu verschaffen, wenn man noch nicht im Stoff steht.
Dann wirst du mit Prototype nicht glücklich werden. Das ist ein Framework aus der Zeit in der sich jQuery noch nicht durchgesetzt hat und ist dementsprechend nur für Ajax und DOM-Manipulation gebaut. So wie du es beschreibst wäre Bootstrap + jQuery + Handlebars (oder ähnliche Template-Engine) die beste Kombi.
Mit jQuery hatte ich schon mehrfach gearbeitet. Mir gefiel daran nicht, dass das Framework so zerstückelt wirkt (viele “selbstgestrickte” Plugins).
In jQuery UI fehlten mir einige Widgets, die zwar durch Plugins ergänzt werden konnten, aber dann von der Qualität her deutlich schlechter als der Rest waren.
Meintest du, dass du außer den bootstrap-Standard-Plugins keine Plugins für jQuery verwenden würdest, oder würdest du auf diese auch verzichten?
Ich habe mir die letzten zwei Stunden bootstrap mal angesehen und bin zu dem Ergebnis gekommen, dass es zu geschätzt 95% meinen Anforderungen entspricht (mit den „Standard-Plugins“ und typeahead für Autovervollständigung).
Die ganzen Ajax-Sachen könnte ich mit Standard-jQuery erledigen und da ich keine Cross-Domain-Requests benötige brauche ich auch keine speziellen Plugins dafür.
*** Edit ***
Eine JS-TemplateEngine brauche ich übrigens nicht, weil ich das ganz klassisch serverseitig (mit thymeleaf) erledige. In Puncto graceful degradation liegt man damit denke ich ein gutes Stück weiter vorn.
Außer jQuery und Bootstrap (also Bootstrap schon :-)) würd ich sonst nichts verwenden.
Das auf alle Fälle. Wir setzen hauptsächlich auf JS-Frameworks und so muss ich offen zugeben, dass bei uns alte und leider auch spezielle Browser für Behinderte nicht unterstützt werden.
Ich werde jetzt mal versuchen, meinen Buildprozess etwas zu erweitern und mit dem gradle-grunt-plugin und dem gradle-node-plugin bootstrap im build zu kompilieren.
Das hat auch den Vorteil, dass ich für meine anderen less-Files und ggf. anfallende JavaScript-Dateien bereits die richtige Buildumgebung integriert habe.
