Nytt fra Next.js, GitHub og Safari

Next.js 16.3 er ute for testing⚡️

Sakte men sikkert nærmer vi oss Next.js 16.3, og Vercel har lagt ut en serie med bloggposter som beskriver alt som er nytt.

Et stort fokus har vært å gjøre nettsider laget med Next mer responsive. For en server-app er det vanligvis to tregheter:

1. Klienten må kontakte serveren
2. Serveren må generere en respons

Den første har typisk blitt løst med prefetching. For hver synlig lenke på siden, sendte Next en forespørsel til serveren for å ha innholdet klart på forhånd. Dette kunne derimot resultere i flere titalls nettverksforespørsler.

Med "Partial Prefetching" ønsker Vercel å redusere antall nettverkskall. I stedet for å sende en forespørsel for hver lenke, vil Next gjøre ett kall for hver rute som skal hentes på forhånd. Hvis du har en side med tjue lenker som går til /chat/[id] med ulike ID-er, og en lenke som går til /dashboard, vil Next bare gjøre to nettverkskall.

Den andre tregheten kan enten løses ved å cache alt som er treigt, eller ved å vise en lastetilstand. Hvis du ikke har håndtert en blokkerende rute med enten lasting eller caching, vil du få et varsel i utviklingskonsollen som vil be deg om å enten håndtere dette, eller eksplisitt erklære ruten som blokkerende.

nextjs.orgNext.js 16.3: Instant Navigations

A new suite of tools that brings the responsiveness of a single-page app to the server-centric model of Next.js.

Forbedringer i Turbopack

Med 16.3 kommer også en drøss med forbedringer i Turbopack. 

Turbopack har lenge brukt veldig mye minne i utviklingsmodus. Årsaken er såkalt "inkrementell kompilering", hvor alle kompilerte filer blir cachet, og ved neste kompilering blir kun endrede filer kompilert. Det gjør at en stor rute kan kompilere svært raskt hvis den er delt opp i flere små filer.

Caching som dette avlaster CPU-en på bekostning av minne. Men flere utviklingsverktøy spiser mye minne, som lintere, IDE-er, typesjekkingsverktøy, eller til og med lokale språkmodeller. Derfor vil Vercel redusere hvor mye minne som brukes.

Siden 16.1 har turbopack-cachen blitt lagret på disk når man starter Next i utviklingsmodus med next dev. Ved omstart av dev-serveren blir cachen lest inn i minnet, så man slipper å rekompilere uendrede deler av applikasjonen. Å lagre cachen på disk gjør det altså raskere å starte dev-serveren på nytt, men den holder fortsatt hele cachen i minnet når den kjører.

Fra 16.3 holder Turbopack bare små deler av cachen i minnet, og laster inn biter av cachen fra disken ved behov. Dette kaller de "memory eviction", og det har betraktelig redusert dev-serverens minnebruk.

Nå kan også produksjonsbygg generert av next build bli cachet på disk. En fordel med dette er at cachen kan gjenbrukes mellom CI-kjøringer. Hvis CI-oppsettet ditt lagrer og gjenbruker .next-mappen, vil Turbopack finne cachen i starten av bygget, og kun kompilere nye endringer. Caching av produksjonsbygg på disk må skrus på eksplitt:

const nextConfig = { experimental: { // Skru på filesystem-caching for `next build` turbopackFileSystemCacheForBuild: true, } }

Les mer om Turbopack-endringene i bloggposten til Vercel 👇

nextjs.orgTurbopack: What's New in Next.js 16.3

Turbopack in Next.js 16.3 adds development memory eviction, persistent file cache for builds, experimental Rust React Compiler, and `import.meta.glob` ...

GitHub lar seg ikke overrumple av sikkerhetsvarsler 😼

Generativ KI har gjort det mye lettere å finne sårbarheter i kode. GitHub rapporterer at antall private sårbarhetsvarsler har økt fra 550 per uke i januar til over 3000 per uke i mai. Samtidig økte antallet repository-varsler fra 650 til over 5000 per uke. For to år siden ble det bare publisert rundt 270 varsler i måneden.

GitHub har egne kuratorer som verifiserer varslene manuelt, og har siden april slitt med å møte sine interne mål for behandlingstid. Jo lengre de bruker på å behandle et varsel, desto lengre ligger sårbarheten ute. Så hvordan håndterer GitHub dette?

Først og fremst har de blitt flinkere til å sortere sikkerhetsrapporter tidlig, slik at de som er godt utfylt og lette å verifisere plukkes ut og godkjennes raskt, i stedet for å ligge i kø sammen med de kompliserte sakene. Kuratorene har også fått KI-verktøy som kan bistå i grunnleggende analyser de uansett ville gjort manuelt. I tillegg har de automatisert datainnhentingen bedre. Verktøyene deres plukker nå ut informasjon som pakkenavn og versjoner automatisk, i stedet for at en kurator må grave det fram manuelt.

Til tross for disse forbedringene, påpeker GitHub at mye av kompleksiteten i arbeidet deres stammer fra ufullstendige sårbarhetsrapporter. Hvis rapporten inneholder utfyllende informasjon, kan sårbarheten behandles på noen få minutter. Derfor er det vi som utviklere som kan gjøre den største forskjellen. Hvis vi vil at sårbarhetene våre skal behandles raskt, er vi nødt til å ta litt ansvar når vi rapporterer dem inn.

github.blogInside the Advisory Database and what happens when vulnerability volume breaks records

The GitHub Advisory Database is processing more vulnerability reports than ever before. Here's what's driving the surge and how we're responding.

Safari får en MCP-server 🤖

Safari har gjort det litt lettere å være utvikler med en splitter ny MCP-server. Nå vil KI-agenter kunne få tilgang til mer av det brukerne opplever på siden din, i tillegg til teknisk informasjon som vil hjelpe ved feilsøking. 

Blant annet vil de kunne inspisere DOM-en, fange opp nettverksforespørsler, lese konsollen, samt ta og analysere skjermbilder. Med dette blir det mulig å bruke KI ikke bare til å fikse feil, men også til å forbedre ytelse og universell utforming.

Foreløpig er MCP-serveren kun tilgjengelig gjennom Safari Technology Preview, altså Safari-versjonen som tilgjengeliggjør eksperimentell funksjonalitet. Du kan teste den ut ved å legge til et par linjer i MCP-konfigurasjonen din:

"safari-mcp-stp": { "command": "/Applications/Safari Technology Preview.app/Contents/MacOS/safaridriver", "args": ["--mcp"] }

Les mer om MCP-serveren i bloggposten til WebKit 👇

webkit.orgIntroducing the Safari MCP server for web developers

In Safari Technology Preview 247, we’re introducing the Safari MCP server — a Model Context Protocol server for web developers that makes ...

Det var alt for denne gang, ha en fin uke 👋