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.^[1] Stuart Morris skrev om the Self-Contained website på slashdotslash.com med de samme målene og funksjonaliteten i april 2002,^[2] 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.^[3]

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^[4] med:

Klient-sidig JavaScript-bibliotek som tar seg av forskjellige utfordringer.
Server-sidige rammeverk for nett som spesialiserer seg på ensideapplikasjoner.^[5]^[6]^[7]
Utviklingen av nettlesere og HTML5-spesifikasjonen som er designet mer for ensideapplikasjoner.^[8]

Søkemotoroptimalisering

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

Mellom 2009 og 2015, Google Webmaster Central foreslo og anbefalte et «AJAX crawling scheme»^[11]^[12] 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.^[13]

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.^[13]

Referanser

^ «Inner-Browsing: Extending Web Browsing the Navigation Paradigm». Arkivert fra originalen . Besøkt 3. februar 2011. «Arkivert kopi». Arkivert fra originalen 27. mars 2014. Besøkt 21. november 2019.
^ «Slashdotslash.com: A self contained website using DHTML». Besøkt 6. juli 2012.
^ «US patent 8,136,109». Besøkt 12. april 2002.
^ «The Single Page Interface Manifesto». Besøkt 25. april 2014.
^ «Derby». Besøkt 11. desember 2011.
^ «Sails.js». Besøkt 20. februar 2013.
^ «Tutorial: Single Page Interface Web Site With ItsNat». Besøkt 13. januar 2011.
^ HTML5
^ «What the user sees, what the crawler sees». Besøkt 6. januar 2014. «the browser can execute JavaScript and produce content on the fly - the crawler cannot»
^ «Making Ajax Applications Crawlable». Besøkt 6. januar 2014. «Historically, Ajax applications have been difficult for search engines to process because Ajax content is produced»
^ «Proposal for making AJAX crawlable». Google. 7. oktober 2009. Besøkt 13. juli 2011.
^ «(Specifications) Making AJAX Applications Crawlable». Google. Besøkt 4. mars 2013.
^ ^a ^b Holmes, Simone (2015). Getting MEAN with Mongo, Express, Angular, and Node. Manning Publications. ISBN 978-1-6172-9203-3

Eksterne lenker

[1] «Inner-Browsing: Extending Web Browsing the Navigation Paradigm». Arkivert fra originalen . Besøkt 3. februar 2011. «Arkivert kopi». Arkivert fra originalen 27. mars 2014. Besøkt 21. november 2019.

[2] «Slashdotslash.com: A self contained website using DHTML». Besøkt 6. juli 2012.

[3] «US patent 8,136,109». Besøkt 12. april 2002.

[spimanifesto-4] «The Single Page Interface Manifesto». Besøkt 25. april 2014.

[5] «Derby». Besøkt 11. desember 2011.

[6] «Sails.js». Besøkt 20. februar 2013.

[7] «Tutorial: Single Page Interface Web Site With ItsNat». Besøkt 13. januar 2011.

[8] HTML5

[9] «What the user sees, what the crawler sees». Besøkt 6. januar 2014. «the browser can execute JavaScript and produce content on the fly - the crawler cannot»

[doogledevelopers-10] «Making Ajax Applications Crawlable». Besøkt 6. januar 2014. «Historically, Ajax applications have been difficult for search engines to process because Ajax content is produced»

[11] «Proposal for making AJAX crawlable». Google. 7. oktober 2009. Besøkt 13. juli 2011.

[12] «(Specifications) Making AJAX Applications Crawlable». Google. Besøkt 4. mars 2013.

[Holmes2015-13] Holmes, Simone (2015). Getting MEAN with Mongo, Express, Angular, and Node. Manning Publications. ISBN 978-1-6172-9203-3

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]