Er JavaScript-animasjoner tregere enn CSS-animasjoner?
CSS vs. JavaScript, komponentarkitektur for React Server Components og npm strammer til forsyningskjeden, i ukas ForrigeUke.
Dette var uken for skygger 🧐, kamuflasje 🫥 og tilbakeblikk 💸 – og 1287 ting skjedde i frontend-verdenen.
CSS eller JavaScript til animasjoner? 📜
Josh Comeau slapp forrige uke en ny artikkel som tar for seg et spørsmål mange har lurt på: Er JavaScript-animasjoner tregere enn CSS-animasjoner?
Svaret er mer sammensatt enn man kanskje skulle tro. Det er ikke utregningen av posisjoner i JavaScript som koster tid, dette gjør nemlig moderne nettlesere på en brøkdel av et millisekund. Forskjellen er at CSS-transitions og keyframes kjører på en egen tråd, mens en requestAnimationFrame-loop kjører på hovedtråden sammen med all annen JavaScript. Når hovedtråden er opptatt med for eksempel React-renders eller parsing av et fetch-svar, hakker JS-animasjonen, mens CSS-animasjonen ruller videre.
Biblioteker som Motion (tidligere Framer Motion) holder seg likevel jevne, fordi de bruker Web Animations API (WAAPI). WAAPI bruker den samme lavnivå-motoren som CSS-keyframes, og havner derfor på en egen tråd. GSAP gjør ikke dette, og kan i tillegg komme ut av synk fordi det flytter elementet like mye per frame i stedet for å holde styr på hvor lang tid som har gått.
Comeau anbefaler ren CSS når det holder, og et bibliotek som Motion når det ikke gjør det. Du kan lese hele artikkelen her 👇
joshwcomeau.com: CSS vs. JavaScript
Komponentarkitektur for React Server Components ⚛️
Aurora Scharff har skrevet om hvordan React Server Components endrer måten man bygger opp en side på. Den vanlige modellen i React har lenge vært å hente data øverst i en route og sende det nedover via props, noe som fort gir tett koblede komponenter og klønete loading-tilstander.
Med RSC kan hver komponent i stedet hente sin egen data på serveren, basert på minimale props, som regel bare en ID. Da blir like enkel å gjenbruke på for eksempel en profilside som på forsiden, uten at siden "over" må vite hva komponenten trenger. Selve siden ender dermed opp som en ren sammensetning av komponenter, mens Suspense-grenser styrer hvordan lasterekkefølgen oppleves.
Hun går gjennom progresjonen fra useEffect til React Query til loaders til RSC, og bygger opp en konkret feed-side i Next.js App Router underveis. Du kan lese hele artikkelen her 👇
aurorascharff.no: Component Architecture for React Server Components
npm strammer til forsyningskjeden 📦
Supply chain-sikkerhet har vært et gjennomgangstema i hele vår, og nylig kom npm med to grep i CLI-versjon 11.15.
Det første er at staged publishing nå er tilgjengelig. I stedet for at en npm publish gjør pakkeversjonen tilgjengelig for alle med en gang, legges den i en kø der en maintainer må godkjenne den med 2FA før den blir installerbar. Det fungerer også for CI/CD-arbeidsflyter og OIDC-basert trusted publishing, og køen er synlig både på npmjs.com og i CLI-en. Du bytter til npm stage publishder du vil ha denne oppførselen.
Det andre er nye flagg for hvor npm install får hente fra: --allow-file, --allow-remote og --allow-directory, i tillegg til det eksisterende --allow-git. Hvert flagg tar enten all (dagens standard) eller none, og kan settes i .npmrc eller package.json. --allow-git får none som standard i neste major-versjon (v12).
pnpm fulgte også opp 11.3, som også støtter staged publishing via pnpm stage, pluss en ny trustLockfile-innstilling. Du kan lese mer om npm-endringene her 👇
github.blog: Staged publishing and new install-time controls for npm
Det var alt for denne gang, ha en fin uke 👋
