Codeberg forbyr vibbekode – mange reagerer

Dette var uken for juks 😾, gjeld 💸, snarveier 🏃 — og 483 ting som skjedde i frontend-verdenen.

Codeberg forbyr vibe-kodede prosjekter🤖

Codeberg er kjent som det europeiske GitHub-alternativet med åpen kildekode. Nylig oppdaterte de sine tjenestevilkår, og la til et forbud mot prosjekter som "hovedsakelig" består av KI-generert kode:

«7. You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as *Claude*, *OpenAI Codex*). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).»

«Advokatten»: – Du får ikke opphavsrett på vibbekode!

– Dette kan sjokkere deg og dine fagfeller, men sånn er det, advarer advokat Kirill Miazine.

Codeberg påpeker at prosjekter laget av enkeltutviklere med KI-agenter klarer å bruke like mye CI/CD- og lagringsressurser som store prosjekter drevet av sammensatte team. De lager spissede produkter som løser et veldig spesifikt problem, og har en særdeles liten brukergruppe. Vibe-kodede prosjekter koster altså mye penger, og bidrar forholdsvis lite til fellesskapet.

I tillegg kritiserer Codeberg effekten som datasentre har på miljøet. Datasentre i Frankfurt bruker for eksempel 40% av den lokale strømforsyningen, og planlegger å bruke fossile energikilder til å dekke et voksende energibehov.

Ifølge bloggposten til Codeberg rammer de nye vilkårene først og fremst autonome KI-agent-prosjekter og repoer med urimelig høyt ressursforbruk i forhold til antall bidragsytere. De er altså ikke ute etter å ta veletablerte prosjekter som av og til godtar et KI-generert bidrag.

Zig vraker GitHub: «Tregt og ofte ødelagt»

– Klokka begynte å tikke da de ble solgt til Microsoft, mener Zig-skaper Andrew Kelley, og mener tida er inne for å gå over til tyske Codeberg.

Likevel har endringen skapt delte reaksjoner. På Hacker News og Lobsters diskuterte folk mest hvor de skal trekke grensen. Teller tung bruk av autocomplete? Hva med IntelliJ sin auto-refaktorering? Det er vanskelig å se for seg hvordan regelen skal håndheves på en rettferdig måte. Selv om Codeberg kommer med noen gode argumenter i bloggposten sin, er selve tjenestevilkårene vagt formulert.

Theo Browne, også kjent som t3.gg, gikk hardt ut mot Codebergs påstand om at KI-agenter kan produsere mer skadelig kode enn mennesker. Han trekker frem at både Claude og Codex har innebygde mekanismer for å hindre at de blir brukt til å produsere skadevare. Dessuten mener han at mange av påstandene i bloggposten er overdrevne, som at datasentre bruker mye vann.

Det blir spennende å se om Codeberg velger å endre formuleringen i tjenestevilkårene sine!

Skaler komponenter med linjehøyder📏

Ahmad Shadeed skrev en hjelpsom artikkel der han promoterer mer aktiv bruk av linjehøyde- (lh-) enheten i CSS.

Si at man har to avsnitt, og man ønsker å definere en vertikal avstand imellom dem. Ofte tyr man kanskje til å definere avstanden i rem, som tar utgangspunkt i rot-elementets (html-taggens) font-størrelse. Men avsnittene kan ha en annen tekst-størrelse enn rot-elementet, og da vil avstanden se unaturlig ut.

Hvis man definerer avstanden som 1lh, blir avstanden knyttet direkte til tekstens egne linjehøyde. Da vil den alltid oppleves proporsjonal og riktig, uansett hvilken skriftstørrelse eller line-height som er satt på elementet.

Et bruksområde han trekker frem, som jeg synes virker spesielt nyttig, er å bruke linjehøyde til å definere størrelsen på ikoner. Da skalerer ikonet automatisk sammen med teksten det står ved siden av, for eksempel i en knapp, i stedet for at man må justere det manuelt hver gang skriftstørrelsen endres.

Les mer om hvordan du kan bruke linjehøyder i bloggposten til Ahmad👇

Cloudflare kjøper Vite: «Alltid litt skummelt»

VoidZero kjøpt opp av Cloudflare, React Compiler skrives om til Rust og State of CSS 2026 har åpnet for innsendinger, i ukas ForrigeUke.

Ikke la deg lure av JSON🤥

I en splitter ny bloggpost viser Gabor Koos hvordan JSON.stringify() og JSON.parse() ofte gir en falsk trygghet. Siden JSON ligner så mye på JavaScript-objekter, er det lett å tro at serialiseringen er tapsfri. Men det er den dessverre ikke.

JavaScript er (på mange måter) ganske sært. For eksempel skiller det mellom undefined og null. Definerte variabler som ikke har fått en verdi enda, får verdien undefined, mens null gjerne brukes for å si at en variabel eksplisitt har fått en tom verdi.

JSON støtter bare null-verdier, så JSON.stringify() - funksjonen for å konvertere et JavaScript-objekt til en JSON-streng - må håndtere undefined på ett eller annet vis. Så hva gjør funksjonen? Fjerner den undefined? Eller konverterer den det til null?

Svaret er "Ja" 🤔

const serialisert = JSON.stringify({
  foo: undefined,
  bar: [123, undefined]
})
// '{"bar": [123,null]}'

undefined fjernes fra objekter, og konverteres til null i lister. Om vi nå konverterer strengen tilbake til et JavaScript-objekt, kommer objektet til å mangle foo, og bar kommer til å inneholde en null-verdi:

const deserialisert = JSON.parse(serialisert)
// {bar: [123,null]}

Det finnes flere eksempler der en slik konvertering kan gjøre at vi mister eller endrer informasjon. JavaScripts spesialverdier som NaN og Infinity blir til null. Date-objekter blir til strenger. Map- og Set-strukturer blir til tomme objekter {}. Serialiserte tall større enn 2^53 - 1 kan bli deserialisert feil, fordi JSON.parse() konverterer dem til Number.

JSON.stringify({foo: NaN}) // '{"foo":null}'

JSON.stringify({date: new Date()}) // '{"date":"2026-08-04T21:57:01.317Z"}'

JSON.stringify({map: new Map([['foo', 'bar']])}) // '{"map":{}}'

JSON.parse('{"foo":12345678901234567}') // {foo: 12345678901234568}

Så hva gjør vi?

Først og fremst mener Gabor Koos at vi alltid bør skille JSON-representasjonen fra klassene våre. Istedenfor å kaste objekter rett inn i JSON.stringify() bør det bygges egne transportobjekter gjennom funksjoner som håndterer alle JSON-særegenheter.

På mottakersiden anbefaler han valideringsbiblioteker som Zod. JSON.parse() sjekker bare syntaks, og TypeScript-typer forsvinner ved kompilering, så det er viktig å validere all JSON som kommer inn i applikasjonen. Men validering redder ikke informasjon som allerede er tapt, så det er viktig å bevare den riktig i JSON-formatet først.

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

Slik jobba VG-utviklerne med dialogen mellom Mette-Marit og Epstein

Google Sheet, JSON og SvelteKit var viktig da VG gjorde alle meldingene mellom kronprinsessen og den dømte sexforbryteren mer lesbare.