Während meiner College-Zeit, als Student der Softwaretechnik, war Java das neue Kind auf dem Block. Zum Glück hatte ich ein paar visionäre Professoren, die darauf aus waren, C++ als etwas Vergangenes zu kennzeichnen und in die wunderbare Welt des „Einmal programmieren, überall einsetzen“ vorzudringen. Die meisten Aufgaben waren in Java, aber wir haben auch andere Technologien wie C, C++, Cobol, OCAML ausprobiert... und Javascript.
Sobald ich anfing, mit JavaScript zu arbeiten, hatte ich sofort das Gefühl, dass es mit einem Hack & Slash-Ansatz entworfen wurde, um etwas zu erledigen, und dass es nicht länger als ein paar Prototypen überleben sollte. Damals war niemand bereit, auf JavaScript zu setzen, aber wir könnten nicht falscher liegen. Zwanzig Jahre später erlaubte unsere Branche, dass JavaScript ins Backend verlagert wurde, und jetzt ist es überall.
Die Jahre nach meinem Abschluss verbrachte ich, wie von den Universitätsprofessoren vorgesehen, damit, in Java zu programmieren. Ich fand es toll, wie Sun die Sprache und Java VM entworfen hat, aber ich habe immer ihre zu komplizierte Art, das Standard Development Kit (SDK) zu entwerfen, in Frage gestellt. Es schien, als wären sie begierig darauf, jedes Muster der berühmten zu verwenden Buch geschrieben von Viererbande, und der erste Kontakt mit J2EE gab mir den Eindruck Martin Fowler bot Sun den Entwurf zu seinem noch zu veröffentlichenden Buch an Entwurfsmuster für Unternehmen, und sie haben daraus eine TODO-Liste gemacht.
Das Java-Ökosystem war so überentwickelt, dass es zur gängigen Praxis wurde, zwei Wochen in einen Projektplan einzuplanen, nur um ein leicht komplexes Produkt zu testen. Erschwerend kam hinzu, dass die gesamte Java-Community begann, überentwickelte Frameworks zu veröffentlichen, und die Welt brachte wunderbare Dinge hervor wie Federbeine und Eclipse RCP.
Du kannst dir nicht vorstellen, wie glücklich ich war, als ich das erste Mal begegnet bin Ruby on Rails, irgendwo in Version 1.x. Es war leicht vorauszusehen, dass das groß werden würde, und das war auch der Grund, warum wir beim Start auf Rails Vollgas gegeben haben Imaginary Cloud.
Ich mochte Skriptsprachen nie, da ich die Arbeit eines Compilers zur Erkennung von Tippfehlern und Datentypfehlern sehr schätze, aber ich habe so lange nach einem guten Web-Framework gesucht, dass ich das Versprechen von Ruby on Rails voll und ganz angenommen habe. Endlich gab es etwas, das es einem guten Entwicklerteam ermöglichte, schnell etwas zu erstellen, das komplexer ist als eine Reihe statischer Webseiten, die in Dreamweaver erstellt wurden.
Ruby on Rails verfolgte einen so disruptiven Ansatz, dass die Community explodierte und fast jedes neue Projekt in der Startup-Welt ihn verwendete. Einige dieser Startups wuchsen ziemlich schnell und bestätigten, dass Rails skalierbar war. Es gibt immer Leute, die sagen, dass Ruby langsam ist und Rails eine Menge Rechenressourcen benötigt, aber wenn Sie bis dahin schnell auf den Markt kommen und trotzdem dieselbe Codebasis verwenden wollten, während Sie ein hockeystickförmiges Wachstum crawlen, waren mehr Server immer eine gute Antwort. Ja, sie waren teuer, aber diese Option war immer noch billiger als das Umschreiben der gesamten Codebasis. Und man könnte die trägen Komponenten eines Systems jederzeit in einer leistungsfähigeren Sprache neu entwickeln. Ruby ließ sich immer ziemlich gut integrieren, entweder über eine Web-API oder eine gemeinsam genutzte Bibliothek.
Trotz der großen Vorteile der Verwendung von Rails in einem neuen Projekt gab es einen Bereich, in den Ruby nicht eindringen konnte, und nicht einmal Rails war ein guter Botschafter. Ich spreche von der Unternehmenswelt. Natürlich gibt es einige Ausnahmen, und man kann immer auf einige erfolgreiche Unternehmensanwendungen hinweisen, in denen Ruby entweder für neue Projekte oder als Neufassung bestehender Projekte eingeführt wurde. Aber wir stehen noch vor einer massenhaften Einführung der Technologie durch etablierte Unternehmen. Dafür gibt es mehrere Gründe, aber diese Meinung wurde nur auf der Grundlage von Bauchgefühl entwickelt und ich habe keine eindeutigen Daten, um sie zu bestätigen. Daher werde ich nicht näher auf die Gründe eingehen, warum Ruby auf dem Unternehmensmarkt nicht massiv eingesetzt wird.
Alles in allem denke ich, dass dies eine verpasste Gelegenheit war und die Softwarebranche jetzt viele praktikable Optionen für Ruby on Rails bietet. Einige werden von Startups ausgiebig genutzt (z. B. Phönix), während andere Unternehmen bis zu einem gewissen Grad durchdrungen sind, weil sie auf Technologien aufbauen, die das Corps bereits nutzt (ja Django, ich spreche von dir). Aber wenn Sie sowohl Unternehmen als auch Startups helfen möchten, können Sie mit JavaScript und Node.js nichts falsch machen. Ich sage nicht, dass Rails nicht für diesen Zweck geeignet ist.
In den meisten Fällen ist es zwar zweckmäßig, aber nicht für den Kontext geeignet. Und mit Kontext meine ich unseren Kontext — also die Möglichkeit, in einem Umfeld zu arbeiten, in dem sowohl Startups als auch Unternehmen bereit sind, ihren zukünftigen Stack darauf zu setzen. Das gilt zwar für Ersteres, aber nicht für das Neuste. Startups und Unternehmen lieben JavaScript. Und aus meiner Sicht das JavaScript-Ökosystem ist ausgereift genug, um all die guten Dinge zu liefern, die Ruby und Rails uns gebracht haben, und noch viel mehr in Bereichen, in denen Ruby und Rails nie glänzen konnten. Schauen wir uns die Ergebnisse an.
Wir haben das Node.js Ökosystem gründlich untersucht (durch Untersuchungen und Feldarbeit an einer großen Anzahl von Projekten), um die Komponenten unseres Referenzstapels zu identifizieren. Je nach Ihren Zielen könnten Sie in Betracht ziehen, dass einige dieser Ergebnisse für oder gegen Node.js sprechen. Ihr Erfahrungsschatz mag variieren, aber wir waren in der Lage, gute Lösungen für Dinge wie Datenbankmigrationen, Authentifizierungsbibliotheken, Admin-/Backoffice-Erweiterungen, automatisiertes Testen, Objektmocking usw. zu finden. Bisher konnten wir in Rails nichts tun, was in Node.js schwer zu erreichen war. Unsere Ergebnisse deuten darauf hin, dass es für fast jedes Rails-Feature oder Ruby-Gem einen Ersatz gibt.
Im Gegensatz zu Ruby dominiert JavaScript das Web-Frontend, und mit Node.js wurde es im Backend berühmt. Es ist leicht zu verstehen, warum JavaScript beliebter ist, aber ich denke auch, dass sich die Community in einer „coolen“ Phase befindet, ähnlich dem, was in den frühen Tagen mit Rails passiert ist. In der Community wird viel Land geraubt, und das treibt viele Innovationen voran. Ich vermute aber auch, dass wir in den kommenden Jahren eine gewisse Konsolidierung erleben werden, bei der Bibliotheken und Frameworks dem Untergang überlassen werden. Die Ruby on Rails-Community ist ebenfalls groß und ziemlich aktiv. Aber als Rails reifte, verlor es seinen coolen Faktor und die Community stabilisierte sich. Das bedeutet auch, dass wir mit weniger Innovation rechnen sollten.
Wir haben benutzt Ruby Motion seit den Anfängen und veröffentlichte mehrere Apps im App Store. Ich muss sagen, das war ein großartiges Framework, das von sehr klugen Leuten entwickelt wurde. Die Unterstützung für automatisiertes Testen war bemerkenswert. Das war Pre-Swift und die Bereitstellung für iOS in Ruby war viel netter als die Verwendung von Objective-C. RubyMotion brauchte jedoch sehr viel Zeit, um Android zu unterstützen, und das Versprechen „einmal bauen, überall bereitstellen“ war zu dem Zeitpunkt, als Swift herauskam, nicht möglich. Die Syntax von Swift ist viel besser als die von Objective-C, und das war ein ausreichender Grund, RubyMotion nicht mehr für neue Projekte zu verwenden. Sie können es heute noch verwenden, obwohl die Gründer ihr Unternehmen verkauft haben und es irgendwie mit der Zeit aufgehört hat. Ich vermute, dass das Framework nicht genug Anklang gefunden hat, um mit den Innovationen Schritt zu halten, die von Apple und Google auf den iOS- bzw. Android-Plattformen vorangetrieben wurden.
Und in der JavaScript-Ecke hast du Reagieren Sie nativ. Es ermöglicht Ihnen, native Apps für iOS und Android bereitzustellen. Es wurde von Facebook entwickelt und von einer großen Community stark unterstützt. Außerdem ist es kostenlos zu benutzen (RubyMotion ist es nicht).
Zurück zu dem, was ich am Anfang dieses Artikels gesagt habe, war meine Wette, dass JavaScript einen schmerzhaften Tod haben würde. Ich könnte nicht falscher liegen. Es ist bemerkenswert, wie es geschafft hat, all die Jahre relevant zu bleiben, bis zu dem Punkt, an dem jemand in der Lage war, seinen Masterplan umzusetzen und ihn ins Backend zu verschieben. Ich denke immer noch, dass es große Probleme mit der Sprache gibt, aber andererseits wurde Rails berühmt und Ruby leidet auch unter einigen Designfehlern.
Mit den neuesten Versionen von ECMA Script werden erhebliche Anstrengungen unternommen, um das Sprachdesign zu verbessern. Wir müssen jedoch immer noch auf eine große Akzeptanz der neuen Versionen warten, um sie nutzen zu können. Es besteht auch die Möglichkeit, einen Transpiler wie Babel zu verwenden, um die neuen Funktionen der neuen ECMA-Skriptstandards zu nutzen, ohne die Abwärtskompatibilität für ältere Browser zu beeinträchtigen.
Tatsache ist, dass Sie jetzt ein komplexes Web- und Mobilprojekt veröffentlichen können, ohne mehrere Sprachen verwenden zu müssen. Dies hilft, die Entwicklungskosten zu senken, und wenn Sie schon lange in der Branche sind, müssen Sie das zugeben. Das ist eine ziemlich coole Leistung.
Alles in allem ist JavaScript für uns für Zweck und Kontext geeignet. Wir haben offiziell aufgehört, Ruby on Rails für neue Projekte zu empfehlen und werden uns standardmäßig für eine JavaScript-basierte Architektur entscheiden. Nichtsdestotrotz werden wir bestehende Rails-Projekte unterstützen, da ich denke, dass die Technologie ausgereift und produktionsbereit ist und aufgrund ihrer ausgereiften und stabilen Community nicht so schnell sterben wird.
CEO von Imaginary Cloud und Mitautor des Buches Product Design Process. Ich mag Essen, Wein und Krav Maga (nicht unbedingt in dieser Reihenfolge).
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
