Ich äußere mich ziemlich oft zu den Problemen, die clientseitiges JavaScript aus Leistungsperspektive verursacht. Wir liefern immer mehr JavaScript an die Geräte unserer Nutzer und das Ergebnis sind zunehmend anfällige und ressourcenintensive Erlebnisse. Es ist... nicht großartig.
Aber das bedeutet nicht, dass ich JavaScript nicht mag. Ganz im Gegenteil, ich arbeite gerne mit JavaScript. Ich wünschte nur, wir wären ein wenig wählerischer, *wo* wir es einsetzen.
Was mich begeistert, ist, wenn JavaScript in Teile des technischen Stacks vordringt, wo es vorher nicht zu finden war. Sowohl die serverseitige Programmierung als auch der Build-Tool-Prozess waren für Frontend-Entwickler nicht gerade tabu, aber bevor Node.js und Tools wie Grunt, Gulp, webpack und Parcel aufkamen, waren dafür andere Sprachen erforderlich. Es gibt viele Verbesserungen (Asset-Optimierungen, Testausführung, serverseitige Anpassungen, die für eine verbesserte Frontend-Performance notwendig sind usw.), die serverseitige Sprachen erforderten, was bedeutete, dass die meisten Frontend-Entwickler dorthin tendenziell nicht gingen. Da diese Tools jetzt von JavaScript angetrieben werden, ist es weitaus wahrscheinlicher, dass Frontend-Entwickler diese Änderungen selbst vornehmen können.
Immer wenn wir einen Teil des Technologie-Stacks nehmen und ihn einem breiteren Publikum zugänglich machen, werden wir eine Explosion von Kreativität und Innovation erleben. Genau das ist mit Build-Prozessen und Bundlern passiert. Es gab eine Innovationswelle, nicht zuletzt dank der Erweiterung der Reichweite von Frontend-Entwicklern.
Deshalb bin ich wirklich begeistert von Edge-Computing-Lösungen.
Die Nutzung eines CDNs ist eines der wertvollsten Dinge, die Sie tun können, um die Leistung zu verbessern und Ihre Reichweite zu erweitern. Aber die Konfiguration dieses CDNs und die Maximierung seines Nutzens war für die meisten Frontend-Teams unerreichbar.
Das ändert sich gerade.
Cloudflare hat Cloudflare Workers, angetrieben von JavaScript. Akamai hat EdgeWorkers, angetrieben von JavaScript. Amazon hat Lambda@Edge, angetrieben von JavaScript. Fastly hat gerade Compute@Edge angekündigt, das von WebAssembly angetrieben wird. Sie können derzeit kein JavaScript für Compute@Edge schreiben (Sie können TypeScript schreiben, wenn das Ihr Ding ist), aber ich vermute, es ist nur eine Frage der Zeit, bis sich das ändert.
Jedes dieser Tools bietet eine programmierbare Schicht zwischen Ihrem CDN und den Besuchern Ihrer Website, wodurch Sie Ihre Inhalte am Edge transformieren können, bevor sie überhaupt bei Ihren Nutzern ankommen. Entscheidend ist, dass all diese Tools die Durchführung dieser Dinge für Frontend-Entwickler viel zugänglicher machen.
Anstatt beispielsweise den Client die gesamte Arbeit für A/B-Tests erledigen zu lassen, können Sie eines dieser Tools verwenden, um die gesamte Logik stattdessen im CDN zu handhaben. Dies trägt dazu bei, clientseitige A/B-Tests (eine Ärgernis für jeden leistungsorientierten Ingenieur aller Zeiten) zu einer Sache der Vergangenheit zu machen. Optimizely nutzt diese Technologie bereits, um genau das für seine eigene A/B-Testlösung zu tun.
Nutzen Sie eine Drittanbieter-Ressource? Edge Computing macht es viel einfacher, diese Anfragen über Ihr eigenes CDN zu leiten, was Ihnen die zusätzlichen Verbindungskosten erspart und dazu beiträgt, Single Points of Failure zu eliminieren.
Benutzerdefinierte Fehlermeldungen? Klar. Benutzerauthentifizierung? Aber sicher. Personalisierung? Ja. Es gab sogar einige ziemlich kreative technische SEO-Arbeiten, die dank Edge Computing stattfanden.
Einige dieser Arbeiten waren früher machbar, aber oft erforderte es das Durchsuchen archaischer Benutzeroberflächen, um die richtige Einstellung zu finden, oder die Verwendung völlig anderer Sprachen und Tools wie ESI oder Varnish, die außerhalb dieses kleinen Bereichs, in dem sie operieren, praktisch nicht existieren.
Diese Dinge für jeden mit etwas JavaScript-Kenntnis zugänglich zu machen, hat das Potenzial, als eine Art Überdruckventil zu dienen, wodurch es für Leute einfacher wird, einige dieser schweren Arbeiten von Client-Geräten weg und zurück zu einem Teil des Tech-Stacks zu verlagern, der viel vorhersehbarer und zuverlässiger ist. Wie Node.js und JavaScript-gesteuerte Build-Tools erweitern sie die Reichweite von Frontend-Entwicklern weiter.
Ich kann es kaum erwarten, all das Experimentieren zu sehen, das stattfinden wird.