Grails oder Spiel! für einen Ex-RoR-Entwickler?

Question

Ich plane ein Java Web Framework zu lernen (ich liebe die Java API) Ich habe bereits Rails und Django benutzt.

Ich möchte etwas in der Nähe von Java, aber ohne die ganze Komplexität von J2EE.

Ich habe 2 Frameworks gefunden, die gut für mich sein könnte:

Grails

Grails sieht gut aus, verwendet es Groovy, die für Web-Anwendung besser als Java ist (ich glaube, ..), aber es ist langsamer als pure-java-basierte Frameworks (Hibernate, Strut, Spring) Es sieht ziemlich einfach zu implementieren (senden .war und es ist in Ordnung!), das GSP ist großartig! Es ist ein bisschen schwieriger zu debuggen (muss den Server bei jeder Änderung neu starten und Stacktraces enthalten eine Mischung aus Java- und Groovy-Traces, die nicht immer am einfachsten zu verstehen ist)

Spielen!

Dieses Framework sieht auch gut aus; es ist schneller als Grails (Es benutzt Java), aber ich mag es nicht wirklich, wie es Java benutzt, es modifiziert den Quellcode, um die Property Calls als setXXX/getXXX zu transformieren, das mag ich nicht ... Das Framework hat auch ein Caching Funktion, die Grails nicht hat. Ich mag die Template Engine nicht wirklich. Es ist auch einfacher zu debuggen (keine Notwendigkeit, den Server neu zu starten, Stacktraces sind klarer)

Was empfehlen Sie? Ich bin auf der Suche nach etwas leicht zu lernen (Ich habe eine Menge Erfahrung mit Ruby, nicht so viel Java-Erfahrung, aber ich liebe die Java-API), voll funktionsfähig (Das ist kein Problem mit allen verfügbaren Java-Bibliothek, aber wenn es Bündel und integriert ich bevorzuge), hat gute Skalierbarkeit und ist nicht zu langsam (schneller als Ruby) Idealerweise würde ich gerne ein Framework mit einer anständigen Community verwenden, um einfach Unterstützung zu finden.

PS: Ich bin nicht daran interessiert in JRuby on Rails

Answer 1

Ich würde Grails vorschlagen. Es hat eine größere Community als das Play Framework (~ 350 Plugins, die so ziemlich jedes Grundbedürfnis abdecken). Außerdem ist grails fast vollständig in Java geschrieben, sodass Sie Groovy nur für Ihre domänenspezifische Implementierung verwenden können.

Wenn Sie auf ein Leistungsproblem stoßen, bei dem die groovigen Seiten, die Sie erstellt haben, der Flaschenhals sind, können Sie immer nur zu einer Java-Implementierung wechseln. Dann sind Sie im selben Boot, in dem Sie die ganze Zeit mit dem Play-Framework gespielt hätten. Sie haben Ihre Entwicklungszeit optimiert, indem Sie die Programmierung der Dinge in Java aufschieben, bis Sie wissen, dass Sie das wirklich tun müssen (was meiner Erfahrung nach sehr selten ist).

Ich bin mir auch nicht sicher, wo Sie gehört haben, dass Sie Ihren Server für jede Änderung neu starten müssen, aber das stimmt nicht. Grails unterstützt das erneute Laden von Controllern/gsps/services/domain objects usw., ohne dass der Server neu gestartet werden muss.

Die gemischten Stacktraces können ein wenig lang werden, aber Werkzeughersteller (wie Intellij) haben kürzlich einige Verbesserungen vorgenommen, die alle Stacktrace-Bereiche aussortieren, die Sie nicht interessieren.

Ich benutze Grails seit den .5 Tagen und war sehr glücklich mit der Plattform.

Answer 2

Es gibt auch Lift auf Scala.
Imho Scala ist die beste statische typisierte Sprache und Lift ist ein ziemlich schönes Framework (für eine statische typisierte Sprache).

Answer 3

Wenn Sie bereits Ruby und Python verwendet haben, werden Sie wahrscheinlich Grails besser als Play genießen. Es ist sehr schwierig, zu Java zurückzukehren, wenn Sie mit diesen dynamischen Sprachen vertraut sind.

Answer 4

Beachten Sie, dass die Play! framework now supports using Scala als 1,1

Answer 5

ich von Grails wechselte zu spielen, und ich sah nie zurück. Mein größtes Problem mit Grails war die allgemeine Robustheit und Entwicklerfreundlichkeit. Die meiste Zeit wurde ich von der Tatsache gebissen, dass Grails den üblichen Stapel von Spring MVC und Hibernate zusammenklebt, während ich versuche, diese Tatsache zu verbergen und dir eine Rails-ähnliche API zu geben (persönliche Meinung von mir). Das Problem damit ist, dass, sobald etwas über die trivialen Beispiele hinausgeht, es leicht kaputt ging und nicht für mich funktionierte. Sich damit zu entwickeln war wie auf Eiern zu gehen (für mich). Wann immer ich nach Dokumentation für ein Feature suchte, das ich brauchte, wurde ich nicht zu Samples, Tutorials, Blogs weitergeleitet, sondern zur Grails JIRA, die mir erklärte, warum das Feature für meinen Anwendungsfall nicht funktionieren würde und dass der Fehler seit zwei Versionen nicht gelöst war Ich benutzte.

Während das nicht die allgemeine Erfahrung für jeden Entwickler ist (ich schreibe das nicht, um Grails zu vereiteln, aber um meine Erfahrungen damit hier zu geben), brauchte ich etwas, das mir half und mir nicht im Weg stehen oder brechen würde runter auf mich, wenn ich es am meisten brauchte. Das ist, als ich Play gefunden habe und ich meine App schnell darauf umgestellt habe, nachdem ich davon erfahren habe (um die Version ~ 1.0).

Bis jetzt war es eine großartige Fahrt und zum ersten Mal in meiner Karriere als Webentwickler habe ich aufgehört, andere Frameworks zu suchen, die versuchen, etwas zu finden, das mir besser gefallen würde.

Wenn ich mit einer Sache schließen müsste, dass Play besser war als Grails - zumindest für mich -, wäre es die Tatsache, dass das Play von Grund auf mit Entwickler Usability im Hinterkopf gebaut wurde. Es opfert nicht Benutzerfreundlichkeit für Unternehmensbuzzwords. Es hat den Mut, alles wegzuwerfen, was nicht in dieses Paradigma passt (z. B. Servlet-basierte Laufzeiten während der Entwicklung für einen schnelleren Turnaround zu mindern). Es ist bereit, Kompromisse zu machen, um Ungeheuerlichkeit zu garantieren. Und das habe ich erst in Communities wie Rails oder Django gesehen, bevor ich Play fand.

Answer 6

Aus meiner Erfahrung mit Play ist es ein großartiger Rahmen. Meine Lieblingsfeatures sind das coole Controller-System und das Template-System - beide sind einfach, aber funktionsreich und leistungsstark.

Der wichtigste Vorteil von Play ist jedoch definitiv der schnelle Entwicklungszyklus, bei dem Codewechsel praktisch nicht neu geladen werden müssen. Aber wenn Sie nicht aufpassen, wird diese Größe nicht viel dauern, und Langsamkeit wird schließlich in Ihren Code kriechen.

Warum ist das? Mit Play werden einige Plugins mit ziemlich starker Initialisierung verwendet, insbesondere EJB (Hibernate) und Spring. Die Initialisierung dieser Plugins wird bei jeder Codeänderung erneut ausgeführt, bevor der neue Code geladen wird. Wenn Ihr Modell und Ihre Systemkonfiguration anwachsen, beginnt diese starke Initialisierung, Ihre Entwicklung ernsthaft zu verlangsamen. In dem System, das ich verwendete, waren 20 Sekunden eine typische Startzeit auf einer virtuellen Maschine, die auf einem Kickass-Laptop lief.

Was Sie tun können, um dies zu vermeiden, hängt von Ihrer Anwendung ab, z. Wenn Sie eine NoSQL-Anwendung erstellen, sollte Ihnen das EJB-Plugin keine Probleme bereiten. Spring kann durch ein benutzerdefiniertes hartkodiertes Java-Plugin ersetzt werden, das IMHO auch leichter zu pflegen ist, oder ein Groovy-Skript ausführen, wenn die Skriptfähigkeit so wichtig ist. Achten Sie auf jeden Fall auf diese Probleme und töten Sie sie, während Sie noch jung sind. Achten Sie darauf, dass Sie bei jeder Aktualisierung keine eigenen sperrigen Initialisierungen ausführen.