Dette var uka for installasjonsmagi og fullførte setninger - og 1907 andre ting som skjedde i frontendverdenen!

Next.js med storlansering

Next.js versjon 16.3 markerer den største oppgraderingen siden november i fjor. Denne inkluderer en rekke oppgraderinger som gjør Next.js kjappere.

nextjs.org

Next.js 16.3

Next.js 16.3 introduces Instant Navigations, a suite of tools for single-page-app responsiveness, plus a faster dev server, faster builds, ...

Et av tiltakene er å bruke "disk caching" og "memory eviction" i Turbopack. Dette innebærer at beregninger som ikke aktivt brukes i RAM, men trengs senere, kan caches på disk og fjernes fra RAM - frem til de igjen trengs. Tidligere har lengre utviklingssesjoner kunne hopt opp minnebruk, men dette tiltaket har blitt målt til å kunne spare har 90% av minnet. Samme teknikk har også blitt brukt ved builds, som har gitt 5,5x raskere build i CI.

Next.js støtter også TypeScript 7 nå, som på sin side kan gi 10x kjappere typesjekking. Med andre ord, utviklingsopplevelsen i Next.js bør føles betydelig kjappere nå, om det så er agenten som raskere må vente på ny instruks fra deg.

For sistnevnte har Next.js også gjort et nyttig tiltak: AI-agenter vil automatisk lese fra dokumentasjonen som matcher Next.js-versjonen i prosjektet du bruker. Det er godt å høre, hilsen en som tidligere har fått Pages Router-forslag i mitt App Router-prosjekt.

Dytt på server-vs-SPA-pendelen

I denne versjonen har Next.js også dyttet på pendelen mellom klient- og server- arkitektur ved å forbedre navigasjoner. For å forstå hvordan, må vi først se litt på historikk:

Før, i en MPA (multi-page application), ville brukeren trykke på en lenke, nettleseren sende en forespørsel til serveren, og serveren sende en ny HTML-side tilbake som førte til ny sideinnlastning. For brukeren kunne det altså ta litt tid fra å trykke på en lenke til den nye navigeringen skjedde.

Så kom SPA-er (single-page applications), som ble populært å bygge, blant annet via React. Her kunne JavaScript i nettleseren håndtere navigeringen, slik at brukeren slapp å vente på en helt ny side fra serveren hver gang. Brukeren kunne se et skall av en ny side, mens nye data ble lastet inn.

Men på grunn av at hele nettsiden ikke nødvendigvis hadde alle dataene klare, kunne brukeren bli møtt av masse spinnere. Noe av dette ble løst med serverkomponenter, som flyttet mer av jobben tilbake til serveren.

Men fra historikk med MPA skjønner du kanskje hva som skjedde da mer arbeid ble flyttet til serveren? Serverresponsen ble tregere, så flere klagde på at navigasjon i Next.js (med serverkomponenter) føltes tregt.

For å både gjøre utvikleropplevelsen og brukeropplevelsen rundt navigasjon bedre, har Next.js lagd en samling av verktøy kalt "Instant Navigations".

For arbeid på serveren kan utvikleren nå velge mellom to måter å gi brukeren rask respons:

1) Stream med Suspense. Vis laste-tilstand umiddelbart, mens mer streames inn senere

2) Cache med "use cache". Vis et tidligere cachet grensesnitt

Begge måter vil føles øyeblikkelige for brukeren. Men det er også et gyldig alternativ å ikke gjøre navigasjonen øyeblikkelig, som om du har en bloggpost du ønsker skal vises i sin helhet når den først kommer - uten innhold som gradvis hopper inn. Da kan "block" brukes:

// i page.tsx eller layout.jsx
export const instant = false;

Alternativene over lar deg bestemme hvordan du vil håndtere ventetiden på at serveren prosesserer noe. Men det løser ikke tiden klienten tar å først komme til serveren.

Next.js har fra før tilbudt prefetching som henter innhold allerede før brukeren trykker på en lenke. Så da er innholdet klart, før brukeren trenger å vente på serveren. Men det kan bli unødvendig dyrt å hente data for 20 lenker når brukeren kanskje bare trykker på én av dem.

Her har Next.js endret til å tilby også partial prefetching. Istedenfor å hente fulle sider, kan Next.js hente skallet for felles ruter. Så Next.js kan hente skallet for /chat/[id], i stedet for /chat/1, /chat/2 og så videre.

Med disse valgene prøver Next.js å gjøre navigeringen mer forutsigbar. Jeg synes skillene også gjør det enklere å vite hvilket verktøy man skal bruke når.

TanStack Table v9

I TanStack-leiren har vi også sett en stor lansering. TanStack Table har nemlig kommet til versjon 9, over fire år siden v8. TanStack Table forenklerer det å lage avanserte tabeller, ved å gi logikk for sortering, filtrering og paginering. Det er også rammeverksagnostisk, så det kan brukes enten du er på React, Vue eller en av mange andre web-teknologier.

tanstack.com

Announcing TanStack Table V9 | TanStack Blog

TanStack Table V9 is here with a tree-shakable feature architecture, fine-grained reactivity, improved performance, and first-class support ...

Det lange oppholdet skyldes blant annet at nye utviklere har tatt over prosjektet fra Tanner Linsley. Tanner og resten av TanStack-gjengen har i mellomtiden hatt nok å gjøre med blant annet Next.js-utfordreren TanStack Start, som nå har kommet til Release Candidate-steget. TanStack Table har også fått oppgraderinger under panseret, så nye funksjoner blir mye enklere å legge til, så v10 forhåpentligvis opp før 2030.

Hele Table-pakken har vokst fra 14 kB til 25 kB. Ingen hårreisende størrelse. Til sammenligning er axios på 17 kB. Samtidig støtter v9 også tree-shaking, som betyr at om du kun bruker funksjonalitet for filtrering, shippes ikke funksjonalitet for sortering og paginering også til brukeren. Så i praksis vil biblioteket ofte være mye mindre enn fulle 25 kB.

V9 har også blitt kjappere. Et av tiltakene for dette har vært å bruke "shared prototypes" for flere elementer. Så istedenfor at celler, rader og header skal duplisere felles metoder, kan de bli gjenbrukt. I TanStacks tester brukte v9 opptil 86 prosent mindre minne enn v8. Dette gjør at sluttbrukeren opplever enda raskere filtrering og sortering, særlig på gigantiske tabeller.

Reaktivitet i TanStack Table

En annen interessant endring er at TanStack Table nå bruker TanStack Store for tilstandshåndtering. TanStack Store er TanStacks eget rammeverksuavhengige, signal-baserte tilstandsbibliotek. Signals er fortsatt i alpha, så at TanStack bruker biblioteket selv vil avdekke mye rusk før det nærmer seg en lansering.

Mens tilstand i React (som useState) fungerer ved at en endring fører til at komponenten som eier tilstanden rendres på nytt, kan signals holde styr på hvilken kode som leser en bestemt verdi, og bare varsle denne når verdien endres. Endres hvilke rader som er valgt, trenger ikke søkefeltet å oppdatere seg. Det kan bety færre unødvendige oppdateringer i grensesnittet.

Signals var ikke det åpenbare valget. TanStack Table startet som react-table, og var derfor bygget rundt Reacts måte å håndtere tilstand på. For å bli ordentlig rammeverksagnostisk måtte tilstanden i stedet kunne kobles til reaktiviteten i alt fra React til Vue og Solid. Om du er mer nysgjerrig på hvordan de konkret løste dette, har Riccardo Perra skrevet et interessant dypdykk her:

tanstack.com

Inside TanStack Table V9 Reactivity | TanStack Blog

TanStack Table V9 moves state and options behind reactive primitives so updates stay within the scopes that consume them. Here is the path ...

👋 Det var alt for denne gang. Ha en riktig fin uke!