Ensideapplikasjon

En **ensideapplikasjon** er en webapplikasjon eller nettside som samhandler med brukeren ved å oppdatere den eksisterende siden dynamisk i stedet for å laste helt nye sider fra en server. Denne metoden eliminerer avbrytelsen av brukeropplevelsen mellom forskjellige sider, og fører til at applikasjonen oppleves mer som en vanlig applikasjonsprogramvare. I en ensideapplikasjon er enten all nødvendig kode (HTML, JavaScript og CSS) hentet gjennom en enkelt sidelasting, eller så blir ressursene dynamisk lastet inn ved behov, normalt som en respons til noe brukeren gjør. Siden laster ikke på nytt under prosessen, men den kan bli kodet for å gi illusjonen av forskjellige sider i applikasjonen. Interaksjon med applikasjonen medfører ofte dynamisk kommunikasjon med nettserveren.

## Historie
Bakgrunnen til benevnelsen *ensideapplikasjon* (engelsk: single-page application) er uviss, men konseptet ble diskutert så tidlig som 2003. Stuart Morris skrev om *the Self-Contained website* på slashdotslash.com med de samme målene og funksjonaliteten i april 2002, og senere samme år beskrev Lucas Birdeau, Kevin Hakman, Michael Peachey and Clifford Yeh en implementering av ensidig applikasjon i US patent 8,136,109.

## Tekniske verktøy
Det er flere tekniske verktøy tilgjengelig som gjør det mulig å benytte bare én side selv om siden trenger kommunikasjon med en server.

### JavaScript-rammeverk
JavaScript-rammeverk for nettlesere, som AngularJS, Ember.js, ExtJS, Knockout.js, Meteor.js, React og Vue.js har tatt i bruk prinsipper for ensideapplikasjoner.

### Ajax
Den vanligste teknikken som blir benyttet er Ajax.

## Utfordringer med ensideapplikasjoner
Fordi ensideapplikasjoner er en utvikling unna den statløse modellen som nettlesere var opprinnelig laget for, har nye utfordringer dukket opp. Hvert av desse problemene har en effektiv løsning med:

* Klient-sidig JavaScript-bibliotek som tar seg av forskjellige utfordringer.
* Server-sidige rammeverk for nett som spesialiserer seg på ensideapplikasjoner.
* Utviklingen av nettlesere og HTML5-spesifikasjonen som er designet mer for ensideapplikasjoner.

### Søkemotoroptimalisering
På grunn av mangelen av JavaScript-utførelse av edderkopper for flere populære søkemotorer, har SEO (Søkemotoroptimalisering, engelsk: Search Engine Optimization) historisk vore et problem for offentlige nettsider som ønsker å benytte modellen med ensidig applikasjon.

Mellom 2009 og 2015, Google Webmaster Central foreslo og anbefalte et «AJAX crawling scheme» ved å benytte et utropstegn for å identifisere seksjoner i AJAX-sider (`#!`).

Fordi søkemotoroptimalisering er utfordrende for ensideapplikasjoner er det verdt å notere seg at ensideapplikasjonene normalt ikke blir brukt i kontekster der søkemotorindeksering er enten et krav eller ønskelig.

Det er et par måter en kan få nettsiden til å oppleves som søkbar. Begge involverer å opprette egne HTML-sider som speiler innholdet av ensideapplikasjonen. Serveren kan da lage en HTML-basert versjon av nettsiden og levere den til edderkoppene, eller så kan en benytte en hodeløs nettleser som PhantomJS til å kjøre JavaScript-applikasjonen og skrive den resulterende HTML-koden.

Begge alternativene krever en del arbeid, og kan ende med å gi mye merarbeid på større, komplekse sider. Det er også noen fallgruver en må passe seg for. Dersom den server-genererte HTML-koden blir tolket som for forskjellig fra innholdet på ensideapplikasjonen, vil siden bli straffet. Å kjøre PhantomJS for å skrive ut HTML-koden kan gjøre responstiden på siden høyere, noe som søkemotorer – særlig Google – vil liste siden din lavere for.

### Nettleserhistorikk
Siden en ensideapplikasjon er, av definisjon, "en enkelt side", bryter siden med den tradisjonelle nettleser sin historikk-navigasjon ved å benytte fram/bak-knappene. Dette utgjør et problem når brukeren trykker på bak-knappen, forventer å komme tilbake til forrige skjermbilde i ensideapplikasjonen, men ender tilbake til den forrige siden som var lastet i nettleseren istedet.

Den tradisjonelle løsningen for ensideapplikasjoner har vært å endre nettleserens URL hash samtidig som skjermbilde endrer seg. Dette kan en oppnå ved bruk av JavaScript, og får historikk-navigasjonen til å fungere. Så lenge ensideapplikasjonen kan gjengi det samme skjermbildet når brukeren da trykker tilbake, vil navigasjonen fungere som ønskelig.

For å videre jobbe med dette problemet, har HTML5-spesifikasjonen introdusert pushState og replaceState som gir programmatisk tilgang til den faktiske URL- og nettleserhistorikken.

### Analyse
Analyseverktøy slik som Google Analytics avhenger sterkt av lastingen av nye sider i nettleseren. Ensideapplikasjoner fungerer ikke på denne måten.

Etter siden er lastet første gang, vil all endring på siden skje internt i applikasjonen. Siden det aldri skjer en ny sidelasting, vil analyseverktøyet ikke kunne fange opp hva som skjer.

### Lastetid
Ensideapplikasjoner har en høyere lastetid ved førstegangslasting enn server-baserte applikasjoner. Dette er fordi applikasjonen må laste inn hele rammeverket og applikasjonskoden før HTML-koden kan rendres ut i nettleseren. En server-basert applikasjon kan liste ut bare den koden som er nødvendig der og da, noe som vil minske lastetiden.

#### Raskere lastetid
Det er noen måter en kan få raskere lastetid på ensideapplikasjoner, som caching og utsette lasting av moduler til de blir synlige på skjermen. Applikasjonen må likevel laste rammeverket før den kan vise noe i nettleseren.

## Referanser


## Eksterne lenker
* Migrating Multi-page Web Applications to Single-page Ajax Interfaces (Delft University of Technology)
* The Single Page Interface Manifesto
* Frameworks for Developing Single Page Applications