Vor rund zwei Jahren begannen wir die Entwicklung einer Web-Applikation. Aufgrund vorhandener Skills im Bereich Groovy & Java, wurde Grails als Framework gewählt.
Immer wieder schien das Framework, das sich mit dem Slogan “the search is over” brüstet, einer effizienten Entwicklung Steine in den Weg zu werfen.
Einfache Aufgaben erforderten komplexe Eigenprogrammierungen und kritische Fehler blieben unbehoben. Als der Veröffentlichungstermin der nun aktuellen Grails-Version 2 über das Jahr 2011 hinweg mehrmals verschoben wurde, kamen erste Zweifel auf.
Im Februar 2012 war unsere Applikation technisch bereit für den Go-Live. Die Fehleranfälligkeit und Komplexität von Grails veranlasste uns dennoch dazu, Alternativen zu suchen anstatt weitere Zeit mit diesem mangelhaften Werkzeug zu verschwenden.
Das Projekt wurde mit Rails neu gestartet und befindet sich seither in rascherer Entwicklung als zuvor.
Seit 4. Juli 2012 ist das Projekt Corilla im Grundumfang online und überschreitet in Bezug auf Stabilität und Geschwindigkeit sämtliche Erwartungen.
Vergleich
Im Folgenden sind die Vorteile von Rails gelistet welche innerhalb der ersten beiden Monate im Rails-Projekt sofort positiv aufgefallen sind.
Sie sind in der Reihenfolge gelistet in der sie bemerkt wurden. Somit ist die Reihenfolge ohne Bezug zur Relevanz des jeweiligen Punktes.
Verglichen wird die Rails Version 3.2 mit Grails 2.0.
SQLite vs. H2 als Datenbank in der Entwicklungsumgebung
Rails verwendet in der Development-Umgebung standardmäßig SQLite als Datenbank – Grails 2 setzt auf H2.
- H2 ist eine in-memory Datenbank. Sämtliche Datensätze gehen beim Neustart der Applikation verloren. Testdatensätze muss man stets neu anlegen.
- Die SQLite-Datenbanken werden im Projektverzeichnis gespeichert. Bei Bedarf können sie somit auch einfach in die Versionsverwaltung aufgenommen werden (obgleich das Format dafür eher ungeeignet ist).
Tatsächlich sollte man bei der Entwicklung jenes DBMS verwenden, welches auch in der Produktivumgebung zum Einsatz kommt. Dennoch ist für einen raschen Start der Rails-Ansatz klar vorzuziehen.
Design aus Scaffolding
In Rails ist das generierte Design aus dem Scaffolding Generator simpel gehalten. Damit ist es sinnvoll als Vorlage nutzbar.
In Grails ist der Aufwand, die ungewollten Teile zu löschen, oft größer als der Vorteil überhaupt erst ein Scaffolding für die Views zur Verfügung zu haben.
Rails Validations – Grails Constraints
Datenvalidierung passiert in Rails lediglich auf Applikationsebene.
Grails hinterlegt zusätzlich Datenbank-Constraints. Während letzteres definitiv als Best-Practice anzusehen ist, führt es wiederum zu Problemen welche die Vorteile nichtig machen.
Im Rahmen eines Grails Feature-Request wurde ein case-insensitive Constraint gefordert, der in quasi jeder Webapplikation zumindest für E-Mail Adressen notwendig ist. Die Idee wurde mit der widersprüchlichen Begründung abgelehnt, dass die Anforderung zu stark von der verwendeten Datenbank abhängen würde.
Während eine manuelle Implementierung in Grails via .withNewSession zu weiteren Verkomplizierungen bei Unit-Tests führt, bietet Rails standardmäßig die notwendige Flexibilität. Die folgende Definition erfüllt die Anforderung:
:uniqueness => { :case_sensitive => false }Applikations-URL in Entwicklungsumgebung
In Rails kann die Applikation unter http://localhost:3000 abgerufen werden, während Grails zusätzlich den Applikationsnamen erfordert (http://localhost:8080/grailsapp).
Der kleine Vorteil der Rails Variante ist, dass nur ein Lesezeichen im Browser ausreicht um die jeweils in Entwicklung befindliche Applikation aufrufen zu können.
Grails hat den zusätzlichen Nachteil dass bei Falschschreibung des Applikationsnamens in der URL eine komplett leere Seite erscheint.
Als Konsequenz suchte ein Entwickler unnötig nach einem Fehler als der Applikationsname von Klein- auf Großschreibung geändert.
Das entsprechende Lesezeichen war ungültig geworden.
Scaffolding Formulare
In Rails wird für die generierte edit- und new-Action auf das gleiche Formular-Template (“partial”) zurückgegriffen, was im Großteil der Webapplikationen gewünscht ist und den Quellcode DRY hält.
Grails hingegen generiert für beide Actions jeweils eigene Formulare welche man erst mühevoll zusammenführen muss, um dem DRY-Prinzip folgen zu können.
Log Ausgaben
Das Logging in Rails beinhaltet die tatsächlichen Werte. Fehler in SQL Anweisungen können somit rasch gefunden werden.
(Besonders interessant in diesem Zusammenhang ist die Unterstützung für EXPLAIN.)
In Grails fehlen die Werte – stattdessen sind nur Fragezeichen sichtbar.
Festlegung von “variablen” Constraints
Constraints werden in Grails nur beim Start evaluiert.
Legt man beispielsweise fest, dass eine Datumsfeld nur ein Datum vom aktuellen Tag oder davor beinhalten darf, wird für die Auswertung der Tag des Starts der Webapplikation (!) genutzt. Ein entsprechender Bug-Report beschreibt das Problem.
In Rails kann die Aufgabenstellung mittels eines lambda gelöst werden.
Generell ist das Arbeiten mit Datumseinträgen in Grails schrecklich komplex – auch wenn man Joda Time zur Vereinfachung einsetzt.
Definition von Models
Die entsprechende Grails Syntax hierfür ist einfach gestaltet. Beispielsweise kann ein Datenbankfeld auf Basis einer selbst definierten Klasse definieren (MyClass fieldname). Grails kümmert sich dann intern um die entsprechende “Übersetzung” auf Datenbankebene.
Das in diesem Fall etwas irreführende Schlüsselwort “belongs_to”, welches bei Rails zum Einsatz kommt, ist oft schwieriger nachzuvollziehen aber letztendlich flexibler.
Methoden: Rückgabewert oder Veränderung des Objekts?
Dieser Punkt ist eher ein Vergleich “Ruby vs. Java” als “Rails vs. Grails”.
In Java ist kaum erkennbar, ob eine Methode das aufrufende Objekt ändert oder nur einen entsprechenden Rückgabewert liefert. Man bedient sich hoffnungsvoll der Logik oder muss in den Dokumentationen nachsehen.
Ein Rufzeichen am Ende eines Methodennamens deutet in Ruby-Konvention auf eine Änderung des aufrufenden Objekts hin – oder verlangt eine Exception im Fehlerfall.
Massen-Zuweisung von Werten
Mass-Assignment birgt das Risiko in sich, Benutzern versehentlich das beliebige Befüllen von Datenbankfeldern zu erlauben auf welche der Zugriff eigentlich verwehrt ist.
In Grails vermeidet man das Risiko grundsätzlich nur durch Verzicht auf die Funktionalität.
Rails bietet eine sichere Lösung:
config.active_record.whitelist_attributes = trueConstraints für E-Mail Adressen
Fern man auf ein entsprechendes Plugin verzichtet, muss man in Rails die Validierung von E-Mail Adressen selbst definieren. Je nachdem wie streng man RFC-Konformität anstrebt, kann sich das Unterfangen sehr komplex gestalten.
Grails bietet hingegen einen email-Constraint.
Stacktraces
In Rails sind die Stacktraces generell kürzer. Fehlermeldungen sind aus bisheriger Erfahrung stets deutlich und ermöglichen ein rasches Finden und Beheben von Fehlern.
Grails ist zum Großteil in Java geschrieben (!). Dadurch werden die Stacktraces weit länger und es ist oft unklar ob man mit einem Fehler in der Applikation oder im Framework selbst konfrontiert ist.
Weit schlimmer ist allerdings dass man für die Nutzung von Grails zwei Sprachen beherrschen muss: Groovy und Java.
Dabei ist sind die Anforderungen an Java-Fertigkeiten besonders hoch.
Rails ist ausschließlich in Ruby implementiert. Es ist unnötig C Quellcode zu lesen.
(Obgleich die Ruby-Standardimplementierung selbst in C geschrieben ist.)
Tests und Test-Driven Development
Tests laufen in Rails schneller als in Grails.
Besonders wichtig ist, dass man in Rails die Tests auch jederzeit starten kann während man den Webserver in der Entwicklungsumgebung (localhost:3000) betriebt.
In Grails scheitert dies. Entweder der Entwicklungsserver oder die Tests laufen.
Routing und erlaubte Requests
In Rails bestimmt das Routing, also die Rake Middleware, welche Request-Arten (GET, DELETE, POST, PUT) für welche Action erlaubt sind.
In Grails muss man dies explizit abfangen um die Applikation zusätzlich abzusichern oder eine unterschiedliche Handhabung zu erreichen.
Flexibilität des Datenbankmodells
Rails Migrations sind für uns der Vorteil von Rails. Sie ermöglichen eine flexible Entwicklung. Ruhigen Gewissens kann man eine Struktur nutzen und, sollte sich heraus stellen das ein Ansatz ungünstig war, rasch auf eine andere Modellierung wechseln.
Ein Grund warum unser Projekt auf Grails-Basis über den Entwicklungszeitraum hinweg offline blieb, war die Sorge das gröbere Änderungen am Datenmodell einen großen Mehraufwand beim manuellen Migrieren erfordern würden.
Mit den Migrations von Rails ist diese Sorge gänzlich beseitigt.
Arbeit mit Datum und Uhrzeit
Viele Date-Funktionen in Java (Grails) sind zu Gunsten des unnötig komplexen Calendar-Konzepts überholt (deprecated). Joda Time vereinfacht den Umgang ein wenig, führt aber andererseits auch zu Schwierigkeiten und notwendigen Konvertierungen vor dem Speichern in die Datenbank.
Die Einfachheit der Ruby/Rails Methoden spricht für sich selbst:
x = 5.hours.from_now
year = x.year
currently_open = Time.now.between? opens_at, closes_atAuslesen der Instanzvariablen des Controllers
In Rails können mittels der assigns() Methode die im Controller gesetzten Instanzvariablen “von Außen” abgefragt werden. Das ermöglicht ausgesprochen einfache funktionale Tests. Folgendes Beispiel prüft ob die Anzahl der aufgelisteten Aktivitäten mit der Anzahl in der Datenbank überein stimmt.
activities_count = 3
# 3 Aktivitäten erstellen
activities_count.times do
FactoryGirl.build(:activity)
end
# Anzahl der Aktivitäten aus index-action überprüfen
get :index
assert_equal activities_count, assigns(:activities).countIn Grails hingegen ist uns nur die komplizierte Möglichkeit über GUI-Selektoren bekannt. Der Aufwand für derartige Tests spricht aber selten dafür, sie auch tatsächlich einzusetzen (vgl. Beitrag zu Geb Functional Testing).
Hilfreiche Fehlermeldungen
Fehlermeldungen in Rails sind oft überraschend ausführlich. Folgendes Beispiel zeigt eine klare Formulierung. Sie beinhaltet sogar Vorschläge zur Korrektur (!) und eine passende Vermutung:
ActiveRecord::HasManyThroughSourceAssociationNotFoundError: Could not find the source association(s) :subscribed_activity or :subscribed_activities in model Subscription. Try ‘has_many :subscribed_activities, :through => :subscriptions, :source =>
’. Is it one of :subscriber or :activity?
In Grails folgt man oft der falschen Fährte.
JavaScript standardmäßig unaufdringlich
In Rails wird JavaScript standardmäßig “unaufdringlich” (unobstrusive) gehalten.
Möchte man JavaScript in einer Grails Applikation unobstrusive halten, muss man auf die Unterstützung durch das Framework verzichten und die entsprechenden Funktionen selbst programmieren.
Vorkompilierte Klassen
Nur in seltenen Fällen ist in Rails während der Entwicklung ein Neustart der Applikation erforderlich – beispielsweise nach dem Hinzufügen neuer Plugins (Gems).
Ansonsten ist es allerdings sogar möglich den aktuellen Entwicklungsstand aus einem Repository zu ziehen (git pull) ohne Schwierigkeiten erwarten zu müssen.
Ein gesonderter Säuberungslauf ist unnötig.
In Grails kommt es regelmäßig vor, dass sonderbare Probleme wie aus dem Nichts auftauchen zu scheinen. Aus Erfahrung weiß man später, dass nur ein Säuberungslauf Abhilfe schaffen kann. Im Detail bedeutet das:
- Applikation stoppen
- Säubern (
grails clean) - Applikation starten (
grails run-app)
Der Ablauf kann je nach Umfang der Applikation mehrere kostbare Minuten beanspruchen.
Das Grails-Plugin N.A.D.D. Neutralizer unterstreicht die Ironie:
This plugin will use text to speech to tell you when key events in your build are complete. So say you are like me with a project that takes several minutes to start after grails run-app. You can, guilt-free, go browse your favorite sites without worrying about getting caught up in something. When your app is up and running, this plugin announces on your speakers, “Application is running!”
Alleine die Existenz eines solchen Plugins sollte skeptisch machen.
Plugin-Infrastruktur
Die Verwaltung von Gems in Rails ist dank Bundler sehr einfach.
Die Grails Plugin-Infrastruktur ist sehr streng und erlaubt den Entwicklern Kompatibilitätsanforderungen zu hinterlegen. Da diesen für gewöhnlich unbekannt ist, mit welchen Versionen ihr Plugin funktioniert, tragen sie oft sonderbare Grenzen ein. Umerziehungsmaßnahmen seitens der Grails Advokaten schlagen fehl und so passieren Dinge wie das folgende:
Quartz am 22.04.2012:
| Error Plugin quartz-1.0-RC1 requires version [1.2 > 1.3.7] of Grails which your current Grails installation does not meet. Please try install a different version of the plugin or Grails.
In diesem Beispiel stand keine andere Version des Plugin zur Verfügung. Allerdings ist davon auszugehen, dass die Versionsobergrenze (1.3.7) schlichtweg falsch gesetzt war und das Plugin durchaus auch mit der Grails Version 2 kompatibel wäre.
Speicherverbrauch
Für die Grails Entwicklung sollten mindestens 1,6 GB freier Hauptspeicher zur Verfügung stehen.
Rails ist mit einer Anforderung von rund 800 MB nur halb so gierig.
Im Folgenden ist die Aufteilung der Ressourcen beschrieben.
Frameworks
Der Rails Serverprozess (WEBrick) beansprucht 75 MB Hauptspeicher.
Die Grails Applikation mit ähnlichem Funktionsumfang benötigt mit 800 MB das Zehnfache (!)
Entwicklungsumgebungen
Sowohl RubyMine (für Ruby/Rails) als auch IntelliJ IDEA (für Java/Groovy/Grails) werden vom tschechischen Unternehmen JetBrains entwickelt. Es kann also davon ausgegangen werden, dass die Qualität der beiden Entwicklungsumgebungen auf ähnlichen Niveau befindet.
Der Speicherverbrauch von IntelliJ IDEA (Grails) mit gestarteter Applikation liegt laut eines kurzen Tests bei 780 MB.
RubyMine (Rails) verbraucht rund 600 MB.
Von einer Entwicklung mit SpringSource STS (Eclipse) oder NetBeans ist übrigens abzuraten. Beide bieten in Bezug auf die Grails Entwicklung kaum Vorteile. Ein guter Texteditor ist vorzuziehen.
HTML via content_for
Mit Methoden wie content_for(), bietet Rails elegante Möglichkeiten um HTML zu generieren. View Helper bleiben übersichtlich und sicher.
Vergleichbares könnte man in Grails theoretisch mittels der Builder erreichen, aber letztendlich ist dort das manuelle Zusammenstückeln der Elemente noch der sinnvollste Weg.
HTML Escaping
In Rails werden View Ausgaben (<%= ... %>) standardmäßig maskiert (escaped). Dadurch werden viele potentielle Angriffspunkte wie XSS geschlossen.
(Tipp: Benennt man einen Übersetzungsstring in einer i18n-Datei mit der Endung _html weiß Rails automatisch, dass für den hinterlegten Text das Escaping ausgesetzt werden soll)
Ein Grails-Projekt sollte man mit der entsprechenden Konfiguration absichern:
grails.views.default.codec = "html" // none, html, base64Array Zugriff
In Groovy (Grails) wird eine Exception ausgelöst, wenn der abgefragte Bereich die größe des Arrays übersteigt. In einem Beispiel wie diesem muss man zuerst die Gesamtlänge abfragen, um dann entsprechend “korrekt” zugreifen zu können: "123"[0..10]
In Ruby (Rails) spart man sich die Abfrage. Im obigen Beispiel erhält man einfach “so viel wie möglich” – also das Array von 0-2.
Case insensitive scoped uniqueness
In diesem Grails Beispiel wird sichergestellt, dass ein Veröffentlicher ( scope ) keine Events mit gleichem Titel ( uniqueness ) veröffentlicht. Dabei soll Groß-/Kleinschreibung ignoriert werden ( case-insensitive ).
title (nullable: false, blank: false, unique: false, size: 5..30,
validator: { val, obj -> (
/* checks if the publisher has published an event with the exact same title (case-insensitive match) */
!Event.withNewSession { // if the get() returns an event, then this is an update - which is fine
!Event.get(obj.id) && Event.findAllByTitleIlikeAndPublisher(val, obj.publisher)
}
)}
)Das Gleiche in Rails:
validates :title, :length => { :in => 5..30 },
:uniqueness => { :case_sensitive => false, :scope => :publisher_id }Variablenübergabe an Views
Alle Instanzvariablen (@variblenname) aus der entsprechenden Action sind in Rails von der View aus verwendbar.
In Grails muss Alles in Form einer Map explizit aus dem Controller übergeben werden.
Counter-Cache
Um die Anzahl der zugehörigen Objekte zu finden stellt Rails die counter_cache Funktionalität bereit. Per Konvention wird bestimmt welches Feld benutzt werden soll.
Möchte man in Grails vermeiden bei jedem Aufruf ein SQL COUNT() abzusetzen, müsste eine ähnliche Funktionalität mittels diverser Interceptors manuell implementiert werden.
“Kleinigkeiten” wie diese zeigen vor allem auf, wie weit Rails bereits in den Details durchdacht ist, während Grails beständig “am Anfang” stehen zu scheint.
Fazit
Grails mag dank Groovy für Java-Veteranen (!) eine Erleichterung bieten. Als Framework ist es allerdings weit von den dem entfernt was die Eigenwerbung verspricht.
Für agile Web-Entwicklung und das schnelle Erreichen von Releases ist es schlicht ungeeignet.
Rails hingegen scheint sämtliche Best-Practices in der Web-Entwicklung zu vereinen und als Standard vorzulegen.
Der Arbeitsverlauf steckt voller positiver Überraschungen und das Endergebnis kann sich sehen lassen.
Ohne irgendwie bewerten zu wollen: warum genau braucht man Java-Kenntnisse für Grails? Was waren wirklich die grossen Probleme mit Grails? Weil, ganz ehrlich: SQLite vs H2 kanns nicht sein, ein schon fast fertiges Projekt abzubrechen...
sehr interessanter Artikel den du da geschrieben hast.
Ich selbst habe öfters mit kleinen Problemen in Grails zu kämpfen. Kinderkrankheiten, die dich praktisch um Tage zurück werfen. Ein Freund von mir schwört auf Rails, aber bis heute konnte ich es mir nicht angucken bzw. habe mir die Zeit nicht dafür genommen, da ich fest davon überzeugt war, dass Grails besser sein muss.
Das Scaffolding der Formulare, dass du angesprochen hast, ist im aktuellen Grails aber genau so wie in Rails. (Ein Formular-Template) Ebenso bietet Grails in der aktuellen Version (2.1) standardmäßig Migration-Möglichkeit.
Das Problem mit Datum und Uhrzeit ist leider immer so ein leidiges Thema in Java als auch noch in Grails...dank JodaTime gehts ja noch...
Noch bin ich nicht ganz überzeugt, dass Rails nun wirklich die bessere Wahl ist. Ich werde wohl auch beide Frameworks vergleichen müssen. Bin gespannt auf die Diskussion hier! Und wäre cool wenn du dir noch einmal das aktuelle Grails 2.1 anschauen könntest und dann nochmal schlussfolgerst. :-)
Based upon your article ... I think you should gain more Grails experience before writing a review or comparison. Your examples are from a novice perspective and not really obstacles or limitations.
*@KoW*
Der Artikel beschreibt, chronologisch sortiert, die positiven Auffälligkeiten aus den ersten Monaten mit Rails im Vergleich zu zirka 20 Monaten Grails-Erfahrung.
Mir ist wichtig, dass die Intention dieses Artikels verstanden wird:
* *Ziel:* Eine Entscheidungshilfe zu bieten (statt glückliche Grails-Nutzer von "ihrem" Framework abzubringen).
* *Motivation:* Ich hätte mir damals selbst einen Artikel gewünscht, der _spezifische_ Punkte anspricht, statt die beiden Frameworks nur oberflächlich zu betrachten. Nun gibt es ihn und möglicherweise erspart er Anderen unnötig investierte Zeit.
* *Nutzen:* Die Leser haben hiermit die Möglichkeit auf die Erfahrung von jemanden zurückzugreifen, der mit _beiden_ Frameworks tatsächlich gearbeitet hat, statt die Frameworks auf Basis _einseitiger_ Erfahrungsberichte und Sichtweisen einschätzen zu müssen.
*Probleme aus technischer Sicht*
Einen negativen Beitrag zu verfassen, welcher nur die Fehler von Grails aufzeigt, wäre für die Leser nutzlos und im Prinzip nur die Wiedergabe unzähliger "Grails JIRA Issues":http://jira.grails.org/secure/IssueNavigator.jspa, welche im Projektverlauf aufgefallen sind.
_Die meisten jener Bugreports sind nach wie vor offen oder wurden ohne Lösung geschlossen._
Genau diese Fehler behindern die effiziente Entwicklung. Möchte man sie beheben, oder _zumindest_ umgehen, muss man auf umfassende Java-Kenntnisse zurückgreifen, da Grails eben zum Großteil in dieser Sprache geschrieben ist.
*Probleme aus "geschäftlicher" Perspektive*
Entwicklungszeit ist wertvoll. Mit Rails erreicht man in weniger Mannstunden elegantere Lösungen, die einfacher zu warten sind.
Währenddessen behindern die Fehler in Grails das effiziente Arbeiten. Hier passierte es auffällig oft, dass kleine Programmieraufgaben einen Manntag Umsetzungszeit erforderten, weil Probleme des Frameworks behandelt werden mussten.
Ich hoffe die Erläuterungen machen die Gründe etwas deutlicher und helfe gerne bei weiteren Fragen.
*@Patrick Hütter*
Danke für deine Erfahrungen zum Thema.
Ich habe mir gestern "Whats new in Grails 2.1?":http://grails.org/doc/2.1.0/guide/introduction.html#whatsNew21 aus der offiziellen Dokumentation durchgesehen, konnte allerdings keine besonderen Vorteile feststellen.
Wichtig ist zu erkennen, dass im Fall von Grails weniger die Software an sich das Problem darstellt - Ich bin überzeugt, dass kluge Köpfe am Grails-Core arbeiten und dabei hochwertigen Code schreiben.
Grails bietet weit weniger Möglichkeiten als Rails, weil eben auch für diese Entwickler der Tag nur 24 Stunden hat.
Unser Projekt begann in der damals aktuellen Grails Version 1.3.3 (Jahr 2010). Das Framework wirkte dauernd - und besonders ab Version 2 - als befände es sich im Alpha-Stadium.
Ein gutes Framework deckt - auch mit seinen Plugins - so viele absehbare Anwendungsfälle wie möglich in hoher Qualität ab und verringert so den individuellen Entwicklungsaufwand.
Meine "beste Vermutung" dazu, woran Grails letztendlich scheitert ist die mangelnde Verbreitung.
Interessant ist deine Überzeugung, dass Grails "besser sein muss". Worauf basiert sie?
*@Jeff Pogo*
I disagree. 20 months should definitely suffice. I suspect the intention of the article along with the answer to the question why it was held in such a fashion might have been lost in translation.
Certainly, _Java_ veterans will find ways to work around limitations more easily. However, the point of a framework should be to provide means of simply & quickly accomplishing common goals instead of introducing new forms of issues which a - regardless how experienced - developer has to cope with.
Der Artikel ist aus meiner Sicht nicht objektiv - schon der Titel legt dies nah. Was hat das Herausgreifen von ein paar Punkten mit einem "ultimativen Showdown" zu tun?
Eine Sache, die wohl mit Deinem Urteil zu tun hat, ist der Punkt mit dem Java-Hintergrund (ich bin ja der Ansicht, dass auch Ruby keine schöne Sprache ist, was die Syntax angeht, aber das ist etwas anderes). Ja, wer ein Grails-Projekt fährt, sollte definitiv auch mit Java umgehen können! Es ist aber wohl eher ein Fehler im Projektmanagement, wer dies nicht einsehen möchte oder weiß, als dem Framework aufgrund mangelnder Erfahrung Fehler nachzusagen.
Dass man mit Java umgehen können sollte ist aber auch klar, denn Grails ist mit Groovy und dieses wiederum unmittelbar mit Java verbunden.
Wenn man ein Android-Projekt macht, wird man auch eher Leute mit Java-Hintergrund bevorzugen. Dasselbe bei iOS - wer vorher mit C oder C++ seine Erfahrung gesammelt hat, wird hier wesentlich schneller zu Rande kommen.
Um noch auf ein paar weitere Punkte einzugehen:
In der Regel geht man bei Grails bei wirklich kritischen Bugs schnell auf die Tickets ein. Im Falle der Datums-Geschichte wäre es vermutlich ein Ein-Zeiler, um einen Validator zu schreiben. Eine Closure und fertig.
Den Punkt mit der DB finde ich nicht plausibel. Was ist an einer SQLite besser? Immerhin wäre man interessant zu wissen, welcher der kleinste gemeinsame Nenner bei Rails-Datenbank das ist, was in der Java-Welt JDBC ist. Zudem kann man ja in Grails ganz einfach eine MySQl, Postgres, Oracle usw. einbinden.
Was die DB-Migrationen angeht, sollte man wissen dass es hierfür ein hervorragendes "dbm"-Plugin gibt.
In Bezug auf den immensen Speicherverbrauch und das HTML-Escaping gebe ich Dir recht.
Nichts für ungut,
Georg
Das Herausgreifen bestimmter Punkte ist Sinn und Zweck des Artikels. Er verschafft mittels spezifischer Vergleiche einen Überblick. Eine vollständige Darstellung bietet (nichtmal) das Studieren der Quellcodes beider Projekte.
Es freut mich, dass du die Abhängigkeit zu Java bestätigst.
Vor allem jene die sich nur theoretisch oder im Rahmen von Projekten mit minimalem Umfang mit Grails beschäftigen, glauben mit Groovy auskommen zu können. Diese Überzeugung wird leider seitens des offiziellen Marketings gefördert und führt somit zu falschen Erwartungen und Überzeugungen.
Interessant ist allerdings, dass in unserem Fall mehrere Jahre kombinierte Java- sowie Monate Groovy-Erfahrung zur Verfügung standen. Ruby wurde erst im Rahmen des Projekt-Neustarts gelernt.
Der folgende kritische Bug bezieht sich auf *Spring Security Core* und *Resources* - zwei Kernelemente jedes Grails-Projekts. Er wurde lange ignoriert und besteht nun nach einem Jahr nach wie vor - ein Muster das sich in ähnlicher Form auch bei anderen Bugs abzeichnet.
"GPSPRINGSECURITYCORE-98":http://jira.grails.org/browse/GPSPRINGSECURITYCORE-98
Jetzt sind ein paar Wochen vergangen seitdem ich deinen Artikel gelesen habe und er ist mir eben wieder eingefallen, als ich wieder mal Probleme im Grails Ökosystem hatte. Ich weiß nicht ob das bei Rails besser ist, aber das Problem bei Grails ist einfach, dass die Plugins teils nicht genug pepflegt werden und sie bei Updates schnell outdated sind. Wenn dann keiner diese Plugins updated oder anpasst an die neue Umgebung muss man wieder selbst Hand anlegen, da man sonst nicht weiter kommt oder mit seiner eigenen Applikation stehen bleibt oder nicht upgraden kann.
Ich hänge jetzt seit 3 Tagen an einer eigentlich recht simplen Sache: Ich möchte die Sessions in der Datenbank speichern, damit ich darüber Cookie und User-Tracking betreiben kann. Desweiteren möchte ich meine App später ggf. bei Heroku deployen. Ich nutze Spring Security für die Authentication. Eigentlich ein recht simples Setup denkt man sich: grails-database-session, spring-security-core und heroku Plugin installieren. Klappt aber nicht! Weil a) database session Plugin outdated => Entwickler kontaktieren oder selbst basteln b) Spring Security Core sich nicht an die Definitionen hält und nach einem Logout auf die Session zugreift => Lauter Exceptions wenn man das database session Plugin nutzt => Workaround: Plugin anpassen c) Um auf Heroku zu deployen, muss man zwingend die Sessions in der DB speichern, da Heroku die Sessions nicht skalieren kann, also kann man nicht wirklich produktiv auf Heroku deployen, da es kein Setup gibt, dass sauber ohne Fehler funktioniert. Und das, obwohl Grails stark damit wirbt so gut für die "Cloud" zu sein.
So Fälle habe ich immer wieder vereinzelt, wenn es eben nicht nur um "CRUD" geht. Ich denke Grails ist ein gutes Framework, aber wie du schon sagtest, fehlt es an Verbreitung und dementsprechend die Community dahinter.
Ich werde in nächster Zeit auch mal Rails testen.
Thanks for the blog entry. I was able to read it with Chrome translator.
As far as goes "Date and Time" there is a MagicNumbers plugin.
http://grails.org/plugin/magic-numbers
bq.:http://www.77dev.com/2012/11/grails-vs-rails.html Grzegorz, I think the reason for missing comparisons based on real development experience is ignorance.
People who start out with any framework often simply *assume* that they are already using the best framework available. After all, that's what the marketing told them, right?
Besides, allowing the thought that their current framework is a fail, would mean they'd have to redo their project from scratch or, at least, accept the fact that they'd wasted time by aggregating knowledge about it.
_Our experience after working intensively with both, Grails and Rails, has been the same as yours: One promises, the other delivers._
In order to provide developers with the opportunity to get a solid impression, we compiled a comparison based on a real-life project.
It emerged while reimplementing that project in Rails. Thus it highlights the differences based on details of common challenges that most projects will face within the first couple of weeks/months.
http://groovy-skills.com/Grails/2012/08/19/ultimativer-showdown-grails-vs-rails/
(The article is in German, so you might want to use a translator.)
Hallo,
Ein sehr guter Beitrag der mich zum Nachdenken angeregt hat.Momentan bin ich in einer frühen Phase der Evaluation beider Frameworks und muss sagen bis jetzt sind beide Frameworks exzellent durchdacht und ich schwanke noch zwischen Rails und Grails.
Aber als Reviewanmerkung:
SQLite vs. H2 als Datenbank in der Entwicklungsumgebung (sehr guter Punkt)
H2 kann als InMemory oder als FileDb sehr einfach eingestellt werden. InMemory ist praktisch in einer sehr frühen Prototypephase. Ein Umschalten auf Filebasierten zugriff ist ebenfalls in GRAILS möglich und sehr einfach. Also hier ist meiner momentanen Meinung nach das H2 Modell sogar einen Sprung vor dem SQLite Model in der Einfachheit der Handhabung und der Kompatibilität zu bestehenden Datenbanklösungen.
Rails Validations – Grails Constraints Mir erscheint im Moment die Grails validierung zwar technisch "umständlicher" aber sicherer in der Anwendung für Web Applikationen. Theoretisch könnte man ja die Applikation umgehen und direkt die Daten über http Terminal request und SQL Injektion auslesen. Das Grails Konzept der Datenbank Constraints macht da glaube ich schon sinn.
Trotzdem super blog, ich sehe Ihn als Brainstorm Sammlung und Erfahrungspool an, denn ich bin mir sicher wir sind nicht die Einzigen welche diese zwei Frameworks evaluieren müssen.
Danke nochmals, Beste Grüsse
*Aktuelle Statistiken zum 29.01.2014*
**Grails** 10.346 Tickets 2.366 offen / 7.980 geschlossen Verhältnis: 23% zu 77% Quelle: http://jira.grails.org/issues/?jql=project%20%3D%20GRAILS
**Rails** 14.051 Tickets 741 offen / 13.310 geschlossen Verhältnis: 5% zu 95% Quelle: https://github.com/rails/rails/issues