Konformität im JavaScript-Framework-System
In unserem einführenden Blogpost ging es darum, wie wir uns beim Erstellen und Verwenden von Frameworks und Tools für die Entwicklung und Verwaltung umfangreicher Webanwendungen wie die Google Suche, Maps und Fotos usw. beschäftigt haben. Wir haben verhindert, dass Entwickler Code schreiben, der sich negativ auf die Nutzererfahrung auswirken kann. So haben wir bewiesen, dass Frameworks eine wichtige Rolle bei der Veränderung von Ergebnissen in Bezug auf Leistung und Anwendungsqualität spielen können.
Intern haben wir bei Google den Begriff Konformität verwendet, um diese Methode zu beschreiben. In diesem Artikel wird beschrieben, wie wir dieses Konzept als Open-Source-Software für das JavaScript-Framework-Ökosystem bereitstellen möchten.
Was ist Konformität?
Bei Google war Konformität eine Weiterentwicklung. Die Teams verließen sich auf eine kleine Gruppe von erfahrenen Pflegern, die umfangreiche Codeüberprüfungen durchführten und Probleme meldeten, die weit über Fehler bei der App-Qualität und -wartung hinausgingen. Um dies auf wachsende Teams von App-Entwicklern zu skalieren, wurde ein Konformitätssystem entwickelt, um Best Practices automatisiert und durchsetzbar zu codieren. Dadurch wurden unabhängig von der Anzahl der Code-Mitwirkenden konstant hohe Anforderungen an die Anwendungsqualität und die Verwaltbarkeit der Codebasis sichergestellt.
Konformität ist ein System, das dafür sorgt, dass Entwickler auf dem gut beleuchteten Pfad bleiben; es schafft Vertrauen und sorgt für vorhersehbare Ergebnisse. Dies macht Teams produktiv und wird für die Größe von entscheidender Bedeutung, da Teams wachsen und immer mehr Funktionen gleichzeitig entwickelt werden. Sie ermöglicht es Entwicklern, sich auf die Entwicklung von Produktfunktionen zu konzentrieren, indem sie von den Details und der sich verändernden Landschaft in verschiedenen Bereichen wie Leistung, Barrierefreiheit, Sicherheit usw. befreit werden. Jeder kann die Konformität jederzeit deaktivieren. Die Anwendung sollte in dem Umfang angepasst werden können, in dem die Teams die Möglichkeit haben, ihre Entscheidung durchzusetzen.
Die Konformität beruht auf starken Standardwerten und der Bereitstellung von umsetzbaren Regeln, die beim Authoring-Zeitpunkt durchgesetzt werden können. Sie sind in die folgenden drei Prinzipien unterteilt.
1. Starke Standardeinstellungen
Ein grundlegender Aspekt der Konformität besteht darin, sicherzustellen, dass die von den Entwicklern verwendeten Tools starke Standardeinstellungen haben. Das bedeutet, dass Lösungen nicht nur in Frameworks verankert sind, sondern dass Framework-Designmuster es einfach machen, das Richtige zu tun, und schwer nachzuvollziehende Anti-Muster zu befolgen. Das Framework unterstützt Entwickler beim Anwendungsdesign und mit der Codestruktur.
Um die Ladeleistung zu steigern, sollte jede Ressource (Schriftarten, CSS, JavaScript, Bilder usw.) optimiert werden. Dies ist eine komplexe Herausforderung, bei der Byte gekürzt, Umlaufzeiten reduziert und für das erste Rendering, die visuelle Bereitschaft und die Nutzerinteraktion getrennt werden müssen. Dazu gehört beispielsweise das Extrahieren von wichtigem CSS-Code und das Festlegen der Priorität für wichtige Bilder.
2. Umsetzbare Regeln
Auch wenn grundlegende Optimierungen implementiert sind, müssen die Entwickler Entscheidungen treffen. Es gibt eine Reihe von Optimierungsmöglichkeiten für den erforderlichen Entwicklerbeitrag:
- Standardeinstellungen, die keine Eingaben des Entwicklers erfordern, z. B. das Einfügen wichtiger CSS-Elemente.
- Entwickler-Opt-in erforderlich machen. Verwenden Sie beispielsweise eine vom Framework bereitgestellte Bildkomponente, um die Größe und Skalierung von Bildern anzupassen.
- Opt-in und Anpassung durch Entwickler erforderlich Sie können beispielsweise wichtige Bilder taggen, damit sie frühzeitig geladen werden.
- Es handelt sich nicht um eine bestimmte Funktion, sondern um Aspekte, die eine Entscheidung des Entwicklers erfordern. Vermeiden Sie es z. B., Schriftarten oder synchrone Skripts zu verwenden, die das frühe Rendering verzögern.
Optimierungen, die Entscheidungen von Entwicklern erfordern, stellen ein Risiko für die Leistung der Anwendung dar. Wenn neue Funktionen hinzukommen und Ihr Team wächst, können selbst die erfahrensten Entwickler nicht mit den sich ständig ändernden Best Practices Schritt halten und sie nutzen ihre Zeit nicht optimal. Aus Gründen der Konformität sind geeignete umsetzbare Regeln genauso wichtig wie starke Standardeinstellungen, damit die Anwendung auch dann weiterhin einem bestimmten Standard entspricht, wenn Entwickler weiterhin Änderungen vornehmen.
3. Erstellungszeit
Es ist wichtig, Leistungsprobleme frühzeitig im Entwicklungszyklus zu erkennen und auszuschließen. Die Erstellungszeit vor dem Commit des Codes eignet sich ideal, um Probleme zu erkennen und zu beheben. Je später ein Problem im Entwicklungszyklus erfasst ist, desto schwieriger und teurer wird seine Behebung. Dies gilt zwar für Korrektheitsprobleme, aber auch für Leistungsprobleme, da viele dieser Probleme nicht rückwirkend behoben werden, nachdem der Commit für die Codebasis durchgeführt wurde.
Heutzutage ist das meiste Leistungsfeedback aufgrund der Dokumentation und einmaligen Audits Out-of-Band oder es wird zu spät nach der Bereitstellung in der Produktion durch die Messwertregression angezeigt. Wir wollen das zur Erstellungszeit bringen.
Konformität in Frameworks
Die folgenden Fragen müssen beantwortet werden, um für eine hohe Nutzerfreundlichkeit bei der Ladeleistung zu sorgen:
- Was gilt als optimales Laden und welche Probleme können sich negativ auf das Laden auswirken?
- Welche Lösungen können integriert werden, die keinen Input von Entwicklern erfordern?
- Wie können wir sicherstellen, dass das Entwickler-Team diese Lösungen optimal einsetzt?
- Welche anderen Optionen könnte der Entwickler treffen, die sich auf die Ladeleistung auswirken?
- Welche Codemuster können uns zu Beginn der Erstellung über diese Auswahlmöglichkeiten (Nr. 3 und Nr. 4 oben) informieren?
- Welche Regeln können wir aufstellen, um diese Codemuster zu bewerten? Wie können sie dem Entwickler zum Zeitpunkt der Erstellung angezeigt und gleichzeitig nahtlos in seinen Workflow eingebunden werden?
Um das bei Google interne Konformitätsmodell auf Open-Source-Frameworks anzuwenden, hat unser Team intensiv in Next.js getestet und wir freuen uns, unsere ausgefeilte Vision und unsere Pläne mit Ihnen teilen zu können. Wir haben erkannt, dass der beste Regelsatz zur Bewertung von Codemustern eine Kombination aus statischer Codeanalyse und dynamischen Prüfungen sein muss. Diese Regeln können sich auf mehrere Oberflächen beziehen, darunter:
- ESLint
- TypeScript
- Dynamische Prüfungen auf dem Entwicklungsserver des Nutzers (nach der DOM-Erstellung)
- Modul-Bundler (Webpack)
- CSS-Tools (noch explorativ)
Indem wir Regeln über verschiedene Tools zur Verfügung stellen, können wir dafür sorgen, dass sie kohärent sind, aber auch Probleme mit der Nutzerfreundlichkeit berücksichtigt werden, die sich direkt auf die Ladeleistung auswirken. Außerdem können diese Regeln den Entwicklern zu unterschiedlichen Zeiten angezeigt werden:
- Während der lokalen Entwicklung im Entwicklungsserver werden im Browser und in der IDE des Nutzers Warnungen angezeigt, die Entwickler dazu auffordern, kleine Codeänderungen vorzunehmen.
- Bei der Build-Erstellung werden ungelöste Probleme wieder im Terminal des Nutzers angezeigt
Kurz gesagt wählen Teams die für sie relevanten Ergebnisse aus, wie Core Web Vitals oder die Ladeleistung, und aktivieren relevante Regelsätze für alle Code-Mitwirkenden.
Dies funktioniert zwar sehr gut bei neuen Projekten, es ist jedoch nicht einfach, große Codebasis zu aktualisieren, um vollständige Regelsätze zu erfüllen. Bei Google haben wir ein umfangreiches System zur Deaktivierung auf verschiedenen Ebenen, z. B. einzelne Quellcodezeilen, ganze Verzeichnisse, Legacy-Codebasis oder Teile der Anwendung, die nicht aktiv entwickelt werden. Wir suchen aktiv nach effektiven Strategien, wie wir diese Teams mit Open-Source-Frameworks zur Verfügung stellen können.
Konformität in Next.js
ESLint wird von JavaScript-Entwicklern weithin verwendet. Über 50% der Next.js-Anwendungen nutzen ESLint in einem Teil ihres Build-Workflows. Next.js v11 bietet eine sofort einsatzbereite ESLint-Unterstützung mit einem benutzerdefinierten Plug-in und einer gemeinsam genutzten Konfiguration, mit der sich häufige Frameworks-spezifische Probleme während der Entwicklung und Build-Erstellung leichter erkennen lassen. Dies kann Entwicklern helfen, erhebliche Probleme beim Erstellen zu beheben. Das ist beispielsweise der Fall, wenn eine bestimmte Komponente auf eine Weise verwendet oder nicht auf eine Weise verwendet wird, die sich auf die Leistung auswirken könnte, wie im Abschnitt Kein HTML-Link für Seite beschrieben. Oder wenn eine bestimmte Schriftart, ein Stylesheet oder ein Skript sich negativ auf das Laden von Ressourcen auf einer Seite auswirken kann. Beispiel: Kein synchrones Skript.
Neben ESLint wird in Next.js seit Version 9 auch integrierte Typprüfung in der Entwicklung und Produktion unterstützt und TypeScript wird unterstützt. Mehrere vom Framework bereitgestellte Komponenten (Bild, Script, Link) wurden als Erweiterung von HTML-Elementen (<img>, <script>, <a>) erstellt, um Entwicklern einen leistungsfähigen Ansatz zum Hinzufügen von Inhalten zu einer Webseite zu bieten. Die Typprüfung unterstützt die angemessene Nutzung dieser Funktionen, indem sichergestellt wird, dass die zugewiesenen Eigenschaften und Optionen im zulässigen Bereich der unterstützten Werte und Typen liegen. Ein Beispiel finden Sie unter Erforderliche Bildbreite und -höhe.
Fehler bei Toasts und Overlays anzeigen
Wie bereits erwähnt, können Konformitätsregeln in mehreren Bereichen angezeigt werden. Toasts und Overlays werden derzeit getestet, um Fehler direkt im Browser in der lokalen Entwicklungsumgebung des Nutzers anzuzeigen.
Viele Tools zur Fehlerprüfung und Prüfung, auf die sich Entwickler verlassen (Tab „Probleme“ von Lighthouse, Chrome-Entwicklertools), sind passiv und erfordern eine Nutzerinteraktion, um Informationen abzurufen. Entwickler reagieren eher, wenn Fehler direkt in ihren vorhandenen Tools auftauchen und wenn sie konkrete und spezifische Maßnahmen zur Behebung des Problems nennen.
Konformität in anderen Rahmenbedingungen
Sie wird zuerst in Next.js auf die Konformität geprüft, um sie auf andere Frameworks (Nuxt, Angular usw.) auszuweiten. ESLint und TypeScript werden bereits in vielen Frameworks auf viele verschiedene Arten verwendet, aber das Konzept eines zusammenhängenden Laufzeitsystems auf Browserebene wird derzeit aktiv erforscht.
Fazit
Durch die Konformität werden Best Practices in Regelsätze codiert, die für Entwickler als einfache Codemuster verwertbar sind. Das Aurora-Team hat sich auf die Ladeleistung konzentriert, aber andere Best Practices wie Barrierefreiheit und Sicherheit sind genauso anwendbar.
Die Einhaltung von Konformitätsregeln sollte zu vorhersehbaren Ergebnissen führen, und das Erreichen hoher Anforderungen an die Nutzerfreundlichkeit kann ein Nebeneffekt der Erweiterung Ihres Technologie-Stacks werden. Konformität macht Teams produktiv und sorgt für hohe Qualitätsanforderungen für die Anwendung, selbst wenn Teams und Codebasen im Laufe der Zeit wachsen.