Redigerer Ensideapplikasjon (avsnitt)

==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<ref name="spimanifesto">{{cite web | url=http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php | title=The Single Page Interface Manifesto | accessdate=2014-04-25}}</ref> med:

* Klient-sidig JavaScript-bibliotek som tar seg av forskjellige utfordringer.
* Server-sidige rammeverk for nett som spesialiserer seg på ensideapplikasjoner.<ref>{{cite web | url=http://derbyjs.com/ | title=Derby | accessdate=2011-12-11}}</ref><ref>{{cite web | url=https://github.com/balderdashy/sails | title=Sails.js | accessdate=2013-02-20}}</ref><ref>{{cite web | url=http://itsnat.sourceforge.net/index.php?_page=support.tutorial.spi_site | title=Tutorial: Single Page Interface Web Site With ItsNat | accessdate=2011-01-13}}</ref>
* Utviklingen av nettlesere og HTML5-spesifikasjonen som er designet mer for ensideapplikasjoner.<ref>[[HTML5]]</ref>

===Søkemotoroptimalisering===
På grunn av mangelen av JavaScript-utførelse av edderkopper for flere populære [[søkemotorer]],<ref>{{cite web |url=https://developers.google.com/webmasters/ajax-crawling/docs/learn-more |title=What the user sees, what the crawler sees |quote=the browser can execute JavaScript and produce content on the fly - the crawler cannot|accessdate=6. januar 2014}}</ref> har SEO ([[Søkemotoroptimalisering]], engelsk: Search Engine Optimization) historisk vore et problem for offentlige nettsider som ønsker å benytte modellen med ensidig applikasjon.<ref name="doogledevelopers">{{cite web |url=https://developers.google.com/webmasters/ajax-crawling/ |title=Making Ajax Applications Crawlable |quote=Historically, Ajax applications have been difficult for search engines to process because Ajax content is produced|accessdate=6. januar 2014}}</ref>

Mellom 2009 og 2015, [[Google Webmaster Tools|Google Webmaster Central]] foreslo og anbefalte et «AJAX crawling scheme»<ref>{{cite web|url=http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html|title=Proposal for making AJAX crawlable|date=7. oktober 2009|publisher=Google|accessdate=13. juli 2011}}</ref><ref>{{cite web|url=https://developers.google.com/webmasters/ajax-crawling/|title=(Specifications) Making AJAX Applications Crawlable|publisher=Google|accessdate=4. mars 2013}}</ref> ved å benytte et utropstegn for å identifisere seksjoner i AJAX-sider (<code>#!</code>).

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.<ref name="Holmes2015">Holmes, Simone (2015). ''Getting MEAN with Mongo, Express, Angular, and Node''. Manning Publications. {{ISBN|978-1-6172-9203-3}}</ref>

===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 [http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-history-pushstate pushState] og [http://www.w3.org/html/wg/drafts/html/master/browsers.html#dom-history-replacestate 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.<ref name="Holmes2015" />