Conformiteit in het JavaScript-framework-ecosysteem
In onze inleidende blogpost hebben we besproken hoe we veel hebben geleerd tijdens het bouwen en gebruiken van frameworks en tools voor het ontwikkelen en onderhouden van grootschalige webapplicaties zoals Google Zoeken, Maps, Foto's, enzovoort. Door ontwikkelaars te beschermen tegen het schrijven van code die de gebruikerservaring negatief kan beïnvloeden, hebben we bewezen dat frameworks een sleutelrol kunnen spelen bij het veranderen van de resultaten op het gebied van prestaties en applicatiekwaliteit.
Intern bij Google hebben we de term ' Conformance ' gebruikt om deze methodologie te beschrijven, en dit artikel beschrijft hoe we van plan zijn dit concept open source te maken voor het JavaScript-framework-ecosysteem.
Wat is conformiteit?
Bij Google was Conformance een evolutie. Teams vertrouwden op een kleine groep zeer ervaren beheerders die uitgebreide codebeoordelingen uitvoerden, waarbij ze zaken signaleerden die van invloed waren op de kwaliteit en onderhoudbaarheid van de app, veel verder dan correctheidsproblemen. Om dit op te schalen naar groeiende teams van app-ontwikkelaars, is een Conformance-systeem ontwikkeld om best practices te codificeren op een manier die geautomatiseerd en afdwingbaar is. Dit zorgde voor een consistent hoge lat voor app-kwaliteit en onderhoudbaarheid van de codebase, ongeacht het aantal codebijdragers.
Conformance is een systeem dat ervoor zorgt dat ontwikkelaars op het goed verlichte pad blijven; het schept vertrouwen en zorgt voor voorspelbare resultaten. Het maakt teams productief en wordt cruciaal voor schaalvergroting – naarmate teams groeien en er tegelijkertijd meer functies worden ontwikkeld. Het stelt ontwikkelaars in staat zich te concentreren op het bouwen van productfuncties, waardoor ze worden bevrijd van details en het veranderende landschap op verschillende gebieden, zoals prestaties, toegankelijkheid, beveiliging, enz. Iedereen kan zich op elk moment afmelden voor Conformance, en het moet in die mate aanpasbaar zijn. dat teams de mogelijkheid hebben om af te dwingen wat ze ook besluiten te doen.
Conformiteit is gebaseerd op sterke standaardwaarden en het bieden van uitvoerbare regels die tijdens het schrijven kunnen worden afgedwongen. Dit valt uiteen in de volgende 3 principes.
1. Sterke wanbetalingen
Een fundamenteel aspect van conformiteit is ervoor zorgen dat de tools die ontwikkelaars gebruiken over sterke standaardwaarden beschikken. Dit betekent dat oplossingen niet alleen in raamwerken zijn ingebed, maar dat raamwerkontwerppatronen het gemakkelijk maken om het juiste te doen en moeilijk om antipatronen te volgen. Het raamwerk ondersteunt ontwikkelaars met applicatieontwerp en codestructuur.
Voor laadprestaties moet elke bron (lettertypen, CSS, JavaScript, afbeeldingen, enz.) worden geoptimaliseerd. Dit is een complexe uitdaging waarbij het aantal bytes wordt ingekort, roundtrips worden verminderd en wordt gescheiden wat nodig is voor de eerste weergave, visuele gereedheid en gebruikersinteractie. Bijvoorbeeld het extraheren van kritische CSS en het instellen van prioriteit op belangrijke afbeeldingen.
2. Bruikbare regels
Zelfs als er fundamentele optimalisaties zijn doorgevoerd, moeten ontwikkelaars nog steeds keuzes maken. Er is een spectrum aan mogelijkheden voor optimalisatie als het gaat om hoeveel input van ontwikkelaars nodig is:
- Standaardwaarden waarvoor geen input van de ontwikkelaar nodig is, zoals het inlinen van kritische CSS.
- Vereist aanmelding voor ontwikkelaars. U kunt bijvoorbeeld een door het raamwerk geleverde afbeeldingscomponent gebruiken om afbeeldingen te vergroten of verkleinen.
- Vereist aanmelding voor ontwikkelaars en maatwerk. Bijvoorbeeld door belangrijke afbeeldingen te taggen zodat ze vroegtijdig worden geladen.
- Geen specifieke functie, maar dingen die nog steeds een beslissing van de ontwikkelaar vereisen. Vermijd bijvoorbeeld lettertypen of synchrone scripts die vroege weergave vertragen.
Optimalisaties waarvoor een beslissing van de ontwikkelaars nodig is, vormen een risico voor de prestaties van de applicatie. Naarmate er functies worden toegevoegd en uw team schaalt, kunnen zelfs de meest ervaren ontwikkelaars de voortdurend veranderende best practices niet bijhouden, en dit is ook niet de beste manier om hun tijd te besteden. Voor Conformance zijn passende, uitvoerbare regels net zo belangrijk als sterke standaardwaarden om ervoor te zorgen dat de applicatie aan een bepaalde standaard blijft voldoen, zelfs als ontwikkelaars wijzigingen blijven aanbrengen.
3. Auteurstijd
Het is belangrijk om prestatieproblemen vroeg in de ontwikkelingslevenscyclus op te sporen en uit te sluiten . De schrijftijd, voordat de code wordt vastgelegd, is bij uitstek geschikt om problemen op te sporen en aan te pakken. Hoe later een probleem in de ontwikkelingscyclus wordt ontdekt, hoe moeilijker en duurder het is om het aan te pakken. Hoewel dit van toepassing is op correctheidsproblemen, geldt dit ook voor prestatieproblemen, aangezien veel van deze problemen niet met terugwerkende kracht zullen worden aangepakt zodra ze zijn vastgelegd in de codebase.
Tegenwoordig is de meeste prestatiefeedback out-of-band via documentatie en eenmalige audits, of komt deze te laat boven water via metrische regressie na implementatie in productie. We willen dit meenemen naar de schrijftijd.
Conformiteit in raamwerken
Om de gebruikerservaring op het gebied van laadprestaties hoog te houden, moeten de volgende vragen worden beantwoord:
- Wat is optimale belasting, en wat zijn de veelvoorkomende problemen die hier een negatieve invloed op kunnen hebben?
- Welke oplossingen kunnen worden ingebakken die geen input van ontwikkelaars nodig hebben?
- Hoe kunnen we ervoor zorgen dat de ontwikkelaar deze oplossingen gebruikt en optimaal benut?
- Welke andere keuzes kan de ontwikkelaar maken die van invloed zijn op de laadprestaties?
- Wat zijn de codepatronen die ons al tijdens het schrijven over deze keuzes (#3 en #4 hierboven) kunnen vertellen?
- Welke regels kunnen we formuleren om deze codepatronen te beoordelen? Hoe kunnen ze tijdens het schrijven aan de ontwikkelaar worden getoond terwijl ze naadloos in hun workflow worden geïntegreerd?
Om het Conformance-model dat we intern bij Google hebben naar open-sourceframeworks te brengen, heeft ons team intensief geëxperimenteerd met Next.js en we zijn verheugd om onze verfijnde visie en plannen te delen. We hebben ons gerealiseerd dat de beste set regels die codepatronen kan beoordelen een combinatie zal moeten zijn van statische codeanalyse en dynamische controles. Deze regels kunnen meerdere oppervlakken bestrijken, waaronder:
- ESLint
- Typescript
- Dynamische controles op de ontwikkelingsserver van de gebruiker (na het maken van een DOM)
- Modulebundelaar (webpack)
- CSS-tooling (nog steeds verkennend)
Door te profiteren van het aanbieden van regels via verschillende tools, kunnen we ervoor zorgen dat ze samenhangend zijn, maar ook eventuele problemen met de gebruikerservaring omvatten die een directe invloed hebben op de laadprestaties. Bovendien kunnen deze regels ook op verschillende tijdstippen aan ontwikkelaars worden getoond:
- Tijdens lokale ontwikkeling op de ontwikkelingsserver zullen de browser en de IDE van de gebruiker waarschuwingen weergeven, waardoor ontwikkelaars kleine codewijzigingen moeten doorvoeren.
- Tijdens het bouwen worden onopgeloste problemen opnieuw weergegeven in de terminal van de gebruiker
Kortom: teams kiezen de uitkomsten die zij belangrijk vinden, zoals Core Web Vitals of laadprestaties, en stellen relevante regelsets in die alle codebijdragers kunnen volgen.
Hoewel dit heel goed werkt voor nieuwe projecten, is het niet eenvoudig om grote codebases te upgraden om aan de volledige regelsets te voldoen. Bij Google hebben we een uitgebreid systeem voor opt-out op verschillende niveaus, zoals individuele regels broncode, volledige mappen, oudere codebases of delen van de app die niet actief worden ontwikkeld. We onderzoeken actief effectieve strategieën om dit naar teams te brengen met behulp van open-sourceframeworks.
Conformiteit in Next.js
ESLint wordt veel gebruikt door JavaScript-ontwikkelaars. en meer dan 50% van de Next.js-applicaties gebruiken ESLint in een deel van hun build-workflow. Next.js v11 introduceerde out-of-the-box ESLint-ondersteuning met een aangepaste plug- in en deelbare configuratie om het gemakkelijker te maken om algemene raamwerkspecifieke problemen op te lossen tijdens de ontwikkeling en tijdens de bouwtijd. Dit kan ontwikkelaars helpen bij het oplossen van belangrijke problemen tijdens het schrijven. Voorbeelden zijn onder meer wanneer een bepaald onderdeel wel of niet wordt gebruikt op een manier die de prestaties zou kunnen schaden, zoals in Geen HTML-link voor pagina ). Of als een bepaald lettertype, stylesheet of script een negatieve invloed kan hebben op het laden van bronnen op een pagina. Bijvoorbeeld Geen synchroon script .
Naast ESLint wordt sinds v9 geïntegreerde typecontrole in zowel ontwikkeling als productie ondersteund in Next.js met TypeScript-ondersteuning. Meerdere componenten van het framework (Image, Script, Link) zijn gebouwd als een uitbreiding van HTML-elementen ( <img> , <script> , <a> ) om ontwikkelaars een performante aanpak te bieden voor het toevoegen van inhoud aan een webpagina. Typecontrole ondersteunt het juiste gebruik van deze functies door ervoor te zorgen dat toegewezen eigenschappen en opties binnen het aanvaardbare bereik van ondersteunde waarden en typen vallen. Zie vereiste afbeeldingsbreedte en -hoogte voor een voorbeeld.
Fouten opsporen met toast en overlays
Zoals eerder vermeld, kunnen conformiteitsregels op meerdere gebieden voorkomen. Toasts en overlays worden momenteel onderzocht als een manier om fouten rechtstreeks in de browser aan het licht te brengen binnen de lokale ontwikkelomgeving van de gebruiker.
Veel foutcontrole- en audittools waar ontwikkelaars op vertrouwen (Lighthouse, tabblad Problemen met Chrome DevTools) zijn passief en vereisen een vorm van gebruikersinteractie om informatie op te halen. Ontwikkelaars zullen eerder actie ondernemen wanneer fouten direct binnen hun bestaande tools aan het licht komen, en wanneer ze concrete en specifieke acties bieden die moeten worden ondernomen om het probleem op te lossen.
Conformiteit in andere raamwerken
Conformiteit wordt eerst onderzocht in Next.js met als doel uit te breiden naar andere raamwerken (Nuxt, Angular, enz.). ESLint en TypeScript worden al op veel verschillende manieren in veel raamwerken gebruikt, maar het concept van een samenhangend runtime-systeem op browserniveau wordt actief onderzocht.
Conclusie
Conformance codificeert best practices in regelsets die voor ontwikkelaars bruikbaar zijn als eenvoudige codepatronen. Het Aurora-team heeft zich gefocust op laadprestaties, maar andere best practices, zoals toegankelijkheid en beveiliging, zijn net zo toepasbaar.
Het volgen van conformiteitsregels zou moeten resulteren in voorspelbare resultaten, en het bereiken van een hoge lat voor gebruikerservaring kan een neveneffect worden van het voortbouwen op uw tech-stack. Conformiteit maakt teams productief en zorgt voor een hoogwaardige balk voor de applicatie, zelfs als teams en codebases in de loop van de tijd groeien.