Ruby on Rails erscheint bald in der Major-Version 6. In den Anfangsjahren wurde Rails bekannt, weil man ohne viel Konfigurationsaufwand mit der Entwicklung beginnen konnte und fast keine Zeit in das Bootstrapping investieren brauchte. Und auch nach fast 15 Jahren gibt es zu dem Webframework keine wirkliche Konkurrenz, mit der man ähnlich effektiv neue Features umsetzen könnte. Doch woran liegt das?
Viel Aufmerksamkeit erhielt Ruby on Rails zu Beginn für das Video „How to build a blog engine in 15 minutes with Ruby on Rails“. Nach mittlerweile 13 Jahren gilt das immer noch als beeindruckend, wie schnell ein rudimentärer Blog implementiert werden kann.
Wenn man die Entwicklung von Rails im Vergleich zu anderen Webframeworks verfolgt, stellt man fest, dass auch in Ruby on Rails zahlreiche neue Features hinzugekommen sind, aber die radikale Einfachheit, mit der man in der Entwicklung konfrontiert ist, geblieben ist. Hier haben sich andere Webframeworks, egal auf welcher Programmiersprache sie aufbauen, oft in die falsche Richtung entwickelt und auf Kosten neuer Features die Komplexität durch viel Konfigurationsaufwand erhöht. Dadurch geht die Einfachheit verloren, durch die man schnell in die Entwicklung starten kann.
Doch nicht nur beim initialen Bootstrapping einer neuen Anwendung, die zu Beginn vielleicht nur Prototypen-Charakter hat, ist meiner Meinung nach Rails weiterhin ungeschlagen schnell. Auch in der weiteren Feature-Entwicklung von produktiv betriebenen Applikationen bietet Rails durch das konsequente Verfolgen des Paradigmas Convention over Configuration, die Flexibilität neue Funktionen effektiv zu entwickeln.
Schnelle Feature-Entwicklung heißt nicht, dass das Resultat nur Prototypen-Charakter hat - das beweist Ruby on Rails immer wieder. Werfen wir beispielsweise einen Blick auf den Reisekosten-Gorilla, das Tool um einfach Reisekostenabrechnungen durchführen zu können. Für uns vier Gründer war von Anfang an klar, dass als Grundlage nur Ruby on Rails in Frage kam. Jeder von uns hat in unseren Jahren als Consultant viele verschiedene Frameworks genutzt, aber an die Effizienz von Rails kam zum damaligen Zeitpunkt kein anderes Framework heran.
Und auch heute, mehrere Jahre nach dem Start des Projekts, sind wir immer noch der Überzeugung, dass Ruby on Rails das überlegene Framework für eine solche Webanwendung ist.
Vor kurzem haben wir beispielsweise ein neues Feature eingebaut, das es ermöglicht Bewirtungsbelege aus getätigten Ausgaben heraus zu erfassen. Insgesamt dauerte es nicht mehr als zwei Tage, das Feature zu entwickeln, zu testen, zu reviewen und ins Produktivsystem zu deployen. Und dass es ganze zwei Tage dauerte, lag nicht an Ruby on Rails, sondern hauptsächlich an der Integration der Unterschriftsfunktionalität, die deutlich komplexer war, als zunächst angenommen. Würde man diesen Teil ausklammern, wäre die Entwicklung noch deutlich schneller vonstatten gegangen.
Das Anlegen der benötigten neuen Felder in der Datenbank ist mit einer einfachen Migration schnell erledigt. Anschließend können die Felder entsprechend dem Styling der Anwendung im Formular eingebaut und gefüllt werden. Das Anzeigen der Felder in den Details einer Ausgabe ist auch alltägliche Arbeit für einen Entwickler und entsprechend flink erledigt.
Das Komplizierte des Features war für uns, neben der schon erwähnten Integration der Unterschriftsfunktionalität ins Formular, noch die Generierung des Bewirtungsbelegs als eigenständiges PDF-Dokument. Doch für das gesamte Ruby-Ökosystem gibt es glücklicherweise unzählige gut gepflegte Libraries, für große und kleine Probleme die irgendwer schon einmal gelöst hat. Das ist meiner Meinung nach einer der großen Vorteile im Ruby Umfeld. Zwar gibt es auch für andere Webframeworks oder Sprachen entsprechende Libraries, doch die Masse und insbesondere Qualität und Einfachheit der Ruby-Libraries ist meiner Meinung nach unübertroffen.
Da der Reisekosten-Gorilla schon an anderer Stelle PDF-Dateien generiert, hatten wir uns mit der Generierung von PDF-Dokumenten schon einmal auseinandergesetzt und eine entsprechende Library eingebunden. Wir benutzen dafür das Ruby Gem prawn. So hatten wir auch schon ein fertiges PDF-Styling, dass wir nutzen konnten, um ein eigenes Dokument für den Bewirtungsbeleg zu erstellen
Hier fiel für uns dann allerdings ein wenig Refactoring-Arbeit an, um die PDF-Generierung generischer als bisher zu gestalten. Anschließend mussten wir nur noch die gewünschten Daten übergeben, in einer Tabelle darstellen und die als SVG gespeicherte Unterschrift auf das PDF drucken. Dann noch die vorhandenen Quittungen an das Bewirtungsbeleg-PDF anhängen und fertig war die Generierung eines selbstausgefüllten Bewirtungsbelegs als eigenes Dokument.
Das Einzige was noch fehlte, war die Verlinkung der PDF-Datei aus der Ausgabe heraus und die Erstellung des PDF in einer neuen Methode im Controller. Aber auch das ist mit Rails in wenigen Zeilen Code erledigt.
Somit konnten wir ein komplett neues Feature in weniger als zweit Tagen umsetzen, das der bestehenden Anwendung einen erheblichen Mehrwert bietet. Das Feedback der Nutzer dazu war eindeutig.
Mit Ruby on Rails lässt sich also schnell qualitativ guter Code schreiben und das mit Ergebnissen, die auch vom UI und UX so hochwertig sind, dass sie die Nutzer und Entwickler gleichermaßen überzeugen. Mehr geht nicht.
Das liegt zum Teil auch daran, dass insbesondere die Templating-Engine bei der Frontend-Entwicklung nicht so stark im Weg steht wie beispielsweise Thymeleaf im Java-Umfeld. Und auch was die Aspekte Security oder Skalierung angeht, ist Rails seit Bestehen Trendsetter. Andere Frameworks ziehen in den meisten Gebieten nur nach - und das oft erst nach Jahren. Ein schönes Beispiel sind auch die Stateless Cookie-based Sessions. Das ist auch heute noch in der Framework-Landschaft nicht alltäglich.
Meiner Meinung nach ist Rails also immer noch das Framework der Wahl und das Nonplusultra, wenn man effektiv Webanwendungen entwickeln will.