Derfor snakker alle om Metas StyleX

Et nytt KI-vennlig alternativ til CSS, et nytt browser-API i React og TanStack + Vercel = sant, i ukas ForrigeUke.

Publisert

< ForrigeUke />

ForrigeUke er en artikkelserie som oppsummerer hva som skjedde i frontend-verden i uka som var. Innleggene skrives av frontend-faggruppene til Bekk, og kan også følges på bekk.no/fag.

Dette var uka for kraftig komprimering og trafikklys-drevet-utvikling - og 1108 ting som skjedde i frontendverdenen!

Nytt API i React: browser ✨

I kommende React-versjon 19.3 kommer et nytt API som lar deg markere en komponent som browser-only. Dette er nyttig ved server-rendring, hvor du kjører kode først på serveren og så i nettleser.

Server-rendring kan være utfordrende når du vil kjøre funksjoner som bare fungerer i nettleser, som localStorage.getItem(). Gamlemåten har vært å sjekke for om window eksisterer. Om window ikke fins, vet du at du er på serveren, og unngår å kjøre nettleser-kode på serveren.

Men nå kommer altså React med en mer eksplisitt funksjon:

import { use, useState } from 'react';
import { browser } from 'react-dom';

export function SavedDraft() {
  // 👇 Komponenten blir ikke vist utenfor en nettleser
  use(browser('The saved draft is stored in localStorage.'));
  
  const [draft] = useState(() => localStorage.getItem('draft') ?? '');
  return <DraftEditor initialDraft={draft} />;
}

For å bruke browser-API-et må komponenten være en klientkomponent innen en Suspense-grense. Det er use(), som vi ser over, som leser av verdien og aktiverer Suspense-grensen.

Ved å bruke en Suspense-grense har vi også fordelen av å vise en fallback frem til komponenten er klar i nettleseren:

// SavedDraft.tsx
'use client';
// ☝️ Marker komponenten som klientkomponent

export function SavedDraft() {
	//...
}

// App.tsx
export function App() {
  return (
      {/*
      👇 Komponenten må være inni en Suspense-grense
      */}
      <Suspense fallback={<p>Loading draft...</p>}>
        <SavedDraft />
      </Suspense>
  );
}

browser-API-et er fortsatt i eksperimentell versjon (canary), men snart får vi kanskje mer forutsigbarhet mellom klient og server:

browser-API-et skal forhåpentligvis fikse den irriterende feilen hvor markup på server og nettleser er ulik.

AI-vennlig alternativ til CSS 🎨

Idet jeg trodde styling-diskusjonen var død, har et annet CSS-verktøy dukket opp: Meta sitt StyleX.

Det har fått fart nå etter Cursor skrev om fra Tailwind til StyleX og at Meta selv har opensourcet designsystemet Astryx. StyleX legger enda tydeligere begrensninger på hvordan styling skrives, noe som kan gjøre at kodeagentene forstår koden bedre.

La oss sammenligne med noen kodeeksempler, først med Tailwind:

<button
  className="rounded-full bg-emerald-700 px-4 py-2
             text-white hover:bg-emerald-800
             sm:px-5"
>
  Lagre
</button>

Og her med StyleX, hvor du definerer et stil-objekt:

const styles = stylex.create({
  button: {
    borderRadius: 999,
    backgroundColor: {
      default: '#0f8b6d',
      ':hover': '#0b6b54',
    },
    paddingInline: {
      default: 16,
      '@media (min-width: 40rem)': 20,
    },
    paddingBlock: 8,
    color: 'white',
  },
})

<button {...stylex.props(styles.button)}>
  Lagre
</button>

StyleX skiller seg ut fra andre stylingverktøy. CSS Modules, som har vært min preferanse, har en deilig enkelhet og nærhet til vanlig CSS, bare med klassenavn som er lokale til CSS-filen. Tailwind, som fikk medvind etter at agent-produsert kode kom på banen, har en stylingmodell med forhåndsdefinerte klasser som har stort sett samme spesifisitet.

StyleX strammer inn stylingen ytterligere ved å definere stylingen som JavaScript-objekter. Objektformatet og kompileringen gjør konflikter mer forutsigbare, i stedet for at CSS-kaskader fra andre deler av appen plutselig blander seg inn.

Innstrammingen skal være en fordel i større applikasjoner og designsystemer, men skal også være nyttig når du jobber med agenter. En agent kan lettere forholde seg til eksplisitt styling og JavaScript-logikk i én komponent enn til CSS-regler som er spredt rundt i applikasjonen. Lovordene er fristende, så det blir spennende å se om StyleX blir det neste store stylingverktøyet vi blir å bruke.

Om du er nysgjerrig på hvordan StyleX egentlig fungerer, ta en titt på dypdykket i denne bloggposten.

TanStack + Vercel = sant ❤️

Jeg må visst slutte å kalle TanStack Start “konkurrenten” til Next.js, for nå har nemlig Vercel gått inn som partner for TanStack.

Dette har de feira ved å lage en guide for hvordan du kan deploye TanStack Start til Vercel.

Med en gratisplan som har vært nok for meg, har Vercel vært min go-to plattform å deploye til når det kommer til hobbyprosjekter. Samtidig har jeg hørt det har vært trøblete for annet enn Next.js-applikasjoner. Dermed er det gledelig at Vercel nå skal gi et førsteklasses hjem for TanStack Start.

Det er nå få steg som skal til for å deploye TanStack Start til Vercel. Du trenger stort sett bare å legge til Nitro Vite-plugin, som gir Vite-appen serverfunksjonaliteten den trenger, som SSR og middleware:

// vite.config.ts
import { nitro } from "nitro/vite";

export default defineConfig({
  plugins: [tanstackStart(), nitro(), viteReact()],
});

For fem år siden ansatte Vercel Svelte-skaper Rich Harris, slik at han kunne jobbe fulltid med Svelte. Forhåpentligvis gir partnerskapet med TanStack den samme effekten: mindre tid på sponsorjakt og mer tid til å videreutvikle verktøyene.

TanStack Start, også etter partnerskapet, fortsetter å være et alternativ til Next.js. Men TanStack har også en hel haug med andre verktøy som begge parter kan dra nytte av.

Jeg er nysgjerrig på hvordan TanStack Start utvikler seg nå med Vercels støtte

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

Foretrekk oss i Google Discover

Ved å legge oss til som foretrukket kilde i Google vil du blant annet få opp flere av sakene våre i Google Discover. Tusen takk for støtten!

Foretrekk oss 😻
Bygget med Labrador CMS