Kent C. Dodds ble kvitt dependabots-mas med KI

Cloudflare skrev om Next.js på ei uke med KI, Kent C. Dodds ble kvitt dependabots mas, og sprites i CSS.

Kent C. Dodds ble kvitt mas fra dependabots.
Publisert

< forrigeUke />

ForrigeUke er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var. Innleggene skrives av frontend-faggruppene til Bekk, og kan også følges på blogg.bekk.no

.

Dette var uka for redirects og brukerstyrte funksjonsbrytere – og 1440 ting som skjedde i frontendverdenen!

… og på den syvende dagen skapte Han vinext 💸

Én utvikler fra Cloudflare gjenbygde nettopp Next.js med Vite og kaller resultatet vinext. Det tok ham en uke og kosta 1 100 dollar i tokens. Poenget var å gjøre det enklere å deploye Next.js-applikasjoner på Cloudflare, men tidlige benchmark-tall viser forbedring i både byggetid og bundle-størrelse:

vinext viser lovende forbedringer over Next.js i byggetid og bundle size.

Steve Faulkner fra Cloudflare skriver videre om noen av mulighetene dette gir. En kul funksjonalitet er såkalt “Traffic-aware Pre-Rendering” (TPR). Istedenfor å pre-rendre alle 100 000 produktsidene dine, kan Cloudflare se på de 50-200 mest brukte sidene, og dermed drastisk redusere byggetiden.

Faulkner trekker også frem hvordan å lage et rammeverk – som har tatt mange år å lage – plutselig var mulig for én fyr. Et av poengene er at Next.js er godt dokumentert, både i form av tester, Stack Overflow (RIP) og utbredt dokumentasjon. Også har KI-modeller blitt sterkere. Dette var ikke nødvendigvis mulig for noen måneder siden – som er ganske sykt at så mye kan endres på så kort tid.

Sjekk ut Faulkners post, for litt mer detaljer rundt hvordan vinext ble lagd og hva det betyr for fremtidig programvare:

How we rebuilt Next.js with AI in one week

Dependabot-oppgradering i lunsjpausen 🔨

Du planlegger kanskje ikke å lage det neste rammeverket, men du har sikkert en haug dependabots- pull requester du prokrastinerer?

Med noen tokens kan dette problemet også forsvinne. I lunsjpauser og mens han sov, har nemlig Kent C. Dodds oppdatert prosjektet sitt.

Han startet ved å spørre Cursor hvilke pakker som lett kunne bli oppdatert, og oppdaterte dem først. Så de medium vanskelige som krevde litt justeringer, så de tricky major-versjonene. Selv ved flere majorversjoner gikk dette ganske knirkefritt.

Årsaken attribuerer han til trad-coding:

«This only really works because I have some pretty good tests and documentation that I made when I was actively developing the project (with my bare hands, like some kind of caveman).»– Kent C. Dodds

Så igjen ser vi hvordan tester og dokumentasjon hjelper KI å stå på rett kurs. For å få noen tips til de konkrete promptene, ta en titt på artikkelen:

How I used Cursor to Migrate Frameworks

Rammeverk gir nødvendige støttehjul 🛤️

Nå som KI er en del av arbeidsflyten, trenger vi egentlig å bry oss om å bruke rammeverk?

For å hoppe til konklusjonen, tror utvikler Zima vi trenger det mer enn noensinne. Dette etter han brukte to uker på å bare bruke vanlige HTML og vanilla JS – istedenfor Next.js.

Rammeverk, før KI-revolusjonen, ga oss tre ting:

  • slippe å finne opp hjulet (routing, tilstandshåndtering)
  • fremme bestepraksiser (sikkerhet, ytelse)
  • bli enige om konvensjoner i teamet

Nå som KI er et ekstra medlem i teamet, er det tredje punktet ekstra viktig. Rammeverk har en haug av regler bygd inn, som at sider skal ligge under /app- mappen. Denne regelen kunne vært opprettholdt som en del av KI-konteksten, men det er både mindre å skrive og mer spesifikt gjennom å bruke et rammeverk.

Sjekk ut resten av posten for å se hvorfor rammeverk er nødvendig for å støtte opp om vår kjære KI-agent:

Removing Next.js Taught Me Why Frameworks Are Still Essential Even for AI

Sprites på web-en 🎮

Nå over til noe helt annet. Hvordan klarte egentlig Twitter å få den lille favoritt-animasjonen til å føles rask – selv på treige mobiler?

Rundt 2015 satt mange brukere med trege telefoner. Å få til en kul animasjon med komplekse DOM-oppdateringer kunne føre til lagg på gamle enheter. Ikke helt verdt det – men i Josh Comeaus nyeste bloggpost forklarer Comeau hvordan de løste det, med en teknikk hentet fra videospill: sprites.

Med object-position styrer du utsnittet. Skjermbilde fra bloggposten.

En sprite fungerer litt som en filmrull: Mange enkeltbilder ligger samlet i ett og samme bilde. I stedet for å laste og vise masse separate elementer, viser du bare ett utsnitt om gangen – og flytter “vinduet” bortover, bilde for bilde.

I CSS kan du styre hva du viser av spriten ved å vise én del av bildet, og så hoppe stegvis videre:

<style>
  @keyframes sprite {
    from {
	  // 👇 Starter å vise fra venstre
      object-position: 0% 0%;
    }
    to {
	  // 👇 Ender visning på høyre
      object-position: 100% 0%;
    }
  }
  
  .trophy {
	/*
      👇 Uten object fit cover vil alle bildene i spritene 
      squashes sammen. Vi vil vise ett av gangen.
    */
    object-fit: cover;
    // 👇 5 steps siden vi her har 5 bilder i spriten.
    animation:
      sprite 1s steps(5, jump-none) infinite;
  }
</style>

Ganske kult!

Resultatet er en en jevn animasjon – uten tung JavaScript – som gir en fet effekt, også på svakere enheter.

Altså de kunne løst dette også med en GIF. Men da får du ikke samme finstyring og mulighet for interaksjon.

For mer detalj rundt CSS-en og når vi egentlig bør bruke sprites versus andre animasjons-teknikker, se på bloggposten:

Sprites on the Web • Josh W. Comeau

Det var alt for denne gang. Ses igjen neste uke! 👋

Powered by Labrador CMS