Frontend-utviklere for raske og tilgjengelige grensesnitt

Frontenden er der kundene møter deg. Det er her de bestiller, logger inn og bestemmer seg for om de stoler på deg. Under fargene og animasjonene ligger ytelse, tilgjengelighet og kode som skal tåle mange år med endringer.

Frontend-utviklerne våre bygger brukergrensesnitt i React, Vue og TypeScript, og alle har over ti års erfaring. Vi holder oss til etablert teknologi, slik at andre utviklere også kan jobbe videre med koden om fem år.

Hva gjør en frontend-utvikler?

En frontend-utvikler bygger den delen av løsningen som brukerne ser og klikker i, som skjemaer, menyer, tabeller og betalingssteg. Jobben er å gjøre designet om til kode som laster raskt på en treg mobil, fungerer med tastatur og skjermleser og oppfører seg likt i alle nettlesere.

Her betyr erfaring mye. En erfaren frontend-utvikler ser når et skjema vil skape trøbbel på mobil, når en side henter mer data enn den trenger, og når en komponent ikke kan brukes uten mus. Da blir feilene rettet før brukerne merker dem.

Frontend, backend eller fullstack?

Frontend er det som kjører i nettleseren. Backend er det som kjører på serveren, altså forretningslogikk, databaser, API-er og integrasjoner. En fullstack-utvikler jobber i begge lagene.

Trenger du hjelp med et grensesnitt mot et system du allerede har, er det en frontend-utvikler du trenger. Skal det bygges noe nytt fra databasen og opp, er fullstack-utvikling ofte et bedre valg, fordi samme team da har ansvaret for hele flyten. Vi gjør begge deler, og vi har også egne backend-utviklere.

Universell utforming er god butikk

Universell utforming er lovpålagt, men det lønner seg også. I Norge har omtrent 15 til 20 prosent av befolkningen en varig funksjonsnedsettelse. I tillegg kommer alle som bruker løsningen med én hånd på bussen eller leser skjermen i sterkt sollys.

Når vi bygger med god kontrast, støtte for skjermlesere og tydelig tastaturnavigasjon, blir løsningen bedre for alle:

• Bedre SEO: Google leser nettsiden omtrent slik en skjermleser gjør, så kode som fungerer for skjermlesere, er også god for SEO.
• Større marked: Du stenger ikke ute kunder som vil kjøpe av deg.
• Innenfor loven: Kravene til universell utforming gjelder allerede for norske nettsteder, og EUs tilgjengelighetsdirektiv (EAA) gjør dem strengere.

Vi bygger etter WCAG 2.2 AA fra første komponent. Trenger du en full revisjon eller en tilgjengelighetserklæring, har vi egne tjenester for universell utforming.

Ytelse og Core Web Vitals

Google måler brukeropplevelsen med tre tall, Core Web Vitals: hvor raskt hovedinnholdet vises (LCP), hvor raskt siden svarer når brukeren klikker (INP), og hvor mye innholdet hopper rundt mens siden laster (CLS). Trege sider gir dårligere plassering i Google og dyrere annonser, og flere gir opp før de kjøper.

Det meste av ytelsen avgjøres av hvor mye JavaScript nettleseren må laste ned og kjøre. Vi deler opp koden slik at hver side bare henter det den trenger, laster bilder og tunge komponenter først når de trengs, og rendrer sidene på serveren der det gjør at de vises raskere. Tailwind CSS fjerner ubrukt CSS automatisk, så filene holder seg små.

Nettstedet du leser nå, har 100 i alle fire Lighthouse-kategorier. Les hvordan vi gikk fra 90 til 100.

Pragmatisme foran hype

Frontend-verdenen endrer seg fort. I går var det Redux, i dag er det Zustand eller Signals. Vi bruker tid på å skille det som varer fra det som forsvinner, og velger verktøy du kan leve med lenge.

• TypeScript: Typene beskriver hvordan dataene ser ut, så applikasjonen krasjer ikke fordi den fikk tekst der den ventet et tall.
• React eller Vue: De mest brukte rammeverkene i verden. Det er lett å finne folk som kan vedlikeholde koden senere, og du låser deg ikke til en nisje.
• Tailwind CSS: Styling som er enkel å vedlikeholde, med små filer i produksjon.

Til state bruker vi det enkleste som fungerer. React Query tar seg av data fra serveren, og Zustand eller Redux tar vi først i bruk når grensesnittet har mye delt state. Har du allerede en stack, jobber vi gjerne videre i den.

Next.js, Inertia eller ren SPA?

En klassisk enkeltsideapplikasjon (SPA) med eget API er ofte mer komplisert enn nødvendig. Du må bygge og vedlikeholde et API, håndtere tokens og skrive mye av den samme logikken to ganger.

For interne fagsystemer, kundeportaler og B2B-løsninger bruker vi derfor ofte Inertia.js. Da bygger vi grensesnittet i React eller Vue, men sidene henter dataene rett fra backenden, gjerne Laravel. Erfaringen vår er at vi utvikler funksjoner 30 til 40 prosent raskere på denne måten, med færre feilkilder og lavere vedlikeholdskostnader.

Er nettsiden avhengig av SEO og mye offentlig innhold, bruker vi Next.js med rendering på serveren eller ferdig genererte sider. Skal de samme dataene brukes av en mobilapp eller andre systemer, bygger vi frontenden mot et eget API.

Fra Figma til kode

Et vanlig problem i IT-prosjekter er avstanden mellom det designeren tegner og det utvikleren bygger. Frontend-utviklerne våre jobber direkte i Figma. Vi setter oss inn i designsystemet, variablene og interaksjonene bak skjermbildene, og bruker design-tokens for farger, avstander og skriftstørrelser rett i koden.

Når designeren endrer merkefargen, slår endringen gjennom i hele løsningen på én gang. Merkevaren blir lik overalt, og mindre tid går med til å flytte piksler. Har du ikke et designsystem ennå, kan vi lage et sammen med deg.

Når passer det, og når passer det ikke?

Senior frontend-utviklere lønner seg når grensesnittet er viktig for virksomheten, for eksempel en kundeportal kundene bruker hver dag eller et fagsystem de ansatte jobber i hele dagen. Det lønner seg også når kravene til universell utforming eller ytelse er strenge, og når frontenden har blitt for dyr å endre.

Trenger du en enkel nettside med mye redaksjonelt innhold, er et eget React-grensesnitt ofte mer enn du trenger. Da passer WordPress ofte bedre, og der hjelper vi også gjerne til.

Hva koster en frontend-utvikler?

Timeprisen starter på 1 500 kr. Du kan leie oss per time til løpende utvikling, eller vi tar et avgrenset prosjekt til fastpris når omfanget er tydelig.

Hva et frontend-prosjekt koster, avhenger mest av tre ting: hvor mange ulike skjermbilder og komponenter løsningen har, om det finnes et ferdig design og designsystem, og hvor mye som skal kobles mot backend og andre systemer. Etter en kort kartlegging får du et estimat, så du vet hva du får før vi begynner.

Overtakelse og modernisering

Mange har en frontend som er noen år gammel, der hver endring tar lengre tid enn den burde. Da starter vi med en gjennomgang. Vi måler ytelse og tilgjengelighet, leser koden og ser på avhengighetene, og gir deg en prioritert liste over hva som bør gjøres. Listen kan du bruke uansett hvem som gjør jobben.

Vi skriver sjelden alt på nytt. Som regel bytter vi ut én del av grensesnittet om gangen, med tester rundt det viktigste, slik at brukerne får forbedringene underveis og slipper å vente på en stor lansering om et år.

Slik sikrer vi kvaliteten

Koden skal være like lett å endre om fem år som i dag. Derfor har vi noen faste vaner:

• Tester: Jest og React Testing Library for komponentene, Playwright for de viktigste flytene fra start til slutt.
• Fast kodestil: ESLint og Prettier, så koden ser lik ut uansett hvem som skrev den.
• Mobil først: Alt bygges for små skjermer først og testes på ulike enheter og nettlesere.
• Kodegjennomgang: En annen seniorutvikler leser koden før den går i produksjon.

Alle hos oss har over ti års erfaring. Du får ingen juniorer på prosjektet og slipper overleveringer underveis.

Stacken vår

Dette er verktøyene vi bruker i de fleste frontend-prosjektene, lag for lag.