Ensidesapplikation (SPA)

Vad webbläsaren faktiskt får

Servern skickar en nästan tom HTML-fil – ofta inte mycket mer än <div id="root"></div> och en scripttagg – plus ett JavaScript-paket. Paketet startar, läser adressen, renderar rätt vy i den tomma diven och tar över webbläsarens history-API så att ett klick på en länk byter adress utan att hela sidan laddas om.

Det ger verkliga fördelar. Navigeringen känns omedelbar eftersom bara data flyttas, inte ett helt dokument. Tillståndet överlever mellan vyerna, så ett halvifyllt formulär eller en öppen sidopanel nollställs inte. Det är den naturliga arkitekturen för allt som beter sig som ett program snarare än som ett dokument: instrumentpaneler, redigerare, bokningsflöden.

Kostnaderna som underskattas

Ingenting finns förrän JavaScriptet körts. Första utritningen fördröjs av nedladdning, tolkning och körning av paketet, vilket är skälet till att ensidesappar så ofta har svag Largest Contentful Paint på mellanklassmobiler.

Sökrobotar och AI-hämtare kan få se den tomma diven. Google kör JavaScript, förr eller senare och med en budget. Många andra – de flesta språkmodellers crawlers, botar som gör länkförhandsvisningar, vissa sociala tjänster – hämtar rå HTML och kör aldrig något skript. Finns innehållet bara efter rendering är sidan tom för dem. Den vanliga lösningen är prerendering eller serverrendering av de sidor som ska hittas.

Routing måste hanteras på servern också. En direktlänk till /priser ger 404 om inte webbservern är inställd på att servera index.html för okända sökvägar.

Missuppfattningen

"Ensides" beskriver hur appen levereras, inte hur den ser ut. En ensidesapplikation kan ha hundra olika adresser och vyer – poängen är att de skapas i webbläsaren i stället för att hämtas som separata dokument. Omvänt är en webbplats med en enda fysisk sida och ingen routing inte det någon menar med en SPA.