Veldig ofte i utviklingsprosjekter velger man å gå for en single page-applikasjon selv om det ikke nødvendigvis gir mening. Selv om man lager sider med mye statisk informasjon som ikke nødvendigvis har noe med hverandre å gjøre samler man alt i en JS-smøle fordi "det er sånn man gjør ting".
Problemet med denne approachen er at man da samler kompleksitet (domene og applikasjon), og dette gjør ting vanskelig å resonnere rundt. I tillegg til at applikasjonsflyten blir vanskeligere å forholde seg til låser man seg også mye mer til teknologivalg.
Backend-teknologi man velger er veldig vanskelig å bytte ut nettopp på grunn av dette (kilde: https://medium.com/sketchdeck-developer-blog/what-i-wish-i-knew-when-i-became-cto-fdc934b790e3). Den store fordelen med frontend-utvikling er at man har så mange muligheter å velge mellom, og "best practices" endrer seg fra uke til uke.
Jo større applikasjoner man bygger i JS-land jo mer låser man seg fast til en applikasjonsstruktur og rammeverk som kanskje ikke lenger er "best practice" (MobX, Cycle.js, Elm) i tillegg til at man samler kompleksitet i store JS-monolitter. Det blir også mye vanskeligere for nye utviklere å sette seg inn i koden.
Man ender også opp med en stor JS-bundle som potensielt kan føre til lange byggetider og lav developer happiness.
Ved å dele opp JS-monolitten din i flere små-apper, som alle dreier seg om sitt eget domene, med sine egne APIer, sin egen store, og sine egne komponenter, gjør man frontend-koden:
- Lettere å resonnere rundt
- Lettere å feilsøke
- Lettere å teste
- Raskere å bygge
Ved å benytte seg av fordelene ved å kjøre i nettleseren (caching, historikk, navigasjon) gjør man også utviklingstiden dramatisk raskere da man ikke trenger 5+ år med React/Redux-erfaring for å kunne bidra. Mindre applikasjoner med mindre avansert arkitektur gjør at overheaden for en ny utvikler blir mindre og han/hun kan bidra mye raskere.
Skal vise slides av hvordan jeg har bygget opp en login-løsning med validering, "glemt passord", 2faktor, lenke til registreringsskjema, og "husk meg"-funksjonalitet med React-komponenter som styres av reaktive strømmer.
Single Page-applikasjoner har selvfølgelig sine fordeler også, og det gir helt klart mening å lage det dersom domenet man opererer i krever high-fidelity app-funksjonalitet. Eksempler er tekstredigeringsprogram, mediaspillere, spill, saksbehandlingssystem med høy cohesion mellom funkasjonalitet.
Jeg ser dog liten grunn til å lage hele nettsiden din som en single page-app dersom det er en nettside du lager. Lag heller flere, mindre SPAer, og knytt de sammen der det gir mening. For eksempel kan en brukerprofil være delt opp i flere SPAer (èn for profildetaljer, èn for e-postinstillinger, èn for avatar-tilpasning) som senere kan kobles sammen med f.eks. React-router.
Deretter kan man ekstrahere state fra de forskjellige appene i en rot-store.