Raus aus dem Kaninchenbau SPA mit modernen Schienen

TL; DR: Der SPA-Trail ist dunkel und voller Schrecken. Sie können furchtlos gegen sie kämpfen ... oder einen anderen Weg wählen, der Sie zum richtigen Ort führt: moderne Schienen.



Ich erinnere mich, dass ich dachte, Rails habe sich auf das falsche Ziel konzentriert, als DHH 2012 Turbolinks ankündigte. Dann war ich überzeugt, dass die sofortige Reaktionszeit während der Benutzerinteraktion der Schlüssel zu überlegenem UX war. Aufgrund von Netzwerkverzögerungen ist diese Interaktivität nur möglich, wenn Sie die Netzwerkabhängigkeit minimieren und anstelle von Netzwerkanrufen den größten Teil des Status auf dem Client beibehalten.

Ich dachte, dass es für die Anwendungen notwendig war, an denen ich arbeitete. Mit dieser Meinung habe ich viele Ansätze und Frameworks für die Implementierung derselben Vorlage ausprobiert: Single-Page-Anwendungen (SPA). Ich glaubte, dass SPA die Zukunft ist. Ein paar Jahre später bin ich mir nicht sicher, wie die Zukunft aussehen wird, aber ich möchte definitiv eine Alternative finden.

Kaninchenbau SPA

Eine einseitige Anwendung ist eine JavaScript-Anwendung, die nach dem Herunterladen die volle Kontrolle erhält, ohne die Seite neu laden zu müssen: Rendern, Empfangen von Daten vom Server, Verarbeiten der Benutzerinteraktion, Aktualisieren des Bildschirms ...

Solche Anwendungen sehen nativer aus als herkömmliche Webseiten, bei denen die Anwendung vom Server abhängt. Wenn Sie beispielsweise Trello verwenden, können Sie feststellen, wie schnell Karten erstellt werden.

Große Verantwortung geht natürlich mit großer Kraft einher. In herkömmlichen Webanwendungen enthält Ihre Serveranwendung ein Domänenmodell und Geschäftsregeln, eine Datenzugriffstechnologie für die Arbeit mit einer Datenbank und eine Controller-Schicht, um zu steuern, wie HTML-Seiten als Antwort auf HTTP-Anforderungen zusammengestellt werden.

C SPA ist etwas komplizierter. Sie benötigen noch eine Serveranwendung, die Ihr Domänenmodell und Ihre Regeln enthält, einen Webserver, eine Datenbank und eine Art Datenzugriffstechnologie ... und eine Reihe zusätzlicher Dinge:

Für Server:

• Eine API, die die Datenanforderungen Ihres Kunden erfüllt
• Ein JSON-Serialisierungssystem zum Datenaustausch mit dem Client und ein Caching-System, das dies unterstützt

Für den neuen JavaScript-Client:

• Vorlagensystem zum Konvertieren von Daten in HTML
• Präsentation Ihres Domain-Modells und Ihrer Regeln
• Die Datenzugriffsschicht in der Clientanwendung zum Übertragen von Daten an den Server
• System zum Aktualisieren von Ansichten bei Datenänderungen
• Ein System zum Verknüpfen von URLs und Bildschirmen (Ich hoffe, Sie verwenden nicht für alles eine Adresse, es sieht nicht wie eine Webanwendung aus.)
• Ein System zum Verkleben aller Komponenten, die erforderlich sind, um Bildschirme anzuzeigen und Daten dafür zu erhalten
• Neue Vorlagen und Architektur für die Organisation von allem, wann
• System zur Fehlerbehandlung, Protokollierung, Ausnahmeverfolgung usw.
• System zum Generieren von JSON für Serveranforderungen
• Automated Testing Framework zur Unterstützung Ihres SPA
• Eine zusätzliche Reihe von Tests zum Schreiben und Unterstützen
• Ein zusätzlicher Satz von Tools zum Zusammenstellen, Packen und Bereitstellen einer neuen Anwendung

Insgesamt haben Sie mit SPA einen weiteren Antrag auf Unterstützung. Und eine neue Reihe von Problemen zu lösen. Beachten Sie, dass Sie eine Anwendung nicht durch eine andere ersetzen können. Sie benötigen weiterhin die Serveranwendung (jetzt wird JSON anstelle von HTML gerendert).

Wenn Sie noch nie mit SPA gearbeitet haben, können Sie die Schwierigkeiten, auf die Sie stoßen werden, unterschätzen. Ich weiß das, weil ich in der Vergangenheit die gleichen Fehler gemacht habe. JSON rendern? Ich kann damit umgehen. Ein reichhaltiges Domain-Objektmodell in JavaScript? Das klingt lustig. Und Sie wissen, dieses Framework wird all diese Probleme lösen. Toller Kuchen!

Falsch.

API und Datenaustausch.

Die Kommunikation zwischen Ihrer neuen Anwendung und dem Server ist ein komplexes Problem.

Es gibt zwei entgegengesetzte Kräfte:

• Sie sollten so wenig Serveranforderungen wie möglich stellen, um die Leistung zu verbessern.
• Das Konvertieren eines einzelnen Datensatzes in JSON ist einfach. Das Mischen großer Modelle verschiedener Datensätze, um die Anzahl der Abfragen zu minimieren, ist jedoch überhaupt nicht möglich. Sie müssen die Serialisierungslogik sorgfältig entwickeln, um die Anzahl der Datenbankabfragen zu optimieren und die Leistung auf dem Niveau zu halten.

Darüber hinaus müssen Sie überlegen, was und wann für jeden Bildschirm heruntergeladen werden soll. Ich meine, Sie brauchen ein Gleichgewicht zwischen Bootstrap, dem, was Sie sofort brauchen und dem, was träge geladen werden kann, und entwickeln eine API, mit der Sie dies tun können.

Einige Standards können hier helfen. JSON-API zur Standardisierung des JSON-Formats; oder GraphQL, um nur die erforderlichen Daten in einer Abfrage auszuwählen, die so komplex wie erforderlich sind. Aber keiner von ihnen wird dich retten vor:

• Die Ausarbeitung jedes Datenaustauschs
• Implementieren von Abfragen zur effizienten Auswahl von Daten auf dem Server

Und beide Aspekte bedeuten ausreichend zusätzliche Arbeit.

Startzeit

Die Leute sind es gewohnt, SPAs mit Geschwindigkeit zu verknüpfen, aber die Wahrheit ist, dass es nicht so einfach ist, sie schnell zu laden. Dafür gibt es viele Gründe:

• Eine Anwendung benötigt Daten, bevor etwas gerendert wird, und es braucht Zeit, um eine ausreichend große Menge an JavaScript zu analysieren.
• Über die anfängliche HTTP-Anforderung zum Herunterladen der Anwendung hinaus müssen Sie normalerweise eine oder mehrere Anforderungen stellen, um die zum Rendern des Bildschirms erforderlichen JSON-Daten abzurufen.
• Der Client muss JSON in HTML konvertieren, um zumindest etwas anzuzeigen. Abhängig vom Gerät und der Menge des zu konvertierenden JSON kann dies zu spürbaren Verzögerungen führen.

Dies bedeutet nicht, dass es unmöglich ist, das SPA zum schnellen Laden zu zwingen. Ich sage nur, dass es schwierig ist und Sie sich darum kümmern sollten, da es nicht mit der SPA-Architektur einhergeht.

Zum Beispiel hat Discourse, ein Ember-basiertes SPA, fantastische Ladezeiten, aber unter anderem laden sie eine große Menge von JSON-Daten als Teil des anfänglichen HTML-Codes vor, um keine zusätzlichen Anforderungen zu stellen. Und ich stelle fest, dass das Discourse-Team im guten Sinne der Geschwindigkeit verrückt ist und ihre Fähigkeiten weit über dem Durchschnitt liegen. Denken Sie darüber nach, bevor Sie dasselbe problemlos in Ihrem SPA reproduzieren können.

Eine ehrgeizige Lösung für dieses Problem ist isomorphes JavaScript: Rendern Sie Ihre Startseite auf dem Server und geben Sie sie schnell an den Client weiter, während sie im Hintergrund des SPA geladen wird und die volle Kontrolle erhält, wenn Sie bereit sind.

Dieser Ansatz erfordert das Ausführen der JavaScript-Laufzeit auf dem Server und ist auch nicht ohne technische Probleme. Entwickler sollten beispielsweise SPA-Ladeereignisse berücksichtigen, wenn sich der Ladevorgang ändert.

Ich mag die Möglichkeit, den Code in dieser Idee wiederzuverwenden, aber ich habe keine Implementierung gesehen, die es mir ermöglichen würde, in die entgegengesetzte Richtung zu gehen. Außerdem erscheint mir dieser Seitenrenderprozess sehr lustig:

- Server: Anfrage an die Server-API
- Server: Datenbankabfrage
- Server: JSON generieren
- Server: Konvertiert JSON in HTML
- Client: Erstes HTML anzeigen
- Client: SPA herunterladen
- Client: Analysieren Sie den anfänglichen HTML-Code und abonnieren Sie DOM-Ereignisse

Könnten Sie einfach die Daten aus der Datenbank anfordern, den HTML-Code generieren und mit der Arbeit beginnen?

Dies ist nicht ganz fair, weil Sie kein SPA sein werden und weil der größte Teil dieser Magie hinter dem Framework verborgen ist, aber es scheint mir immer noch falsch.

Architektur

Das Entwickeln von Anwendungen mit einer umfangreichen Benutzeroberfläche ist schwierig. Dies alles ist darauf zurückzuführen, dass dies eines der Probleme ist, die zur Entstehung eines objektorientierten Ansatzes und vieler Entwurfsmuster geführt haben.

Das Verwalten des Kundenstatus ist schwierig. Herkömmliche Websites konzentrieren sich normalerweise auf Bildschirme mit Einzelverantwortung, die beim Neustart ihren Status verlieren. In SPA ist die Anwendung dafür verantwortlich, dass alle Status- und Bildschirmaktualisierungen während der Verwendung konsistent sind und reibungslos verlaufen.

Wenn Sie in der Praxis damit begonnen haben, JavaScript in kleinen Teilen zu schreiben, um die Interaktion zu verbessern, müssen Sie in SPA Tonnen zusätzlichen JavaScript-Code schreiben. Hier sollten Sie sicherstellen, dass Sie alles richtig machen.

Es gibt so viele verschiedene Architekturen wie SPA-Frameworks:

• Die meisten Frameworks unterscheiden sich von der herkömmlichen MVC-Vorlage. Ember war ursprünglich von Cocoa MVC inspiriert, hat aber in den letzten Versionen sein Programmiermodell stark verändert.
• Es besteht die Tendenz, dass Entwickler Komponenten der herkömmlichen Trennung von Controller und Präsentation vorziehen (einige Frameworks wie Ember und Angular haben in neueren Versionen diesen Ansatz gewählt). Alle Frameworks implementieren eine Art Einweg-Datenbindung. Eine doppelseitige Bindung wird aufgrund von Nebenwirkungen, die dazu beitragen können, nicht empfohlen.
• Die meisten Frameworks enthalten ein Routing-System, mit dem Sie URLs und Bildschirme zuordnen und festlegen können, wie Komponenten für das Rendern instanziiert werden sollen. Dies ist ein einzigartiger Webansatz, der auf herkömmlichen Desktop-Schnittstellen nicht vorhanden ist.
• Die meisten Frameworks trennen HTML-Vorlagen vom JavaScript-Code, aber React mischt HTML-Generierung und JavaScript und ist aufgrund seiner weit verbreiteten Verwendung recht erfolgreich. Es gibt auch einen Hype um das Einbetten von CSS in JavaScript. Facebook mit seiner Flux-Architektur hat die Branche stark beeinflusst, und Container wie Redux, Vuex usw. sind stark davon beeinflusst.

Von allen Frameworks, die ich gesehen habe, ist Ember mein Favorit. Ich verehre seine Beständigkeit und die Tatsache, dass er ziemlich stur ist. Ich mag auch sein Programmiermodell in neueren Versionen, das traditionelle MVC, Komponenten und Routing kombiniert.

Andererseits bin ich stark gegen das Flux / Redux-Lager. Ich habe so viele kluge Leute gesehen, die sie benutzt haben, dass ich mich bemüht habe, sie zu studieren und zu verstehen, und nicht ein einziges Mal. Ich kann nicht anders, als frustriert den Kopf zu schütteln, wenn ich den Code sehe. Ich sehe mich beim Schreiben eines solchen Codes nicht glücklich.

Schließlich kann ich die Mischung aus HTML und CSS in Komponenten voller JavaScript-Logik nicht ertragen. Ich verstehe, welches Problem dies löst, aber die Probleme, die dieser Ansatz mit sich bringt, machen es nicht wert.

Lassen wir die persönlichen Einstellungen. Unter dem Strich haben Sie bei der Auswahl des SPA-Pfads ein sehr schwieriges Problem: die Architektur Ihrer neuen Anwendung korrekt zu erstellen. Und die Branche ist weit davon entfernt, sich darauf zu einigen. Jedes Jahr erscheinen neue Frameworks, Vorlagen und Versionen von Frameworks, wodurch sich das Programmiermodell geringfügig ändert. Sie müssen eine Menge Code schreiben und verwalten, der auf Ihrer Architektur basiert. Denken Sie also richtig darüber nach.

Codeduplizierung

Wenn Sie mit SPA arbeiten, werden Sie wahrscheinlich auf Codeduplizierungen stoßen.

Für Ihre SPA-Logik möchten Sie ein umfangreiches Modell von Objekten erstellen, die Ihren Domänenbereich und Ihre Geschäftslogik darstellen. Und für die Serverlogik benötigen Sie immer noch dasselbe. Und es ist eine Frage der Zeit, bis Sie mit dem Kopieren des Codes beginnen.

Angenommen, Sie arbeiten mit Rechnungen. Sie haben wahrscheinlich eine Rechnungsklasse in JavaScript, die eine Gesamtmethode enthält, die den Preis aller Elemente zusammenfasst, damit Sie den Wert rendern können. Auf dem Server benötigen Sie außerdem die Rechnungsklasse mit der Gesamtmethode, um diese Kosten zu berechnen und per E-Mail zu senden. Siehst du? Die Rechnungsclient- und Serverklassen implementieren dieselbe Logik. Codeduplizierung.

Wie oben erwähnt, könnte isomorphes JavaScript dieses Problem mindern und die Wiederverwendung von Code erleichtern. Und ich sage zu Level, weil die Korrespondenz zwischen dem Client und dem Server nicht immer 1 zu 1 ist. Sie sollten sicherstellen, dass Code niemals den Server verlässt. Eine große Menge an Code ist nur für den Client sinnvoll. Außerdem sind einige Aspekte einfach unterschiedlich (z. B. kann das Serverelement Daten in der Datenbank speichern und der Client kann die Remote-API verwenden). Die Wiederverwendung von Code, auch wenn dies möglich ist, ist ein komplexes Problem.

Sie können darauf wetten, dass Sie kein umfangreiches Modell in Ihrem SPA benötigen und stattdessen direkt mit JSON / JavaScript-Objekten arbeiten und die Logik auf die Komponenten der Benutzeroberfläche verteilen. Jetzt haben Sie die gleiche Codeduplizierung mit Ihrem UI-Code gemischt, viel Glück damit.

Das Gleiche passiert, wenn Sie Vorlagen zum Rendern von HTML zwischen dem Server und dem Client wünschen. Wie wäre es beispielsweise mit der Generierung von Seiten auf dem Server für Suchmaschinen für SEO? Sie müssen Ihre Vorlagen auf dem Server neu schreiben und sicherstellen, dass sie mit dem Client synchronisiert sind. Wieder Vervielfältigung des Codes.

Die Notwendigkeit, die Logik der Muster auf dem Server und dem Client zu reproduzieren, ist meiner Erfahrung nach die Ursache für das wachsende Unglück der Programmierer. Dies einmal zu tun ist normal. Wenn Sie dies zum 20. Mal tun, werden Sie Ihren Kopf umklammern. Nachdem Sie dies zum 50. Mal getan haben, werden Sie darüber nachdenken, ob all diese SPA-Teile benötigt werden.

Zerbrechlichkeit

Nach meiner Erfahrung ist die Entwicklung guter SPAs eine viel kompliziertere Aufgabe als das Schreiben von Webanwendungen mit Servergenerierung.

Erstens, egal wie vorsichtig Sie sind, egal wie viele Tests Sie schreiben. Je mehr Code Sie schreiben, desto mehr Fehler werden Sie haben. Und SPA repräsentiert (sorry, wenn ich hart drücke) einen riesigen Stapel Code zum Schreiben und Unterstützen.

Zweitens ist die Entwicklung einer umfangreichen Benutzeroberfläche, wie oben erwähnt, kompliziert und führt zu komplexen Systemen, die aus vielen miteinander interagierenden Elementen bestehen. Je komplexer das von Ihnen erstellte System ist, desto mehr Fehler treten auf. Und im Vergleich zu herkömmlichen Webanwendungen mit MVC ist die SPA-Komplexität einfach verrückt.

Um beispielsweise die Konsistenz auf dem Server zu gewährleisten, können Sie Einschränkungen in der Datenbank, der Modellvalidierung und den Transaktionen verwenden. Wenn etwas schief geht, antworten Sie mit einer Fehlermeldung. Im Client ist alles etwas komplizierter. So viel kann schief gehen, weil zu viel passiert. Es kann sein, dass ein Datensatz erfolgreich gespeichert wurde und ein anderer Datensatz nicht. Vielleicht sind Sie mitten in einer Operation offline gegangen. Sie müssen sicherstellen, dass die Benutzeroberfläche konsistent bleibt und die Anwendung nach einem Fehler wiederhergestellt wird. All dies ist natürlich nur viel komplizierter möglich.

Organisatorische Herausforderungen

Es klingt albern, aber um ein SPA zu entwickeln, benötigen Sie Entwickler, die wissen, was damit zu tun ist. Gleichzeitig sollten Sie die Komplexität von SPA nicht unterschätzen. Sie sollten nicht glauben, dass ein erfahrener Webentwickler mit der richtigen Motivation und dem richtigen Verständnis ein großartiges SPA von Grund auf neu schreiben kann. Sie benötigen die richtigen Fähigkeiten und Erfahrungen oder erwarten wichtige Fehler. Ich weiß das, weil es genau mein Fall ist.

Dies ist vielleicht eine wichtigere Herausforderung für Ihr Unternehmen als Sie denken. Der SPA-Ansatz ermutigt hochspezialisierte Teams anstelle von Teams von Generalisten:

• SPA-Frameworks sind komplexe Softwareteile, für deren Produktivität unzählige Stunden Erfahrung erforderlich sind. Nur die Personen in Ihrem Unternehmen, die diese Stunden mit dem Code verbringen, können diese Anwendungen unterstützen.
• SPA-Frameworks erfordern durchdachte und produktive APIs. Um diese Anforderungen zu erfüllen, sind ganz andere Fähigkeiten erforderlich als für die Arbeit mit SPA.

Es besteht die Möglichkeit, dass Sie mit Personen zusammen sind, die nicht mit SPA arbeiten können und die nicht auf der Serverseite arbeiten können, einfach weil sie nicht wissen, wie.

Diese Spezialisierung ist ideal für Facebook oder Google und deren Teams, die aus mehreren Schichten von Ingenieurtruppen bestehen. Aber wird es gut für Ihr 6-köpfiges Team sein?

Moderne Schienen

Es gibt drei Dinge in modernen Rails, die Ihre Meinung über die Entwicklung moderner Webanwendungen ändern können:

• Einer von ihnen ist Turbolinks und dies ist eine Gehirnexplosion
• Der andere ist ein alter Freund, der heute übersehen wird: SJR-Antworten und einfache AJAX-Anfragen zum Rendern
• und der letzte wurde kürzlich hinzugefügt: Stimulus

Es ist schwer zu verstehen, was es heißt, einen Ansatz anzuwenden, ohne damit zu spielen. Daher werde ich in den folgenden Abschnitten einige Verweise auf Basecamp machen. Ich habe nichts mit Basecamp zu tun, außer als glücklicher Benutzer. Dieser Artikel ist nur ein gutes Live-Beispiel für moderne Rails, das Sie kostenlos ausprobieren können.

Turbolinks

Die Idee hinter Turbolinks ist einfach: Beschleunigen Sie Ihre Anwendung, indem Sie das Neuladen von Seiten vollständig durch AJAX-Anforderungen ersetzen, die das `` -Element ersetzen. Die innere Hexerei, die diese Arbeit macht, ist verborgen. Als Entwickler können Sie sich auf die traditionelle serverseitige Programmierung konzentrieren.

Turbolinks ist von pjax inspiriert und wurde mehrfach überarbeitet.

Früher habe ich mir Sorgen um die Leistung gemacht. Ich habe mich geirrt Die Beschleunigung ist enorm. Was mich überzeugt hat, war, wie ich es im Projekt verwendet habe, aber Sie können einfach die Testversion in Basecamp ausprobieren und damit spielen. Versuchen Sie, ein Projekt mit einigen Elementen zu erstellen, und navigieren Sie dann durch diese, indem Sie auf Abschnitte klicken. Dies gibt Ihnen eine gute Vorstellung davon, wie Turbolinks aussehen.

Ich denke nicht, dass Turbolinks mit seiner Neuheit (pjax - 8 Jahre) einfach unglaublich ist. Oder seine technische Raffinesse. Es überrascht mich, wie eine einfache Idee Ihre Produktivität im Vergleich zur Alternative zu SPA um eine Größenordnung steigern kann.

Lassen Sie mich einige der Probleme hervorheben, die dadurch behoben werden:

• Datenaustausch. Du hast es nicht. Sie müssen JSON nicht serialisieren, APIs erstellen oder über Datenanforderungen nachdenken, die die Kundenanforderungen hinsichtlich der Leistung erfüllen.
• Anfangslast. Im Gegensatz zu SPA stimuliert dieser Ansatz schnelle Ladezeiten (vom Design her). Zum Rendern des Bildschirms können Sie die benötigten Daten direkt aus der Datenbank abrufen. HTML — .
• : JavaScript-. , SPA.

Die MVC auf dem Server ist in der von Rails und vielen anderen Frameworks verwendeten Version viel einfacher als alle für die umfangreiche GUI-Architektur verwendeten Vorlagen: Erhalten Sie eine Anfrage, arbeiten Sie mit der Datenbank, um sie zu erfüllen, und zeigen Sie die HTML-Seite als Antwort an.

Schließlich hat die Einschränkung, die immer ersetzt wird, einen wunderbaren Effekt: Sie können sich auf das anfängliche Rendern von Seiten konzentrieren, anstatt bestimmte Abschnitte zu aktualisieren (oder einige Bedingungen in der SPA-Welt zu aktualisieren). Im Allgemeinen macht er einfach alles.

• Codeduplizierung. Es gibt nur eine Ansicht Ihrer Anwendung, die sich auf dem Server befindet. Ihr Domain-Modell, seine Regeln, Anwendungsbildschirme usw. Es ist nicht erforderlich, Konzepte im Client zu duplizieren.
• . SPA, JavaScript , . , , , .

Beachten Sie, dass ich nicht über Namensprobleme spreche, sondern über deren Behebung. Zum Beispiel sind GraphQL- oder SPA-Rehydratisierung super intelligente Lösungen für sehr komplexe Probleme. Aber was ist, wenn Sie, anstatt zu versuchen, eine Lösung zu finden, sich in eine Situation versetzen, in der diese Probleme nicht existieren? Dies ist eine Änderung der Herangehensweise an das Problem. Und ich habe Jahre gebraucht, um die Fähigkeit dieses Ansatzes zur Lösung von Problemen voll zu würdigen.

Natürlich ist Turbolinks keine problemlose Silberkugel. Das größte Problem ist, dass vorhandener JavaScript-Code beschädigt werden kann:

• Turbolinks werden mit dem benutzerdefinierten Ereignis "Seitenladen" ausgeliefert, und vorhandene Plugins, die auf regulären Seitenladevorgängen beruhen, funktionieren nicht. Heutzutage gibt es bessere Möglichkeiten, dem DOM Verhalten hinzuzufügen, aber ältere Widgets funktionieren nicht, wenn sie nicht angepasst werden.
• JavaScript-Code, der das DOM ändert, muss idempotent sein, da er mehrmals ausgeführt werden kann. Dies macht wiederum viele vorhandene JavaScript ungültig.
• Die Geschwindigkeit ist ausgezeichnet, aber nicht ganz so wie in SPA, wo einige Interaktionen ohne Laden des Servers verarbeitet werden können. Ich werde später mehr über Kompromisse sprechen.

AJAX-Rendering und SJR-Antworten

Erinnern Sie sich, als das Rendern von HTML über Ajax vor 15 Jahren im Trend lag? Weißt du was? Dies ist immer noch ein großartiges Werkzeug in Ihrem Arsenal:

• HTML DOM, ( 100 ).
• HTML , .

Sie können sehen, wie sich dieser Ansatz in Basecamp anfühlt, indem Sie Ihr Profilmenü öffnen, indem Sie auf die Schaltfläche oben rechts klicken:



Wird sofort geöffnet . Auf der Entwicklungsseite müssen Sie sich nicht um die JSON-Serialisierung und die Clientseite kümmern. Sie können dieses Fragment einfach auf dem Server anzeigen und dabei alle Funktionen von Rails nutzen.

Ein ähnliches Tool, das Rails im Laufe der Jahre integriert hat, sind serverseitige JavaScript-Antworten (SJR). Mit ihnen können Sie auf Ajax-Anfragen (normalerweise Formulareingaben) mit JavaScript antworten, das vom Client ausgeführt wird. Es bietet die gleichen Vorteile wie das AJAX-Rendering von HTML-Snippets: Es läuft sehr schnell, Sie können den Code auf der Serverseite wiederverwenden und Sie können direkt auf die Datenbank zugreifen, um eine Antwort zu erstellen.

Sie können sehen, wie dies geschieht, wenn Sie in Basecamp gehen und versuchen, eine neue Aufgabe zu erstellen. Nachdem Sie auf "Aufgabe hinzufügen" geklickt haben, speichert der Server die Aufgabe und antwortet mit einem JavaScript-Fragment, das dem DOM eine neue Aufgabe hinzufügt.

Ich denke, viele Entwickler betrachten AJAX-Rendering und SJR-Antworten heute mit Verachtung. Ich erinnere mich auch daran. Sie sind ein Werkzeug und können als solches missbraucht werden. Bei richtiger Anwendung ist dies jedoch eine hervorragende Lösung. Sie können großartige UX und Interaktivität zu einem sehr niedrigen Preis anbieten. Leider sind sie wie Turbolinks schwer zu bewerten, wenn Sie noch nicht gegen SPA gekämpft haben.

Reiz

Stimulus ist ein JavaScript-Framework, das vor einigen Monaten veröffentlicht wurde. Rendering oder JavaScript-basierte Statusverwaltung sind nicht wichtig. Stattdessen ist es nur eine schöne, moderne Art, JavaScript zu organisieren, mit dem Sie HTML hinzufügen:

• Es verwendet MutationObserver, um das Verhalten an das DOM zu binden, was bedeutet, dass es egal ist, wie der HTML-Code auf der Seite angezeigt wird. Natürlich funktioniert dies hervorragend mit Turbolinks.
• Sie sparen eine Menge Boilerplate-Code zum Anhängen des Verhaltens an das DOM, zum Anhängen von Ereignishandlern an Ereignisse und zum Platzieren von Elementen im angegebenen Container.
• Ziel ist es, Ihren HTML-Code lesbar und verständlich zu machen. Dies ist hilfreich, wenn Sie jemals auf das Problem gestoßen sind, herauszufinden, welcher Teil von JavaScript auf dieses verdammte Element einwirkt.
• Es fördert die Beharrlichkeit im DOM. Dies bedeutet wiederum, dass es ihm egal ist, wie der HTML-Code generiert wird, was für viele Szenarien, einschließlich Turbolinks, geeignet ist.

Wenn Sie den Rails-Pfad akzeptieren, konzentriert sich Ihr JavaScript darauf, den serverseitigen HTML-Code zu ändern und die Interaktion zu verbessern (mit etwas JavaScript). Stimulus wurde entwickelt, um solchen Code zu organisieren. Dies ist kein SPA-System und gibt nicht vor, eines zu sein.

Ich habe Stimulus in mehreren Projekten verwendet und es gefällt mir sehr gut. Es eliminiert eine Menge Boilerplate-Code, basiert auf den neuesten Webstandards und liest sich sehr schön. Und etwas, das ich besonders liebe: Jetzt ist dies die Standardmethode, um etwas zu tun, das in jeder Anwendung noch gelöst werden musste.

Kompromissspiel

Turbolinks werden normalerweise als "Nutzen Sie alle Vorteile von SPA ohne Unannehmlichkeiten" verkauft. Ich denke nicht, dass dies völlig wahr ist:

• Anwendungen, die mit modernen Rails erstellt wurden, sehen schnell aus, aber SPA reagiert immer noch schneller auf Interaktionen, die vom Server unabhängig sind.
• Es gibt Szenarien, in denen SPA sinnvoller ist. Wenn Sie ein hohes Maß an Interaktivität bieten möchten, müssen Sie eine große Anzahl von Status verwalten, komplexe Logik auf der Clientseite ausführen usw. Das SPA-Framework erleichtert Ihnen das Leben.

Jetzt ist Entwicklung ein Kompromissspiel. Und in diesem Spiel:

• Mit Modern Rails können Sie Anwendungen erstellen, die schnell genug sind und gut aussehen.
• Mit Rails können Sie für eine Vielzahl von Anwendungen dieselben Funktionen mit weniger Code und weniger Komplexität implementieren.

Ich glaube, dass Sie mit Rails mit 10% Aufwand 90% des Angebots von SPA erhalten können. In Bezug auf die Leistung tötet Rails SPA. Was UX betrifft, denke ich, dass viele Entwickler den gleichen Fehler wie ich machen, vorausgesetzt, SPA UX ist unübertroffen. Es ist nicht so. Wie oben erläutert, wissen Sie besser, was Sie beim Erstellen Ihres SPA tun, oder UX wird tatsächlich schlechter.

Fazit

Ich beobachte, wie Unternehmen SPA-Frameworks massiv akzeptieren, und sehe unzählige Artikel darüber, wie man ausgefallene Dinge im SPA-Stil macht. Ich denke, es gibt viele „Verwendungen des falschen Tools für den Job“, da ich fest davon überzeugt bin, dass die Arten von Anwendungen, die die Verwendung von SPA rechtfertigen, begrenzt sind.

Und ich sage, sie rechtfertigen es, weil SPAs komplex sind. Ich hoffe auf jeden Fall, dass ich Sie davon überzeugt habe. Ich sage nicht, dass es unmöglich ist, großartige SPA-Anwendungen zu erstellen, oder dass moderne Rails-Anwendungen per Definition großartig sind. Nur ein Ansatz ist sehr kompliziert und der andere viel einfacher.

Bei der Vorbereitung dieses Artikels bin ich auf diesen Tweet gestoßen:



Es brachte mich zum Lachen, weil ich die ersten Optionen wählen würde, wenn die Alternative nicht gerechtfertigt wäre. Er ist auch ein Vertreter der Denkweise von Entwicklern, die Komplexität lieben und davon leben, bis hin zu dem Gedanken, dass andere Menschen mit anderen Kriterien verrückt sind.

Nach vielen Jahren wurde mir klar, dass Komplexität oft eine Wahl ist. In der Programmierwelt ist es jedoch überraschend schwierig, die Einfachheit zu wählen. Wir schätzen Komplexität so sehr, dass wir durch das Akzeptieren von Einfachheit oft anders denken, was per Definition schwierig ist.

Denken Sie daran, dass Sie Ärger loswerden können. Wenn Sie den SPA-Pfad wählen, stellen Sie sicher, dass er gerechtfertigt ist und Sie die Probleme verstehen. Wenn Sie sich nicht sicher sind, experimentieren Sie mit verschiedenen Ansätzen und überzeugen Sie sich selbst. Vielleicht haben Facebook oder Google in ihrer Größenordnung nicht den Luxus, solche Entscheidungen zu treffen, aber Sie können es wahrscheinlich.

Und wenn Sie ein Rails-Entwickler sind, der Rails vor vielen Jahren verlassen hat, empfehle ich Ihnen, dorthin zurückzukehren. Ich denke, Sie werden begeistert sein.