Valg av rammeverk er en av de beslutningene kunder sjelden har en mening om, og med god grunn. Det er vår jobb. Men det er verdt å vite hvorfor vi lander der vi gjør, fordi det påvirker hva løsningen koster å endre om to år.
Vi bygger webapplikasjoner med React og Next.js. Ikke fordi det er nyest, men fordi kombinasjonen løser tre problemer som ellers er dyre å løse på egen hånd.
Problemet med å sende alt til nettleseren
En rendyrket React-app sender hele applikasjonen til nettleseren, som så bygger opp siden. Det fungerer greit for et internt verktøy, men har to konsekvenser som betyr mye for offentlige sider.
Den første er at brukeren ser ingenting før koden er lastet ned og kjørt. På god forbindelse er det knapt merkbart. På mobil med middels dekning er det forskjellen på at siden føles rask eller treg.
Den andre er at søkemotorer i utgangspunktet får en tom side. Google klarer i mange tilfeller å kjøre koden og se innholdet likevel, men det er ikke noe man bør basere synligheten sin på.
Next.js løser begge ved å gjøre arbeidet på serveren først. Nettleseren mottar ferdig HTML som vises umiddelbart, og gjør den deretter interaktiv. Brukeren ser innhold med én gang, og søkemotorene ser nøyaktig det samme som brukeren.
Hva dette betyr for synlighet
Dette er den mest konkrete gevinsten for de fleste kunder. En løsning der innholdet leveres ferdig fra serveren, kan rangere i søk på samme måte som en tradisjonell nettside.
Det betyr at dere kan bygge produktsider, artikler og landingssider inne i den samme applikasjonen som resten av tjenesten, framfor å ha en separat nettside ved siden av. Én kodebase, ett design, ett sted å gjøre endringer.
For en bedrift som lever av å bli funnet, er dette ofte det avgjørende argumentet. Vi har skrevet mer om hvorfor synlighet betyr så mye i fem tips for bedre SEO.
Hvor det passer best
Kundeportaler og selvbetjeningsløsninger er kanskje det vanligste. Kunder logger inn, ser sine egne data, gjør endringer og laster ned dokumenter. Her trengs både god ytelse for innloggede brukere og søkbare sider for dem som ennå ikke er kunder.
Administrasjonsgrensesnitt er det andre. Når en bedrift har en mobilapp, trengs nesten alltid et sted å håndtere innhold, brukere og innstillinger. Det bygges best som webapplikasjon, fordi de som bruker det sitter ved en skjerm uansett.
Nettbutikker og innholdstunge sider passer godt fordi ytelse og søkbarhet begge betyr penger.
Og interne verktøy som skal erstatte regneark og manuelle rutiner, der behovet er skjemaer, oversikter og arbeidsflyt framfor noe telefonen kan.
Når det er feil valg
Skal dere ha en enkel presentasjonsside med noen få undersider som sjelden endres, er dette overkill. Det finnes enklere måter å lage en god nettside på, og de er både rimeligere og lettere å overta for noen andre senere.
Skal løsningen brukes offline, bruke kamera aktivt, eller sende pålitelige push-varsler, hører den hjemme i en app. Vi har gått gjennom den avveiningen i app eller nettside.
Og har dere allerede et team som kan noe annet godt, er det som regel riktigere å bygge på den kompetansen enn å innføre noe nytt dere må leie inn hjelp for å vedlikeholde.
Samme språk på tvers av app og web
En praktisk fordel som betyr mer enn den høres ut som: React Native, som vi bygger mobilapper med, bruker samme språk og mange av de samme tankemåtene som React på web.
Det betyr at det samme teamet kan jobbe på begge, at logikk kan deles mellom app og webløsning, og at dere ikke trenger to adskilte kompetansemiljøer for å vedlikeholde en plattform som finnes både på mobil og i nettleseren.
For en bedrift som skal eie løsningen over tid, er det en reell besparelse.
Fallgruvene vi ser
Den vanligste er å bygge alt som en innlogget applikasjon, og så oppdage at ingenting av innholdet kan finnes i søk. Tenk gjennom tidlig hva som skal være åpent og hva som skal være bak innlogging.
Den nest vanligste er å hente for mye data. Rammeverket gjør det enkelt å be om alt på en gang, og en side som laster tusen rader for å vise ti, blir treg uansett hvor god teknologien er.
Og så er det avhengigheter. Det er lett å installere en pakke for hver lille ting, og hver pakke er noe som må oppdateres og som kan slutte å vedlikeholdes. Vi holder listen kort med vilje.
Hva du bør spørre om
Uansett hvem som bygger løsningen deres, er det tre spørsmål verdt å stille. Blir innholdet synlig for søkemotorer? Hvem eier koden når prosjektet er over? Og hva kreves for å vedlikeholde dette om to år, hvis vi skal gjøre det selv eller med noen andre?
Vil du diskutere en løsning? Se hvordan vi jobber med webapplikasjoner, regn på omfanget i priskalkulatoren, eller ta kontakt.