Vite skal være 10 til 30 ganger raskere

Dette var uken for burritoer 🌯, snakkende hunder 🦮 og sunn jobbkultur 🤝 — og 1538 ting som skjedde i frontend-verdenen

Vite 8 ute med en Rust-basert bundler 🏎️

Vite 8 er nå offisielt stabilt, og den største nyheten er at Rolldown erstatter det tidligere todelte oppsettet med esbuild og Rollup.

Tidligere brukte nemlig Vite esbuild under utvikling, og Rollup til produksjonsbygg. Esbuild kompilerte raskt, som ga god utvikleropplevelse fordi endringer i koden ble reflektert nesten umiddelbart i nettleseren. Rollup var treigere, men produserte mer optimaliserte produksjonsbygg.

Dette fungerte lenge, men skapte etter hvert mer hodepine enn det var verdt. Plugins som virket for esbuild, virket ikke nødvendigvis for Rollup uten mye jobb fra Vite-teamet. Tidvis kunne det også føre til forskjeller mellom utviklings- og produksjonsbygg.

Derfor har Rust-baserte Rolldown blitt den nye bundleren i Vite 8. Ytelsesmessig er den 10-30 ganger raskere en Rollup, og dermed sammenlignbar med esbuild. I tillegg støtter den det samme plugin-økosystemet som Rollup og Vite.

Dette føyer seg inn i en tydelig trend der flere utviklingsverktøy skrives i Rust for å gi merkbare ytelsesfordeler. Generelt virker oppdateringen som et steg i riktig retning for Vite.

Vite 8.0 is out!

MIT-lisensiert Vite+ er ute i alfa 🛠️

I kjølvannet av Vite 8 har VoidZero sluppet en større pakke med utviklingsverktøy, Vite+. I stedet for å sy sammen Vite, Vitest, ESLint, Prettier, task runners og mer, får vi nå ett CLI som håndterer alt.

At mye av stacken er skrevet i Rust gjør ytelsen merkbart bedre. Linting med Oxlint kan være 50–100 ganger raskere enn ESLint, formattering med Oxfmt opptil 30 ganger raskere enn Prettier, og som nevnt tidligere vil bygging av produksjonsbygg kunne være flere ganger raskere i den nye Vite-versjonen som følger med Vite+.

En gledelig nyhet er at Vite+ er MIT-lisensiert med åpen kildekode, noe som gir lav terskel for å ta det i bruk. Det reduserer nemlig risikoen for vendor lock-in, og lar deg forke og tilpasse verktøyet selv hvis det skulle gå i en retning du ikke liker.

Sjekk det ut her 👇

Announcing Vite+ Alpha

CSS-baserte scroll-animasjoner 🎨

I 2023 introduserte Google Chrome scroll-drevne animasjoner, altså animasjoner som kjører i takt med scrollingen. Forrige uke kom Chrome 146 med en etterfølger; nemlig scroll-utløste animasjoner.

Hva er egentlig forskjellen? Scroll-drevne animasjoner er direkte knyttet til scroll-posisjonen. Scroller du ned, spilles animasjonen frem. Scroller du opp, reverseres den.

Scroll-utløste animasjoner er animasjoner som starter idet et element krysser en bestemt scroll-posisjon, og de vil fullføre uavhengig av om du fortsetter å scrolle. Slike animasjoner brukes ofte til å tone inn innhold når det først dukker opp på siden.

Tidligere løste vi dette ved hjelp av IntersectionObserver-APIet i JavaScript:

// Elementet vi ønsker å observere
const observertElement = document.querySelector(".element");

// IntersectionObserver tar inn en funksjon som kjører 
// når et observert element overlapper med viewporten
const observer = new IntersectionObserver((observerteElementer) => {
  observerteElementer.forEach((element) => {
    if (element.isIntersecting) {
      console.log("Det observerte elementet er synlig!");
    }
  });
});

// Vi registrerer det observerte elementet
observer.observe(observertElement);

Med CSS trenger vi 3 ting. Først og fremst må vi definere animasjonen vår.

animation: unclip 0.35s ease-in-out both;

Nå utløses animasjonen rett etter at siden laster inn. Vi vil endre dette så den utløses når brukeren blar ned til det animerte elementet.

/* timeline-trigger: ; */ timeline-trigger: --t view() entry 100% exit 0%;

Chrome 146 lar oss definere en såkalt timeline-trigger, her med navnet --t. Med view() kan vi utløse animasjonen basert på når det animerte elementet krysser grensen til viewporten i nettleseren. Til slutt sier vi at animasjonen skal starte når elementet er fullstendig inne i viewporten (entry 100%) og slutte akkurat idet det begynner å forlate viewporten (exit 0%).

Til slutt kan vi få animasjonen til å bruke --t ved hjelp av den nye animation-trigger-regelen.

animation-trigger: --t play-forwards play-backwards;

Og vipps, så har vi erstattet IntersectionObserver-APIet med 3 linjer CSS. Men spiller det egentlig noen rolle?

Å flytte styling ut av JavaScript og inn i CSS kan gi store utslag i ytelsen. JavaScript kjører nemlig på hovedtråden i nettleseren. Bruker du JavaScript til å regne ut styling, så kan du altså ikke kjøre annen JS-kode samtidig. Dette er ugunstig i en verden full av JavaScript-baserte frontend-rammeverk. Deler av CSS-rendringen gjøres også på hovedtråden, men akkurat scrolling delegeres til andre tråder. Det betyr at CSS-baserte scroll-animasjoner vil kunne være mindre belastende for web-applikasjoner. Google har tidligere forsket på effekten av å skrive om scroll-drevne animasjoner fra JavaScript til CSS, og fant at CPU-forbruket i enkelte tilfeller gikk ned fra 50% til bare 2%.

Det er altså ikke så rart at det har blitt populært å skrive seg bort ifra JavaScript-drevet styling. Scroll-utløste animasjoner blir veldig mye brukt på moderne nettsider, og det er godt å se at CSS utvikles i retning av det som faktisk er populært, med en ytelsesboost på kjøpet.

New in Chrome 146 | Blog | Chrome for Developers

Hotkeys har blitt enda hottere 🔥

Forrige uke tok Kyle Cook, kjent for YouTube-kanalen Web Dev Simplified, en gjennomgang av Tanstacks nye hotkey-bibliotek!

Biblioteket, som foreløpig er i alfa, abstraherer bort mye logikk som er nødvendig for å gi en god brukeropplevelse. For eksempel støtter det Mod-tasten som endrer seg til Ctrl eller Cmd avhengig av om man er på henholdsvis Windows eller Mac. I tillegg har det støtte for sekvenser, som betyr at du for eksempel kan trykke på G-tasten to ganger for å utløse en handling.

Alle hotkeys er også konfigurerbare med flere alternativer. Ett som høres spesielt nyttig ut er requireReset som gjør at hotkey-kombinasjoner kun blir utløst én gang, og for å utløse de igjen må man først slippe alle tastene.

Et annet merkverdig alternativ er ignoreInputs, som skrur av hotkeys mens brukeren skriver i et input-felt. Dette virker jo helt åpenbart når man leser det, men jeg hadde nok aldri kommet på at det var lurt hvis jeg skulle ha begynt å implementere hotkeys selv.

Så selv om du ikke har tenkt å bruke biblioteket kan det altså være lurt å lese gjennom dokumentasjonen, for kanskje finner du noe du ikke har tenkt på, som vil gjøre hotkey-brukeropplevelsen på nettsiden din et ørlite grann bedre 🤏