<ForrigeUke uke"9" år="2026" />
KI, rammeverk og videospill – i denne ukas ForrigeUke.
Dette var uka for redirects og brukerstyrte funksjonsbrytere – og 1440 ting som skjedde i frontendverdenen!
«<ForrigeUke /> er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var.»
… 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:
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
One engineer used AI to rebuild Next.js on Vite in a week. vinext builds up to 4x faster, produces 57% smaller bundles, and deploys to Cloudflare ...
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
I upgraded kentcdodds.com from Remix v2 to React Router v7 in a day with over 17k lines of code changed. Here's how I did it.
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.
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
In game development, it’s common to use spritesheets for animation, but this technique isn’t as widely used on the web these days. Which ...
Det var alt for denne gang. Ses igjen neste uke! 👋
