Er du en frontender? Da er det på tide å ta noen grep

La oss være ærlige. Frontend er ikke lenger hva frontend pleide å være. Det er lettere og mer krevende på samme tid. Og vi trenger å endre oss.

Frontend pleide å være et spesialistfag

Da jeg startet som utvikler, hos Bring i 2013, var det ikke lett å være frontend-entusiast. Vi hadde én stor CSS-fil som vi tullet med var “append only”, vi hadde store porsjoner med jQuery-spaghetti og frontendkode i både JavaScript, CoffeeScript og JSP. Det var en hverdag med fulle regresjonstester, ukjente biblioteker og en konstant leting etter dokumentasjon.

Det var mange grunner til at verden var som den var, men noen av de grunnene jeg gjenkjenner i retrospekt var disse:

Umoden teknologi

Frontend-teknologi anno 2013 var… kaotisk. Det dukket opp nye biblioteker og rammeverk nærmest ukentlig, og ingen visste vel egentlig hvilke man burde satse på. Mange team endte opp med å velge teknologier som senere viste seg å være blindspor, og de måtte ofte gjøre store omskrivninger av kodebasen sin. Jeg har vært med på en bråte av dem opp gjennom.

Dette teknologilandskapet gjorde at man i stor grad måtte plassere “bets” på forskjellige teknologier, basert på hvor mye du stolte på folka bak. Av og til stemte det (React) og av og til stemte det ikke (Angular). Det var ikke lett, skal jeg si deg!

Gamle nettlesere som ikke oppdaterte seg selv

Mye av hverdagen som frontender i gamle dager gikk med på å håndtere nettleser-kompabilitet. Mange av problemene i produksjon stammet fra at brukere satt med utdaterte nettlesere, og hver nettleser hadde sine egne quirks som måtte håndteres. Jeg har fortsatt mareritt om å spinne opp en egen VM for å verifisere at ting fungerte (eller ikke) i IE7.

Dette skapte et behov for å være sabla god i alle de små triksene og hackene som trengtes for å få ting til å fungere på tvers av nettlesere. Man måtte også ha en inngående kunnskap i hvordan forskjellige nettlesere tolket og rendret HTML og CSS forskjellig, og hvordan man kunne skrive kode som fungerte overalt. Og å huske på alle de sabla nettleser-spesifikke prefiksene… -webkit-grøss.

Dårlig verktøystøtte

Man hadde heller ikke noen særlig gode verktøy. Vi hadde ingen typesikring, testing var komplisert å sette opp og vedlikeholde, og verktøyene vi hadde var trege siden de var implementert i JavaScript. Webpack, for de som husker det, krevde omfattende konfigurasjon for selv de enkleste oppsett. Eller Gulp. Eller Grunt, for den saks skyld.

Dette betydde at frontend-utviklere måtte være eksperter på byggsystemer og verktøykonfigurasjon. De måtte forstå hvordan bundlere fungerte på et dypt teknisk nivå, og kunne debugge problemer i build-pipelinene våre på Jenkins. Dette var liksom nok en ting som krevde at du virkelig forstod hvordan ting funka – eller i alle fall var flink til å finne ut av det kjapt.

Manglende dokumentasjon og læringsressurser

Dokumentasjon var ofte mangelfull eller ikke-eksisterende. Man måtte ofte dykke ned i kildekoden til bibliotekene man brukte for å forstå hvordan de faktisk fungerte.

Det var også en påfallende mangel på gode læringsressurser. De få tutorialene som fantes var korte, fulle av feil, og stemte mest sannsynligvis ikke med den versjonen som du jobba med akkurat da.

Dette skapte et miljø hvor frontend-utviklere måtte være eksepsjonelt selvstendige og ressurssterke. Du måtte kunne lese og forstå kompleks kildekode, og ofte bygge din egen forståelse gjennom prøving og feiling.

I dag har frontend blitt et fag for generalister

Hvis du spoler fremover sånn 10–12 år, så er situasjonen vi står i som frontendutviklere ganske annerledes. Frontend har blitt profesjonalisert, og har blitt både iterert på og investert i av noen av de flinkeste i bransjen over en årrekke.

Vi har fantastiske verktøy

Typesikring har (heldigvis) blitt en slags standard i frontend-utvikling, og TypeScript har virkelig revolusjonert hvordan vi skriver og vedlikeholder kode. Ikke bare fanger vi feil tidligere, men typesystemet fungerer også som levende dokumentasjon som hjelper utviklere å forstå kodebasen raskere. Og ikke minst slipper vi å skrive så mange tester, som vi igjen slipper å vedlikeholde 😅

Byggverktøyene har også kommet milevis siden jeg startet. Byggverktøyene har blitt skrevet om fra JavaScript til Rust, og har fått nyttige defaults som gjør at man ikke lenger trenger å konfigurere så mye (eller i mange tilfeller, noe som helst). Det gjør at bygget ditt skjer på sekunder istedenfor minutter, og du slipper å holde presentasjoner for kollegaene dine om hvordan du best setter opp code-splitting med vendor bundles. For eksempel.

I de fleste tilfellene har jeg egentlig ikke noe forhold til bygg-verktøyet i det hele tatt — det bare funker. Vi har hot-reloading, som gjør at du ikke mister tilstand mellom hver CSS-endring, vi har Tailwind som gjør det enkelt å skrive konsekvent CSS, og vi har nok innebygd funksjonalitet i rammeverkene vi bruker til at vi kan glemme hvordan ting som Redux egentlig funker.

Vi har selv-oppdaterende nettlesere

Husker du nettleser-bugs? Hvis ikke, så misunner jeg deg. I dag er de er så godt som eliminert fra hverdagen vår! Moderne nettlesere oppdaterer seg selv automatisk, og nye funksjoner rulles ut kontinuerlig uten at du nødvendigvis trenger å tenke på det. Chrome, Firefox og Safari har alle adoptert denne modellen, og selv om du fortsatt hører surmaga oppstøt om at “Safari er den nye IE8”, så kan vi nok alle være enige om at Safari ikke er den moderne ekvivalenten til IE8. It just ain’t.

Dette har jo egentlig endret hvordan vi tenker på nettleser-kompatibilitet. Der vi før måtte være eksperter på hver nettlesers særegenheter og begrensninger, kan vi nå stole på at standarder følges og at nye funksjoner blir tilgjengelige automatisk. Dette har fjernet et helt lag av kompleksitet fra frontend-utvikling.

Vi har endelig konsensus rundt rammeverk

Der vi før hadde et nytt fett frontend-bibliotek hver uke, har markedet nå stabilisert seg rundt noen få, velprøvde alternativer. React, Vue og Svelte har eksistert i mange år og har modne og stabile APIer. Dette fører ikke bare til at vi slipper å lære oss nye ting hele tiden, men vi kan også fokusere på å bli skikkelig gode i den eller de teknologiene vi velger å fokusere på.

Spesielt i Norge ser vi at React har blitt en de facto standard for nye prosjekter. Dette betyr at utviklere kan fokusere på å bli virkelig gode i ett rammeverk, istedenfor å måtte være eksperter på mange. Det betyr også at det er lettere å flytte mellom prosjekter og team, siden kompetansen er mer overførbar.

Vi har designsystemer 🎉

Det å utvikle frontend i dag handler i stor grad om å bruke eksisterende komponenter. Der vi før måtte implementere hver knapp, hvert input-felt og hver modal fra bunnen av, har vi nå robuste designsystemer som gir oss disse komponentene (forhåpentligvis) ferdig testet og dokumentert.

Organisasjoner bygger sine egne designsystemer som kan brukes på tvers av team. Dette har ikke bare økt utviklingshastigheten, men har også gjort det enklere å vedlikeholde konsistent design og brukeropplevelse på tvers av produkter. Når en bug fikses i designsystemet, fikses den nokså automatisk i alle applikasjoner som bruker komponenten.

Selv det å lage designsystemer har blitt enklere. Der vi før ofte skrev alt fra bunnen av, finnes det nå en håndfull med “hodeløse” komponentbiblioteker (react-aria, shadcn/ui og Radix er tre eksempler jeg kommer på), som du kan importere, style som du vil, og shippe til produktteamene dine. De tar høyde for best practice innen universell utforming, så du slipper å dykke altfor dypt ned i “UU-hullet” for å lage ting som er brukbare for folk som ikke kan bruke mus.

Frontend og AI

Det er kanskje litt klisje å melde nå, men jeg har virkelig blitt frelst av hvor enkelt det er å utvikle frontend-kode ved hjelp av generativ AI. På et eller annet plan, har det fundamentalt endra helt hvordan jeg utvikler brukergrensesnitt spesielt, og jobber med både utvikling og debugging generelt.

Kontekstuell kodeforståelse

Når en AI-motor kan se og forstå kodebasen din, kan den komme med relevante forslag til både forbedringer og nye funksjoner. Og her mener jeg ikke bare en fancy autocomplete — moderne AI-verktøy kan forstå arkitekturen i prosjektet ditt og foreslå løsninger som passer inn i den eksisterende kodestilen.

For eksempel kan en AI analysere hvordan du har implementert lignende funksjonalitet andre steder i kodebasen, og foreslå løsninger som aligner med resten av koden din når du ber den implementere en eller annen endring. Den kan også identifisere mønstre i koden din og foreslå refaktoreringer som gjør kodebasen mer vedlikeholdbar.

Økt utviklingshastighet

Selv om tastehastighet ikke er den største flaskehalsen i utvikling, gjør AI det mulig å eksperimentere og iterere raskere enn noensinne. Du kan beskrive funksjonaliteten du ønsker å implementere med ditt naturlige språk, og få forslag til implementasjon som du kan flikke på og tilpasse.

Dette har spesielt stor effekt når du jobber med nye APIer eller biblioteker. Istedenfor å måtte lese gjennom omfattende dokumentasjon, kan AI-en foreslå relevante kodesnutter basert på din beskrivelse av hva du prøver å oppnå, og AI-ens mulighet til å lese og forstå dokumentasjon. Dette reduserer tiden brukt på å lete etter løsninger og lar deg fokusere på å evaluere og tilpasse forslagene.

Forbedret debugging

Debugging har blitt dramatisk enklere med AI-assistanse. Du kan mate AI-en med stack traces og få hjelp til å undersøke GitHub-issues, kildekode og typekontrakter for å finne rotårsaken til problemer. AI-en kan også foreslå potensielle løsninger basert på lignende problemer som andre har løst.

Dette er ekstra nyttig når du jobber med vanskelige utfordringer som involverer flere lag av teknologi. AI-en kan hjelpe deg å forstå hvordan forskjellige deler av systemet interagerer, og hvor i appen din problemet egentlig oppstår (på tross av hva stack tracen din påstår).

Intelligent iterasjon

Har du hørt om AI-agenter? Jeg elsker AI-agenter. I kontekst av frontend-utvikling, så er AI-agenter er basically vanlige språkmodeller som foreslår noe, kjører test-suiten og linteren din, finner sine egne feil og retter dem.

Det sparer deg for å prompte, kjøre, feile, prompte igjen med feilen og få et nytt resultat. Det er helt herlig! Det fungerer ikke alltid, selvfølgelig, men som kompetent frontender så skjønner du som regel hvordan du kan nudge språkmodellen i riktig retning.

Spesialistrollen er ikke lenger like nødvendig

Du ser hva vi trengte å være gode til før? Det trenger vi som regel ikke å være like gode til lenger. Mange av de tekniske utfordringene som tidligere krevde spesialistkompetanse har rett og slett blitt løst. Og det — det betyr at vi kan være gode i andre ting.

Dette betyr ikke at frontend-utvikling har blitt enkelt eller at det ikke krever kompetanse. Men fokuset har skiftet fra dyp teknisk spesialisering til en bredere forståelse av hele utviklingsstacken.

T-formede utviklere

Det vi burde gjøre, som frontendutviklere (som jeg vet, har brukt tusenvis av timer på å lære oss alle disse greiene opp gjennom) er å bredde ut kompetansen vår. Vi trenger å bli T-profiler. En T-profil — om du ikke har hørt om det før — er en fullstack-utvikler som er litt ekstra god på ett område. Det området kan være plattform, sky, sikkerhet, personvern, eller i vårt tilfelle, frontend.

Dette gjør teamene mer fleksible og effektive. Når alle medlemmer har grunnleggende forståelse for hele stacken, reduseres behovet for overleveringer og koordinering mellom forskjellige tekniske fagspesialister.

Unntak fra regelen

Det finnes riktignok fortsatt områder hvor frontend-spesialisering er verdifullt:

Designsystem-team

Designsystem-team trenger fortsatt utelukkende frontend-spesialister. Disse teamene bygger komponenter som skal brukes på tvers av mange applikasjoner og team, og må håndtere en kompleksitet som krever dyp teknisk forståelse. Du må kunne API-design, unngå breaking changes mellom versjoner, og forstå behovene til hele organisasjonen din. SÅ god er ikke AI enda.

Komplekse frontend-applikasjoner

Enkelte produktteam med særlig komplekse frontend-løsninger kan også ha behov for spesialistkompetanse. Dette kan være apper med omfattende datavisualisering, kompleks tilstandshåndtering, eller spesielle krav til ytelse og tilgjengelighet.

Men selv i disse tilfellene ser vi at spesialistene ofte må ha bredere kompetanse enn før, siden moderne frontend-utvikling involverer så mange forskjellige aspekter av systemutvikling. Og med fullstack-rammeverk som Next eller (min favoritt) Remix i bunn, ender man ofte opp med å jobbe med både backender og databaser.

Så, hva burde vi frontendere gjøre?

Hvis du er som meg, så står du foran en ganske stor oppgave. Du må lære deg nye ting, langt utenfor kjernekompetansen din, og du burde gjøre det kjapt.

Det er på tide å tenke bredere enn bare frontend. Du bør ha en grunnleggende forståelse for hele stacken:

Lær deg grunnleggende backend-utvikling. Dette betyr ikke at du må bli en database-ekspert, men du bør forstå:

• Hvordan API-er designes og implementeres
• Grunnleggende databaseoperasjoner og -modellering
• Hvordan man håndterer autentisering og autorisasjon
• Ytelses-optimalisering på serversiden

Få innsikt i moderne utviklingsplattformer:

• Container-teknologier som Docker
• Skyplattformer som AWS, Azure eller GCP
• CI/CD-pipelines og automatisert testing
• Overvåkning og logging av produksjonssystemer

Sikkerhetsbildet blir stadig mer utfordrende, og det begynner å haste litt at du i alle fall innehar en grunnleggende forståelse for:

• Vanlige sikkerhetstrusler i web-apper
• OWASP Top 10 og hvordan man beskytter seg mot disse
• Sikker håndtering av brukerdata og autentisering
• Best practices for sikkerhet generelt

AI er ikke bare et verktøy — det lar deg bli en 10x utvikler over natta! Nå er ikke jeg verdens største AI-ekspert, men ting jeg kommer til å ha fokus på er å:

• Lære meg å skrive effektive prompts som gir deg koden jeg trenger
• Bruke AI til å utforske nye APIer og biblioteker
• Hjelpe meg med debuggingen av prod-issues
• Bruk AI til å forklare meg ting jeg ikke helt skjønner
• Få AI til å reviewe koden min og foreslå forbedringer
• Utforsk nye teknologier med AI som guide

Kroken på døra?

Behovet for frontend-spesialister er ikke lenger det samme som før. Det er kanskje litt trist, men det er også noe som begynner å bli klarere og klarere for meg. Dette representerer både en utfordring og en mulighet for dagens frontend-utviklere.

• Omfavn rollen som generalist
• Utnytt AI til å gjøre deg mer effektiv
• Hold deg oppdatert på moderne verktøy og praksiser
• Finn nisjer hvor din spesialistkompetanse fortsatt gir verdi

Fremtiden tilhører de som kan kombinere bred teknisk kompetanse med effektiv bruk av moderne verktøy og AI. For frontend-utviklere betyr dette å bevege seg bort fra tradisjonell spesialisering og mot en mer fleksibel og helhetlig tilnærming til utvikling.

Så da er det bare å sæla på, da. Jeg gleder meg i alle fall veldig.