Christian Hansson
Tillståndslös kommunikation: En studie av JavaScript-ramverk
Stateless Communication:
A study of JavaScript frameworks
Informatik C-uppsats
Termin: VT 2016
Examinator: John Sören Pettersson
1
Abstract
Undersökningens syfte är att ta reda på hur JavaScript‐ramverk presterar i jämförelse med ren JavaScript i en kommunikation med en webbservice. Kommunikationen med en webbservice är tillståndslös. Detta innebär att en webbapplikations förfrågan mot en webbservice alltid är en ny förfrågan. En webbservice kommer inte ihåg klientens tidigare frågor.
Det finns idag en rad olika JavaScript‐ramverk som klarar av en kommunikation av sådan karaktär. Denna undersökning kommer att utvärdera prestationerna av de mest använda ramverken på marknaden gällande kommunikation med en webbservice. För att avgöra vilka ramverk som ska ingå i undersökningen ingick endast de ramverk vars användning på
webben överstiger 0.1%, vilket resulterade i att 17 stycken ramverk undersöktes. Därefter gallrades de ramverk bort som inte klarar av kommunikation med en webbservice, ramverk som inte är underhållna och slutligen också ramverk som kostar pengar att använda. De ramverk som kvarstod var jQuery, MooTools, Prototype, AngularJS och Dojo.
Implementationer producerades med de kvarvarande ramverken och en med ren JavaScript‐
kod. Sedan analyserades dessa implementationer genom att dokumentera svarstider och med hjälp av analyseringsverktyget Platojs. Verktyget gav svar på de frågor som
formulerades för att kunna svara på huvudgripliga undersökningsfrågan i undersökningen.
Frågorna sökte svar på underhållbarhetsvärde, antal rader kod, estimerade antal fel och Lint‐
fel.
Undersökningen visar att implementationer med JavaScript‐ramverk presterar bättre än ren JavaScript. En korrelation upptäcktes mellan mätvärdena ”estimerade antal fel” och
”underhållbarhet”, genom de ekvationerna Platojs använde för analysen. Om en
implementation innehåller ett högre antal estimerade fel var underhållbarheten sämre. En sammanvägd analys visade att det ramverk som presterade bäst var jQuery.
Nyckelord: JavaScript, ramverk, webbservice, Platojs, jämförelse
2
Innehåll
Förklaring av använda begrepp ... 4
1. Inledning ... 6
1.1 Problemområde... 6
1.2 Syfte ... 6
1.3 Undersökningsfrågor ... 6
1.4 Målgrupp ... 7
1.5 Avgränsning ... 7
1.6 Metod ... 8
1.6.1 Mall ... 8
1.6.2 Datainsamling ... 8
1.6.3 Reliabilitet... 9
1.7 Etiska överväganden ... 9
2. Teoretisk och Teknisk referensram ... 10
2.1 Tidigare forskning ... 10
2.2 Mätning av programvara ... 11
2.2.1 Underhållbarhet ... 11
2.2.2 Verktyget Platojs ger svar på mätvärden ... 12
2.4 Vad är en webbservice ... 13
2.5 REST‐API ... 13
3. Genomförande ... 15
3.1 Urval ... 15
3.2 Skapandet av implementationer ... 15
3.2.1 Mall ... 15
3.2.2 Scriptens funktionalitet ... 17
3.3 Generering av resultat ... 17
3.4 Utvärdering och poängsättning av resultat ... 19
4. Resultat och Analys ... 21
4.1 Individuella mätvärden ... 21
4.1.1 Underhållbarhet ... 21
4.1.2 SLOC ... 22
4.1.3 Uppskattade fel ... 23
4.1.4 Lint‐fel ... 24
4.1.5 Genomsnittliga svarstider ... 24
4.1.6 Sammanställning av resultat ... 25
4.2 Poängsättning för vidare forskning ... 25
4.3 Analysering av resultat ... 26
4.4 Hur ren JavaScript står sig mot ramverken ... 27
4.5 Bäst presterande implementationen: jQuery ... 27
4.6 Slutsats och sammanfattning ... 27
5. Diskussion ... 29
5.1 Fortsatta studier ... 29
Referenser ... 31
Bilagor ... 33
Bilaga 1 – Mall för empiri insamling ... 33
Bilaga 2 – Implementationer ... 34
3
Figurförteckning
Figur 1 – Formel för underhållbarhet ... 12
Figur 2 – HTML mall ... 16
Figur 3 – Resultat validering av mall ... 16
Figur 4 – Mappstruktur för mall ... 16
Figur 5 ‐ Svarstid exekvering av script ... 17
Figur 6 – Resultat underhållbarhet ... 18
Figur 7 – Resultat antal rader kod ... 19
Figur 8 – Resultat estimerade antal fel ... 19
Figur 9 – Resultat Lint‐fel ... 19
Figur 10 ‐ Platojs översikt av underhållbarhet ... 22
Figur 11 ‐ Platojs översikt antal rader kod ... 23
Figur 12 ‐ Platojs översikt antal uppskattade fel ... 24
Figur 13 ‐ Platojs översikt Lint‐fel ... 24
Figur 14 ‐ Implementation JavaScript ... 34
Figur 15 ‐ Implementation AngularJS ... 34
Figur 16 ‐ Implementation Dojo ... 35
Figur 17 ‐ Implementation jQuery ... 35
Figur 18 ‐ Implementation MooTools... 35
Figur 19 ‐ Implementation Prototype ... 36
Tabellförteckning
Tabell 1 – Exempel på resultat svarstid av ramverken ... 18Tabell 2 ‐ Resultat underhållbarhet ... 21
Tabell 3 ‐ Resultat antal rader kod ... 22
Tabell 4 ‐ Resultat uppskattade fel ... 23
Tabell 5‐ Resultat genomsnittliga svarstider ... 24
Tabell 6 ‐ Sammanställning undersökning ... 25
Tabell 7 – Mall för iterationer av svarstid ... 33
Tabell 8 ‐ Mall sammanställning undersökning ... 33
4
Förklaring av använda begrepp DOM
DOM är en förkortning av ”Document Object Model”. DOM är ett plattforms‐ och språk‐
neutralt interface som tillåter program och script att dynamiskt erhålla och modifiera dokument på webben. Utvecklare kan med hjälp av till exempel JavaScript uppdatera en webbsidas struktur och dess visuella representation (W3C 2005).
Html och CSS
HTML och CSS är två av de grundläggande teknikerna för att skapa webbsidor och webbapplikationer. Med HTML skapar man strukturen och med CSS skapas det visuella utseendet. HTML är ett så kallat märkspråk, där man använder sig utav taggar för att strukturera en webbsida. CSS används för att skapa den visuella representationen i form av färger, layouter och fonter (W3C 2016a).
HTTP
HTTP står för ”hypertext transfer protocol”. HTTP är de regler som gäller för överföring av data över internet. HTTP använder en klient‐server modell. En klient kan till exempel vara en dator i hemmet utrustad med en webbläsare. En server är typiskt sett ett webbhotell.
Samarbetet mellan klienten och servern utförs genom att webbläsaren skickar en förfrågan till servern. Servern svarar genom en statuskod. Om det är en lyckad förfrågan, statuskoden är 200, kommer data att skickas till klienten (TechTerms 2015).
JSON
JSON står för ”JavaScript Object Notation” och är ett text‐baserat format för strukturerad data (Bray 2014).
Lint‐fel
Lint‐fel innebär att syntax inte stämmer med den standard som existerar. Om ett Lint‐fel existerar är det en indikation att kod bör ses över, inte att kod är fel. Lint‐fel i JavaScript kan specificera vart i kod det existerar ett syntax fel och erbjuda en förklaring över funnet syntaxfel (Crockford 2008).
Open‐source
Open‐source innebär att källkod skriven av en eller flera utvecklare är publik. En open‐source produkt kan vilken användare som helst ladda ner och modifiera. Den generella tanken med open‐source är att det skall vara gratis att använda (Hertel et al. 2003).
Ramverk
Ramverk har utvecklats för diverse olika programspråk i syftet att främja användandet (Gizas et al. 2012). Med hjälp av ett ramverk bör de mest komplexa lösningarna förenklas för
5 lättare förståelse av koden. Ett ramverks lösningar bidrar även till lättare återanvändning av kod (Graziotin & Abrahamsson 2013).
REST
REST står för ”Representational State Transfer”. Det är ett samlingsnamn för webbens arkitektoniska stil. Begreppet REST myntades på grund av nyckel begränsningar upptäckta av Roy Fielding år 1993 (Masse 2011). Begreppet REST beskriver hur klienter och webbservices kommunicerar. Kommunikationen sker med hjälp av ett API som bestämmer exakt hur det skall gå tillväga. Ett API som anpassar sig till en REST arkitektonisk stil är ett REST‐API (Masse 2011).
Webbservice
En webbservice är en mjukvara placerad någonstans på internet. Den är åtkomlig via internetprotokoll, exempelvis http (se ovan) eller SMTP (simple mail transfer protocol). En webbservice är en standard för plattformsoberoende webbapplikationer (Chappell & Jewell 2002). En webbservice skall bestå av ett definierat interface. Ett interface som beskriver exakt hur kommunikationen går till oberoende av vilket typ av system som kommunicerar med webbservicen (W3C 2004).
6
1. Inledning
1.1 Problemområde
Att skapa en webbapplikation idag kräver viss kunskap inom HTML och CSS. Som
komplement finns även JavaScript. W3C (2016b) definierar JavaScript som det mest använda scriptspråket. Ett scriptspråk är ett programmeringsspråk där koden inte behöver kompileras före den körs. JavaScript bidrar till att en webbapplikation kan bli mer dynamisk, exempelvis att inte behöva ladda om en applikation i webbläsaren när en användare interagerat med den, enligt W3C (2016b).
Det går att skriva kompletta webbsidor och webbapplikationer med hjälp JavaScriptkod, men generellt sett undviks det idag. Istället används ramverk, men att välja ett ramverk är en helt egen process. Idag står utvecklare inför svårigheter när det kommer till att välja ett ramverk (Graziotin & Abrahamsson 2013). Att lära sig ett ramverk är att lära sig hur det är uppbyggt (Hou et al. 2003).
En webbservice är en mjukvara placerad någonstans på internet, tillgänglig via HTTP.
Kommunikationen med en webbservice är tillståndslös. Det betyder att för varje fråga vi ställer mot en webbservice måste vi skicka exakt den relevanta data som krävs, en webbservice kommer inte ihåg en klient (Masse 2011). En webbservice tror alltid att en klient är en ny klient oavsett hur många gånger tidigare den agerat mot den (W3C 2004). Det kan resultera i många förfrågningar från en webbapplikation mot en webbservice.
Eftersom det idag finns en rad olika JavaScriptramverk som klarar av att hantera en
tillståndslös kommunikation ämnar detta kandidatarbete svara på hur de väl presterar efter utvalda mätvärden. Även hur de presterar i jämförelse med en implementation med ren JavaScript, det vill säga ett script skrivet utan att använda något ramverk.
Gizas et al. (2012) har i sin undersökning testat källkoden för olika JavaScriptramverk. De har inte testat någon slags implementation utförd med ramverken, utan endast den källkod som utgör ramverken. Det som testades i deras undersökning var kvalitét, validitet och
prestanda. Slutsatsen av deras undersökning visade att en del ramverks källkod bör ses över.
Jag har inte hittat några studier där implementationer utförda med ramverk testats. Den utförd av Gizas et al. (2012) är den enda liknande som jag hittat.
1.2 Syfte
Syftet med denna undersökning är att ta reda på om JavaScriptramverk lämpar sig bättre än ren JavaScript i en tillståndslös kommunikation med en webbservice.
1.3 Undersökningsfrågor
Den huvudgripliga undersökningsfrågan i detta kandidatarbete är: Hur presterar
JavaScriptramverk i jämförelse med ren JavaScript i kommunikation med en webbservice efter utvalda mätvärden?
7 Gizas et al. (2012) har i sin undersökning testat kvalitét, validitet och prestanda av källkoden på en rad olika JavaScriptramverk med hjälp av definierade kriterier. Likt de kriterierna har det i denna undersökning formulerats underfrågor för att kunna besvara den huvudgripliga undersökningsfrågan. Frågorna lyder:
Hur ser underhållbarheten ut för skapad implementation?
Hur ser antal rader kod, SLOC (source lines of code), ut för skapad implementation?
Hur ser antal uppskattade fel i implementationen ut?
Hur ser antal Lint‐fel ut (baserat på resultatet från analyseringsverktyget JSLint)?
Hur ser genomsnittliga svarstider av implementationen ut (genom iterationer av implementationen)?
Svaren på dessa frågor utgör den mall för analys som används i denna undersökning, för att besvara den huvudgripliga undersökningsfrågan.
1.4 Målgrupp
Undersökningen är tänkt att inriktas mot utvecklare som är i valet av att välja ett ramverk för ett projekt där tillståndslös kommunikation är ett krav. Tillsammans med krav om att
ramverket skall vara open‐source, det vill säga att användandet skall vara gratis.
1.5 Avgränsning
Mitt kandidatarbete är avgränsat på flera sätt. Den första delen är att undersökningen avser att undersöka JavaScriptramverk vars totala användning på webben överstiger 0.1%. Genom denna avgränsning blir det totalt 17 stycken ramverk som initialt ingår i undersökningen, enligt W3Techs (2016). Ramverken blir därefter: jQuery, Bootstrap, Modernizr, MooTools, ASP.NET Ajax, Prototype, Script.aculo.us, YUI library, Shadowbox, Spry, Underscore, AngularJS, Backbone, Dojo, Knockout, GSAP och Ext JS (W3Techs 2016). Avgränsningen bestämdes då det skulle bli ett acceptabelt antal ramverk som undersöktes, då det finns väldigt många ramverk ute på marknaden idag (Graziotin & Abrahamsson 2013).
Den andra avgränsningen i mitt kandidatarbete gäller dokumentationen av de olika ramverken. Det finns idag många hemsidor som erbjuder handledning om ramverken, utöver detta finns det även böcker som utbildningssyfte. Av denna anledning kommer jag att i min granskning av olika ramverk hålla antalet källor lågt. Endast undersöka den officiella dokumentation tillhandahållen av ramverkens utvecklare för att göra det rättvist för alla ramverken. Implementationerna, som skapades av mig, producerades på det sätt som utvecklarna av ramverken menade. En del av denna avgränsning var även om ett ramverk fortfarande var underhållet.
Den tredje avgränsningen jag vill beröra är webbservicens data. Jag ämnade undersöka hur de olika ramverken hämtar data från en webbservice via ett REST‐API. Istället för att skapa en egen webbservice på en server använde jag mig av ett som Typicode (2016)
8 tillhandahåller. Detta gör det möjligt för framtida studier, och utvecklare, att jämföra egna resultat med de som framkom i denna undersökning.
Den sista avgränsningen är att endast undersöka och implementera den funktionalitet som krävs. Detta innebär att inte implementera något som inte behövs för att utföra en
kommunikation med en webbservice, då det skulle påverka det slutgiltiga resultatet i undersökningen.
1.6 Metod
I detta avsnitt ges en kortfattad redovisning om hur utförandet genomfördes i undersökningen. I kapitel 3 beskrivs utförandet med ett mer tekniskt sätt att skriva.
1.6.1 Mall
Till undersökningen skapades en mall. Den mallen var en tom webbapplikation, det vill säga ingen som helst funktionalitet applicerad. Mallen skulle vara lätt att kopiera för vidare applicering av ramverket som skulle testas. Detta för att få ett så enhetligt resultat som möjligt. Skulle samma webbapplikation användas för alla implementationslösningar kan det finnas en risk att det ligger kvar något i koden, som i slutändan skulle ge ett resultat som inte går att lita på.
1.6.2 Datainsamling
I detta avsnitt följer en kortfattad redovisning hur datainsamlingen gick till i undersökningen.
En mer detaljerad redovisning av hur resultat genererades går att läsa om i kapitel 3.
Undersökningen skedde i olika steg. Det första steget var att undersöka dokumentationen som fanns för de initialt 17 stycken olika ramverk som ingick i undersökningen. Målet med detta var att sålla bort de ramverk som inte uppfyller de kriterier undersökningen kräver, de kriterierna återfinns i kapitel 3.1 Urval. En teknik som användes vid granskningen var en teknik som Patel och Davidson (2011) nämner, dokument‐studier. Beteckningen används traditionellt för information som nedtecknats eller tryckts. ”Oavsett hur vi gör, måste vi se till att vi inte bara väljer ut sådant material som stöder våra egna idéer” (Patel & Davidson 2011, s. 69). Därför valdes enbart den officiella dokumentationen och ingen annan potentiell källa utan koppling till utvecklarna av ramverken. Efter att ha undersökt dokumentationen kvarstod fem ramverk i undersökningen. Och implementationerna skapades med hjälp av den dokumentation som granskades. Implementationer finns i bilaga 2.
När implementationerna hade skapats utfördes iterationer av exekvering i syfte att
dokumentera genomsnittliga svarstider. Efter att svarstider var fastställda implementerades ett analyseringsverktyg, Platojs (Overson et al. 2012). Med detta verktyg kunde resultat genereras, resultat som gav svar på undersökningens återstående frågor, som återfinns i kapitel 1.3 Undersökningsfrågor. Svaren på frågorna, för varje implementationslösning, var de olika mätvärdena som användes för att besvara den huvudgripliga undersökningsfrågan.
Ramverken poängsattes därefter baserat på de resultat som framkom. Poängsättningen
9 bestod av maximalt sex poäng per fråga. Det ramverk vars resultat var det bäst presterande fick högst poäng, ramverket vars resultat var sämst fick lägst. Hur svaren bedömdes går att läsa om i kapitel 3.4 Utvärdering och poängsättning av resultat, där redovisas vad som var ett önskvärt mätvärde för varje svar.
1.6.3 Reliabilitet
Målet med undersökningen är att kunna leverera ett så enhetligt och precist resultat som möjligt. Därför utfördes alla testerna på min dator hemma hos mig. Min internetuppkoppling var under undersökningen 100/100 Mbit/s.
Eftersom jag planerade att använda Typicode (2016) API att testa emot itererades implementationerna för att få ett snitt på svarstider. Iterationerna var de enda exekveringarna av scripten som utfördes i undersökningen. Typicode (2016) är ett api tillgängligt för alla, så kan jag inte garantera att alla implementationer kommer få samma resultat. Och av den anledningen skedde iterationer av exekveringen för att kunna utesluta eventuella internetrestriktioner som kan förekomma.
1.7 Etiska överväganden
Vetenskapsrådet (2002) listar fyra stycken huvudkrav. De kraven är informationskravet, samtyckeskravet, konfidentialitetskravet och nyttjandekravet. Dessa krav är även enligt Vetenskapsrådet (2002) avsedda att vägleda den enskilde forskaren i sin planering.
Informationskravet innebär att man som forskare skall informera uppgiftslämnare och undersökningsdeltagare om deras uppgift i projektet, och vad som gäller för deras deltagande.
Samtyckeskravet betyder att en forskare alltid skall inhämta samtycke från undersökningsdeltagare.
Konfidentialitetskravet innebär att den personal i forskningsprojektet som omfattar användning har tystnadsplikt gällande uppgiftslämnare och undersökningsdeltagare.
Nyttjandekravet innebär att uppgifter om enskilda inte får användas för kommersiellt bruk eller andra icke‐vetenskapliga syften (Vetenskapsrådet 2002).
Dessa krav är inte något som är aktuellt i den undersökning jag har genomfört. Det har inte
funnits några respondenter eller undersökningsdeltagare att ta hänsyn till.
10
2. Teoretisk och Teknisk referensram
I detta kapitel redovisas den litteraturgenomgång som gjordes i detta arbete.
2.1 Tidigare forskning
Jones (2007) diskuterar att det finns en rad olika sätt att avgöra vad som är en bra
dokumentation för ett programspråk. I artikeln diskuteras det hur man som utvecklare av ett programspråk bör tänka för att producera en dokumentation, och olika faktorer man kan använda för att avgöra kvaliteten av dokumentationen. I artikeln nämner han:
Hur lätt det är för utomstående att skapa en implementation baserad på informationen i programspråksdokumentationen.
Ansträngningen utförd för att skapa dokumentationen. Det kan anses som ett kommersiellt intresse för ett programspråk. Ju mer populärt det blir desto mer utvecklas dokumentationen.
Dessa faktorer Jones (2007) nämner är relevanta för arbetet. Det kommer vara av intresse att se vilken version dokumentationen befinner sig, för att exempelvis avgöra om ett ramverk är underhållet eller inte. Implementationer kommer att produceras med hjälp av dokumentation, så informationen dokumentationen bistår med bör vara relevant.
Gizas et al. (2012) har i deras arbete utfört tester på källkoden i en del av de mest använda JavaScriptramverken. De ramverk som ingick i deras undersökning var: Ext JS, Dojo, jQuery, MooTools, Prototype and YUI. I undersökningen har de testat kvalitet, prestanda och validering. I undersökningen har de använt flera olika verktyg i syftet. Gällande kvalitét undersöktes storlek, komplexitet och underhållbarhet. Storlek undersöktes genom att räkna antal rader kod. Komplexitet undersöktes genom att sätta ett värde på hur många vägar det finns i ett program (McCabe 1976), och sist räknades det ut ett underhållbarhetsvärde.
Prestanda testades i deras undersökning genom att undersöka exekveringstid i olika webbläsare. Det sista som testades i undersökningen utfört av Gizas et al. (2012) är validering. Det skedde genom att testa om ramverken innehöll några kritiska fel i form av genererade felmeddelanden. I sammanfattningen som ges försöker de inte kröna det bästa ramverket. Poängen de förmedlar är en indikation att ett visst ramverk bör ses över. Nästa steg i undersökningen har de för avsikt att utföra testerna av ramverken i en mobil miljö (Gizas et al. 2012).
Hou et al. (2003) diskuterar just användandet av ramverk. De påstår att lära sig att använda ett ramverk är ganska svårt. Att lära sig ett ramverk är att lära sig hur ramverket är
uppbyggt. Och att i en ideal situation döljs källkoden som utgör ramverken för programmerare så gott som möjligt, tyvärr är det inte alltid fallet. Ibland måste
programmerare även titta i källkoden för att skapa en förståelse av ramverket (Hou et al.
2003).
11 Teknologier ämnade för webbutveckling utvecklas allt mer. Det är idag möjligt att skapa en webbapplikation istället för ett vanligt program i en dator (Graziotin & Abrahamsson 2013).
Graziotin och Abrahamsson (2013) diskuterar att JavaScript är det mest populära programmeringsspråket för webbläsare. Och att det är fullt möjligt att idag skriva en applikation med ren JavaScript. Men programmerare undviker detta typiskt sett och
använder sig utav ramverk. Graziotin och Abrahamsson (2013) diskuterar att de har sett att utvecklare inte är intresserade av olika prestationer i form av olika mätvärden. De visar mer intresse för hur underhållet ett ramverk är, storleken av ramverket, licensen och mängden funktionalitet som finns. Graziotin och Abrahamsson (2013) summerar sin rapport genom att diskutera att webbutvecklingen är på väg in i en ny era. En era där JavaScript blir mer och mer viktig. De rekommenderar mätning av prestanda med hjälp av olika mätvärden.
2.2 Mätning av programvara
Grady (1994) definierar termen Software Metrics som ”Software metrics measure specific attributes of a software product or a software development process. In other words, they are measures of success” (s. 18). Grady (1994) diskuterar att alla dessa attribut hos utvecklandet av en mjukvara eller mjukvaran i sig är markerade med en slutpunkt. En slutpunkt är ett önskat resultat av en mätning. Det önskade resultatet kan vara bestämt av en tredje part eller av en själv som utvecklare. I detta kandidatarbete kommer termen software metrics att översättas till svenska genom termen mätvärden. Svaren på de frågor som återfinns i kapitel 1.3 Undersökningsfrågor utgör de mätvärden som används i undersökningen.
2.2.1 Underhållbarhet
Welker (2001) har i sin artikel sett över måttet maintainability index (MI). I artikeln
presenterar han de ursprungliga två polynom ekvationerna för att avgöra ett eventuellt MI.
Logiken bakom ekvationerna var att skapa kvantifierbara värden av följande:
Densitet av operatorer och operander. Hur många variabler finns det och hur används dem.
Komplexiteten av logiken. Hur många exekveringsvägar finns det i koden.
Storlek. Hur mycket kod finns det.
Mänsklig insikt. Har det kommenterats i koden
Resultatet av ekvationerna ger ett MI index. Vilket värde som ges kan variera mellan olika ekvationer som används, baserat på de två ursprungliga polynom ekvationerna. Ett exempel är i artikeln av Welker et al. (1997) presenteras en skala mellan 0 och 4.
MI är alltså ett mått av ett systems eller applikations underhållbarhet. Wani och Gandhi (1999) skriver att om ett system är bra borde underhållbarhetsvärdet vara högre, och vice versa. Welker (2001) diskuterar att man inte bör behandla detta värde som ett vakuum, det vill säga att strikt följa det till punkt och pricka. ”Subjective measures applied via human code reviews still play an extremly important role in assessing software maintainability.”
12 (Welker 2001, s.1). Citatet summerar den poäng Welker (2001) förmedlar. Att man bör se underhållbarhetsvärde som en indikator för en direkt mänsklig undersökning.
2.2.2 Verktyget Platojs ger svar på mätvärden
Här kommer det att redovisas vilken litteratur som undersökts i samband med granskningen av analyseringsverktyget Platojs (Overson et al. 2012). Då det inte finns någon omfattande dokumentation gällande Platojs har det granskats källkod för verktyget. Nedan redovisas vad Platojs tillhandahåller svar på, och den litteratur som undersökts gällande de olika
mätvärdena.
Platojs (Overson et al. 2012) är ett verktyg för att visualisera JavaScriptkods komplexitet.
Verktyget tar en implementation och analyserar den JavaScriptkod som implementationen består av. Efter analys kan Platojs tillhandahålla svar på de underfrågor som formulerades för att besvara kandidatarbetets övergripliga undersökningsfråga, som återfinns i avsnitt 1.3 Undersökningsfrågor. Det första Platojs kan ge svar på är hur underhållbarhet ser ut.
Formeln Platojs använder kan ses i figur 1.
Figur 1 – Formel för underhållbarhet
Parametern ”averageEffort” bygger på termen ”Halstead Volume” som beräknas som antalet förekomster av operatorer och operander multiplicerat med logaritmen av antalet olika operatorer och operander i koden (Caldiera et al. 1991). Parametern ”averageCyclomatic”
bygger på termen ”Cycolmatic Complexity” som betyder ett mått på hur många vägar det finns i ett program (McCabe 1976). Den sista parametern i ekvationen ”averageLoc” betyder antalet rader kod i implementationen.
Platojs (Overson et al. 2012) ger även en representation på hur mycket kod det finns i varje analyserad implementation, vilket även är en faktor för hur Platojs räknar ut
underhållbarheten. Antal rader kod är idag ett av de mest mätbara och definierade mätvärden som används. Den underliggande idén med att mäta antal rader kod är att program blir mer och mer avancerade ju mer kod som produceras (Ferrer et al. 2013).
Platojs ger också en visuell representation på antalet estimerade fel. Enligt Ferrer et al.
(2013) är denna ekvation en del av Halsteads definierade mått. Ekvationen för estimerade fel ser ut på följande vis: ”B = ଷ ”. Bokstaven ”B” i ekvationen står för de estimerade antal felen en implementation kan innehålla (Ferrer et al. 2013).
Platojs bistår även med eventuella Lint‐fel som existerar, med hjälp av verktyget JSLint (2015). Lint‐fel är ett meddelande att syntax inte stämmer med den standard som ECMA (2016) bestämt, enligt Crockford (2008). Skulle ett Lint‐fel finnas i analysen gjord av Platojs
13 kommer verktyget att kunna bistå med en beskrivning av problemet och en ungefärlig plats där det uppstod. Crockford (2008) beskriver syftet med Lint‐fel genom att påpeka att det inte är en verifiering att skriven kod är korrekt, utan att det agerar som ett extra par ögon för att upptäcka potentiella problem.
2.4 Vad är en webbservice
Chappell och Jewell (2002) beskriver termen ”Web service” som: ”A web service is a piece of business logic, located somewhere on the Internet, that is accessible through standard‐
based Internet protocols such as http or SMTP” (s.6). Chappell och Jewell (2002) menar att en webbservice utvecklades för att skapa en standard för plattformsoberoende
webbapplikationer.
W3C (2004) definierar termen webbservice på följande sätt: ”A Web service is a software system designed to support interoperable machine‐to‐machine interaction over a network.”
W3C (2004) skriver att en webbservice måste bestå av ett interface beskrivet på så sätt att vilken maskin som helst bör kunna förstå det. Andra systems interaktioner med en
webbservice måste således följa den standard som interfacet beskriver. W3C (2004) skriver
”en webbservice är en abstrakt notation som måste bli implementerad av en konkret agent”.
En agent i detta fall är en konkret mjuk‐/hårdvara som skickar eller tar emot meddelanden från en webbservice. W3C (2004) fortsätter beskriva funktionalitet hos webbservices på följande vis.
Du kan implementera en specifik web service med hjälp av en agent enda dagen, skrivet med ett särskilt programspråk. En annan dag skall du kunna implementera samma web service med en annan agent, skapad med ett annat programspråk. Även om agenterna ändrats kommer webbservicen vara den samma. (W3C 2004)
2.5 REST‐API
Ordet REST betyder ”Representational State Transfer” och är ett samlingsnamn, sedan år 2000, för webbens arkitekturstil (Masse 2011). Klienter som kommunicerar med en web service använder sig av ett API (application programming interface). Ett API kan ses som ett sätt att visa hur klienter kan kommunicera och utbyta information mellan varandra (Masse 2011).
Webbens arkitektur består av sex stycken begränsningar, en del av dem kan delas in ytterligare. Begränsningarna formulerades 1993 av Roy Fielding (Masse 2011). Fielding formulerade begränsningarna eftersom han såg ett problem i hur skalbarheten för webben utvecklades. Begräsningarna som Fielding formulerade är: Client‐server, Uniform interface, Layered system, Cache, Stateless och Code‐on‐demand. REST är Fieldings samlingsnamn som anpassar sig till dessa begränsningar (Masse 2011).
REST är alltså en arkitektonisk stil vanligen använd som en design för moderna webbservices.
Ett API som använder sig av utav REST arkitektonisk stil är alltså ett REST‐API (Masse 2011).
14 Ett REST‐API använder sig av Uniform Resource Identifiers (URI’s) för att kommunicera med olika resurser, som till exempel en webbservice. URI är en syntax som är till för att ge varje resurs på webben ett unikt id (Masse 2011). En sådan resurs kan se ut på följande vis, även den som användes i undersökningen tillhandahållet från Typicode (2016): ”
http://jsonplaceholder.typicode.com/posts”. Med hjälp av en sådan resurs kan en förfrågan mot en webbservice utföras och ett svar levereras (Masse 2011).
15
3. Genomförande
Detta kapitel går igenom hur undersökningen lades upp och hur resultat kunde genereras och sedermera poängsättas.
3.1 Urval
Initialt i urvalsprocessen undersöktes det övergripande syftet med ramverken. Vad ramverkens primära uppgift var ställdes mot kriterierna för deltagande i undersökningen.
Undersökningen använde den officiella dokumentationen för varje ramverk. Kriterierna, som grundas i detta kandidatarbetes avgränsningar, lyder:
Klarar ramverket av att utföra ett http‐request?
Är ramverket open‐source (gratis att använda)?
Är ramverket fortfarande underhållet?
De ramverk som inte passerade gallringen är: Bootstrap, Modernizr, ASP.NET Ajax,
Script.aculo.js, YUI library, Shadowbox, SPRY, Underscore, Backbone, Knockout, GSAP och EXT JS. I de efterforskningar som utfördes när ramverkens officiella dokumentation granskades kunde dessa ramverk svara nej på minst ett av de kriterierna och därför bortfaller alltså dessa. En annan anledning till bortfall var beroenden. En del av ramverken visade sig kräva ett annat ramverk för användning. Eftersom undersökningen ämnar svara på hur individuella ramverk presterar resulterar ramverk som kräver ett annat ramverk i ett bortfall.
De ramverk där det kunde svaras ja på kriterierna när den officiella dokumentationen undersöktes var:
JQuery
MooTools
Prototype
AngularJS
Dojo
Undersökningen genomfördes därefter med dessa ramverk, och en implementation med ren JavaScript.
3.2 Skapandet av implementationer
I denna undersökning användes webbläsaren Firefox (version 48.0.2) för att exekvera scripten. För att nollställa webbläsaren mellan exekveringarna startades den om, så att eventuella data som lagrats rensades bort.
3.2.1 Mall
För att kunna exekvera implementationerna av ramverken användes HTML för att skapa en blank webbsida. Den blanka webbsidan innehöll endast en titel‐tagg, meta‐tagg och en script‐tagg där de ramverk som ingick i undersökningen skulle inkluderas. Målet med en
16 sådan minimal blank webbsida var att lägga störst fokus på ramverken. Mallens HTML‐
struktur kan ses i figur 2.
Figur 2 – HTML mall
För att säkerställa den HTML kod användes en valideringstjänst som W3C erbjuder gratis1, resultatet av den valideringen kan ses i figur 3. Den script‐tagg som kan ses i figur 2, men inte i figur 3, var inte med i valideringen då den inte innehöll något script.
Figur 3 – Resultat validering av mall
Den mappstrukturen som bestämdes för mallen kan ses i figur 4. I figuren är varje ord som är markerat med en pil en mapp, varje ord utan en pil är en fil.
Figur 4 – Mappstruktur för mall
För varje implementation som skapades placerades de script som producerades i mappen
”js”. Att det var samma mappstruktur för alla ramverkens implementationer förenklade
1 Läs mer om W3C validerings tjänst. https://validator.w3.org/ Besökt den 2 maj 2016 i skapandet av mall.
17 arbetet som Platojs (Overson et al. 2012) utförde då man pekade på en mapp i
kommandotolken, se kapitel 3.3 Generering av resultat.
3.2.2 Scriptens funktionalitet
Den enda funktionaliteten som krävdes för undersökningens syfte var möjligheten att skapa ett http‐request, ingen annan funktionalitet producerades. Ett http‐request utförs när en webbsida laddats färdigt och de importerade JavaScriptfilerna exekveras. JavaScriptfiler importeras i slutet av sidan vilket anses som god praxis enligt Google (2016), som visas i kapitel 3.2.1 Mall. Med ett http‐request hämtade implementationerna data från en webbservice. Data som hämtades var i form av JSON objekt, tillhandahållet från Typicode (2016). Information för att kunna producera scripten hämtades från den dokumentation som fanns tillgängligt från utvecklarna av ramverken. Dokumentationen var av värde då den var utförlig för den önskade funktionaliteten och fortfarande underhållen (Jones 2007).
För att kunna visualisera data utan att behöva modifiera DOM användes kommandot:
”console.dir”. Detta kommando tillhandahåller en utskrift i en webbläsares webbkonsol.
Med hjälp av kommandot och webbkonsollen går det att skriva ut hur lång tid det tar för en implementation att exekveras, i syftet att generera svarstider och verifiera att det är ett lyckat http‐request.
Den första som testades i varje implementationslösning var svarstider för exekvering av script. Svarstiderna genereras genom att skapa två variabler bestående av tidsmarkering med hjälp av kommandot: ”performance.now()”, vilket är precist till en tusendel av en millisekund enligt MDN (2016). Kommandot returnerar en siffra som placeras i en variabel.
Den första variabeln förekom före all skriven kod och den andra efter. Efter de
tidsmarkeringarna var skapade räknades svarstiden ut, och skrevs ut i webbkonsolen. Figur 5 visas ett exempel på hur det såg ut.
Figur 5 ‐ Svarstid exekvering av script
3.3 Generering av resultat
Som det tidigare nämns användes ett kommando för att dokumentera en svarstid i form av millisekunder, vilket kunde avläsas i webkonsolen. Den dokumenterades för varje iteration i en tabell. Tabellen utformades att den innehöll varje ramverks iteration. Detta för att skapa en överskådlig syn av all rådata som genererades. Exempel på hur den ser ut kan ses i tabell 1. I undersökningen valdes det att iterera implementationen tio gånger. När iterationerna utförts räknades ett medelvärde ut och avrundades till tre decimaler. Därefter togs kommandot för svarstid bort från implementationerna.
18
Tabell 1 – Exempel på resultat svarstid av ramverken
Iteration Angular Dojo jQuery Mootools Prototype JavaScript
1
2
3
4
5
6
7
8
9
10
M =
Efter att ha fastställt en genomsnittlig svarstid för implementationerna installerades
verktyget Platojs på den dator där undersökningen genomfördes. För att göra det möjligt för Platojs att generera ett resultat för en specifik implementation krävdes det att i
kommandotolken navigera sig dit implementationen fanns, på datorn. Sedan exekvera Platojs med hjälp av kommandot: ”plato ‐r ‐d report js”. Detta skapar en mapp vid namn
”report”. I den mappen placeras resultatet av analysen. Det sista ordet ”js” i kommandot representerar den mapp med script i som Platojs skall analysera.
Formatet för Platojs data erhölls som en webbsida, även tillgänglig utan uppkoppling till internet. Den webbsidan gav tydliga visuella representationer på de frågor undersökningen sökte svar på. Nedan följer exempel på hur data visualiserades av Platojs efter det hade implementerats, och analyserat ett script. I exemplen nedan visas endast ett analyserat script, i kapitel fyra där undersökningens resultat presenteras är analyserna från Platojs sammanslagna i ett stapeldiagram.
Figur 6 visar hur underhållbarheten kan se ut för det analyserade scriptet. Figur 7 visar hur antal rader kod (source lines of code) ser ut i scriptet. Figur 8 visar ett exempel på hur estimerade fel visualiseras. Slutligen visar figur 9 exempel på hur Lint‐fel visualiseras.
Figur 6 – Resultat underhållbarhet
19
Figur 7 – Resultat antal rader kod
Figur 8 – Resultat estimerade antal fel
Figur 9 – Resultat Lint‐fel
3.4 Utvärdering och poängsättning av resultat
I utvärderingen av de individuella testresultaten, som framställts genom iterationer av exekvering och analysen av Platojs (Overson et al. 2012), tilldelades ramverken poäng.
Poängskalan utformades genom att det var sex implementationer och lika många poäng kunde ges för varje mätvärde. Mätvärdena är svaren på de underfrågor som finns
definierade i avsnitt 1.3 Undersökningsfrågor och som utgör grunden till undersökningens huvudfråga. Den implementation som presterade sämst gällande en fråga tilldelades ett poäng och den som presterade bäst tilldelades sex poäng. Nedan följer en förklaring för hur resultaten bedömdes och poängsattes, enligt de svar som underfrågorna genererade.
20 För underhållbarheten tillhandahöll Platojs en siffra mellan 0 och 100. Ett högt tal innebär högre underhållbarhet, därför poängsattes den implementationen med högst
underhållbarhet med flest poäng.
Antal rader kod bedömdes genom att ju högre tal desto sämre. Ferrer et al. (2013) menar att ju högre antal rader kod som produceras desto mer komplex blir koden, vilket kan leda till lägre underhållbarhet. Eftersom implementationerna som ingick i undersökningen utförde exakt samma funktionalitet poängsattes den implementation med minst antal rader kod högst.
Antal uppskattade fel bedömdes genom att ett högt resultat var det sämsta. Den
implementation som fick det högsta resultatet poängsättes därför lägst, och den med minst poängsättes högst. Ett högt tal innebar att det fanns fler estimerade fel i en implementation.
Lint‐fel var något Platojs analyserade och gav en siffra på hur många som fanns. Ju högre antal Lint‐fel som uppstod desto sämre. Ett Lint‐fel innebar att kod man skrivit innehöll ett eller flera syntax fel. Implementationen med minst Lint‐fel poängsattes därför med flest poäng.
När det gäller genomsnittliga svarstider poängsattes den snabbaste implementationen högst, den med längst svarstid poängsattes lägst.
21
4. Resultat och Analys
I detta kapitel presenteras resultatet av undersökningen. Initialt redovisas enskilda resultat av undersökningen med hjälp av tabeller och figurer. Därefter redovisas den övergripliga analys som genomfördes baserat på resultaten. I analysen besvaras den huvudgripliga undersökningsfrågan i kandidatarbetet.
4.1 Individuella mätvärden
Nedan kommer resultaten av de enskilda mätvärdena redovisas. De enskilda mätvärdena i denna undersökning är svaren på de underfrågor som återfinns i avsnitt 1.3 Undersöknings‐
frågor. Svaren är de mätvärden som ligger till grund för den huvudgripliga frågan i detta kandidatarbete: Hur presterar JavaScriptramverk i jämförelse med ren JavaScript i kommunikation med en webbservice efter utvalda mätvärden?
Redovisningen sker i samma ordning som frågorna är listade.
Hur ser underhållbarheten ut för skapad implementation?
Hur ser antal rader kod, SLOC (source lines of code), ut för skapad implementation?
Hur ser antal uppskattade fel i implementationen ut?
Hur ser antal Lint‐fel ut (baserat på resultatet från analyseringsverktyget JSLint)?
Hur ser genomsnittliga svarstider av implementationen ut (genom iterationer av implementationen)?
I varje redovisning delas poäng ut baserat på prestation av varje implementation. Hur poängsättning definierades beskrivs i avsnitt 3.4 Utvärdering och poängsättning av resultat.
4.1.1 Underhållbarhet
I presentationen av detta mätvärde kommer jag att använda förkortningen MI.
Förkortningen kommer från det engelska uttrycket för underhållbarhet ”Maintainability index”.
Det var någorlunda jämt mellan de olika ramverken med två undantag. Första undantaget var implementationen med ren JavaScript som fick lägst med 76.1 MI. Nästa ramverk var AngularJS som fick näst lägst med 86.31 MI. Implementationen med ramverket Dojo fick 92.86 MI, Prototype 93.02 MI och jQuery fick 93.64 MI. Det ramverk som fick högst underhållbarhet poäng var MooTools med 94.16 MI.
Tabell 2 visar resultatet utan inbördes ordning. Därefter följer en visuell presentation tillhandahållet av verktygen Platojs där alla ramverk placerats tillsammans i ett stapeldiagram, se figur 10.
Tabell 2 ‐ Resultat underhållbarhet
Ramverk Maintainability index Poäng
JavaScript 76.1 1
22
AngularJs 86.31 2
Dojo 92.86 3
jQuery 93.64 5
Mootools 94.16 6
Prototype 93.02 4
Figur 10 ‐ Platojs översikt av underhållbarhet
4.1.2 SLOC
Antal rader kod i implementationerna analyserades också av Platojs (Overson et al. 2012).
Det ramverk som hade lägst antal rader kod i implementationen var jQuery med 5 rader kod.
Efter det kom MooTools med 6 rader kod. Efter det kom Prototype med 10 rader kod.
AngularJS implementation hade 12, Dojo hade 14 rader kod. Den implementation som hade flest antal rader kod var ren JavaScript som hade 15.
I tabell 3 sammanställts resultatet utan inbördes ordning. Figur 11 presenterar resultatet av antal rader kod i form av ett stapeldiagram, tillhandahållet av verktyget Platojs.
Tabell 3 ‐ Resultat antal rader kod
Ramverk SLOC (source lines of code) Poäng
JavaScript 15 1
AngularJs 12 3
Dojo 14 2
jQuery 5 6
Mootools 6 5
Prototype 10 4
23
Figur 11 ‐ Platojs översikt antal rader kod
4.1.3 Uppskattade fel
Den som hade flest uppskattade fel var den med ren JavaScript. Implementationen hade 0.1 uppskattade fel. Därefter kom AngularJS med 0.08. Prototype hade 0.06. Dojo och MooTools hade 0.04. Implementation med lägst antal uppskattade fel var den skriven med jQuery vilket enbart hade 0.02.
I tabell 4 presenteras en sammanställning av antal uppskattade fel. I figur 12 presenteras resultatet tillhandahållet från Platojs. Resultatet av denna del i undersökningen genererade lika resultat för två av implementationerna. Därför reducerades antal möjliga poäng och poängskalan varierade mellan 1 och 5.
Tabell 4 ‐ Resultat uppskattade fel
Ramverk Estimated errors Poäng
JavaScript 0.1 1
AngularJs 0.08 2
Dojo 0.04 4
jQuery 0.02 5
Mootools 0.04 4
Prototype 0.06 3
24
Figur 12 ‐ Platojs översikt antal uppskattade fel
4.1.4 Lint‐fel
När Platojsanalysen utförts visade det sig att inte en enda av implementationerna innehöll något Lint‐fel. Implementationerna tilldelas därför 0 poäng, då det inte går att särskilja dem.
För detta kapitels konsistens presenteras det stapeldiagram tillhandahållet från Platojs i figur 13.
Figur 13 ‐ Platojs översikt Lint‐fel
4.1.5 Genomsnittliga svarstider
Tabellen nedan visar resultatet av de genomsnittliga svarstiderna för alla implementationer.
Resultatet från alla de iterationerna som genomfördes finns i bilaga 1. Det ramverk som hade högst genomsnittlig svarstid var Dojo med 14.533 millisekunder. Därefter kom MooTools med 2.73 millisekunder och Prototype med 2.132 millisekunder. Efter det kom implementationen skriven med ren JavaScript på 1.382 millisekunder. AngularJS hade en genomsnittlig svarstid på 0.091 millisekunder. Den implementation som hade den snabbast genomsnittliga svarstiden var jQuery med 0.076 millisekunder.
Tabell 5‐ Resultat genomsnittliga svarstider
Ramverk Genomsnittlig svarstid (ms) Poäng
JavaScript 1.382 4
AngularJs 0.091 5
Dojo 14.533 1
25
jQuery 0.076 6
Mootools 2.73 2
Prototype 2.132 3
4.1.6 Sammanställning av resultat
I tabell 6 nedan har all data slagits samman och poäng summerats, poäng kan ses inom parentesen i blå text. Gällande Lint‐fel så gavs det inte ut några poäng, därav strecket inom parentesen.
Implementationen som fick sämst övergripliga resultat var den med ren JavaScript, med endast 7 poäng. Dojo fick 10, AngularJS 12, Prototype 14 och MooTools 17 poäng.
Ramverket vars implementation fick flest poäng var jQuery med 22 poäng.
Tabell 6 ‐ Sammanställning undersökning
Ramverk MI SLOC EstError LintError Svarstid Poäng
JavaScript 76.1 (1) 15 (1) 0.1 (1) 0 (‐) 1.382 ms (4) 7 AngularJs 86.31 (2) 12 (3) 0.08 (2) 0 (‐) 0.091 ms (5) 12 Dojo 92.86 (3) 14 (2) 0.04 (4) 0 (‐) 14.533 ms (1) 10 jQuery 93.64 (5) 5 (6) 0.02 (5) 0 (‐) 0.076 ms (6) 22 Mootools 94.16 (6) 6 (5) 0.04 (4) 0 (‐) 2.73 ms (2) 17 Prototype 93.02 (4) 10 (4) 0.06 (3) 0 (‐) 2.132 ms (3) 14
4.2 Poängsättning för vidare forskning
I undersökningen valdes det att poängsätta alla implementationerna på en skala mellan ett till sex. Implementationen som presterade bäst poängsattes högst och vice versa. När framställandet av rådata var färdig sammanställdes resultaten i olika tabeller, som redovisas i kapitel 4.1. För alla mätvärden kunde ett exakt svar levereras förutom på ett, Lint‐fel. Några Lint‐fel existerade inte i den kod som producerades för undersökningen. I undersökningen valdes det att tilldela implementationerna noll poäng, då det inte gick att särskilja dem för mätvärdet.
Mätvärdet ”Lint‐fel” borde ha blivit poängsatt med sex poäng, inte noll. Detta har
framkommit genom konstruktiv kritik på kandidatarbetet2. I framtida undersökningar, där
2 Mohammad Mustafa, konversation den 26 augusti 2016.
26 likadana mätvärden används, skulle inte resultatet från denna undersökning vara jämförbar.
Lint‐fel har behandlats i detta kandidatarbete som ett bortfall. Att inte de producerade några Lint‐fel borde ha resulterat i att de alla skulle fått högsta poäng, då noll Lint‐fel är ett bra värde.
Istället för att ändra kandidatarbetets resultat i efterhand kvarstår poängsättningen av Lint‐
fel. Den slutgiltiga poängsättningen skulle ha varit densamma, fast varje implementation skulle ha sex poäng mer. JavaScript skulle ha 13 poäng, AngularJS 18, Dojo 16, jQuery 28, MooTools 23 och Prototype 20.
Poängsättningen av ”estimerade antal fel” behövs även denna formas om. Gällande det mätvärdet visade det sig att två implementationer hade lika resultat. Då reducerades antal möjliga poäng med en, och högsta poäng var fem. Detta skedde då det var omöjligt att särskilja resultaten för korrekt poängsättning.
De slutsatser och analyser som dras i detta kandidatarbete påverkas inte av detta. Det som påpekas i detta kapitel uppmärksammas på grund av initialt i undersökningen var målet att generera resultat som skulle gå att särskiljas.
4.3 Analysering av resultat
I denna kandidatuppsats söktes det svar på hur implementationer med JavaScriptramverk presterar jämfört med en implementation skriven med ren JavaScript. Funktionaliteten som scripten utförde var kommunikation med en webbservice.
Fem olika frågor formulerades för att kunna besvara den huvudgripliga undersökningsfrågan i denna kandidatuppsats, där svaren på frågorna resulterade i exakta mätvärden. I
undersökningen användes ett analyseringsverktyg, Platojs (Overson et al. 2012). Med hjälp av Platojs kunde de olika implementationerna analyseras och mätvärde levereras. Frågorna och mätvärdena formulerades med hjälp av litteraturen som undersöktes i arbetet.
Mätvärdet gällande underhållbarhet var en skala mellan 0 och 100 där ett högt värde som möjligt var det bästa. Den implementation som presterade bäst gällande underhållbarhet var MooTools.
Nästa mätvärde var antal rader kod. Det önskvärda värdet är ett så lågt antal som möjligt eftersom det kan leda till bättre underhållbarhet (Ferrer et al. 2013). Implementationen med lägst värde var den skriven med jQuery, som endast hade fem rader kod.
Estimerade fel är även denna baserad på en skala där ett så lågt värde som möjligt är att föredra. Implementation som presterade bäst var den skriven med jQuery. Den hade endast 0.02 stycken antal estimerade fel.
När Platojs analyserade implementationerna fann den inte ett enda Lint‐fel. Lint‐fel är indikationer på att den syntax som används i implementationerna bör ses över (Crockford 2008). Skulle ett Lint‐fel producerats hade det analyserats i detta arbete. Eftersom det inte fanns några blir detta mätvärde ett slags bortfall. Det är dock inte ett bevis på att den kod som producerats är helt korrekt (Crockford 2008).
27 Genomsnittliga svarstider dokumenterades även i undersökningen, dock inte med hjälp av analyseringsverktyget Platojs (Overson et al. 2012). Detta skedde genom manuella
iterationer som dokumenterades. Implementation som hade sämst resultat var den
producerad med Dojo. Den hade en genomsnittlig svarstid på 14.533 millisekunder vilket är ett högt resultat jämfört med den som hade snabbast, jQuery på 0.076 millisekunder.
4.4 Hur ren JavaScript står sig mot ramverken
Implementationen med ren JavaScript behandlades på samma sätt som de med ramverk.
Vilket innebar att först undersöktes den officiella dokumentationen därefter producerades det ett script.
I den totala poängsättningen hade JavaScript 7 poäng. Implementationen presterade med lägst resultat på alla punkter förutom på svarstid, där Dojo hade högst genomsnittlig svarstid.
Resultaten visar värdet 76.1 i underhållbarhet. Detta indikerar på att implementationen med JavaScript är något som bör ses över (Welker 2001). I scriptet som producerades krävdes det 15 rader kod för den funktionalitet som krävdes av undersökningen. Detta kan vara en bidragande faktor till att underhållbarheten resulterade i ett lågt värde (Ferrer et al. 2013).
Implementation med Dojo hade även den ett högt antal rader kod. Underhållbarhetsvärdet var dock 92.86. Skillnaden mellan JavaScript och Dojo var de estimerade antal felen.
JavaScript innehöll 0.1 stycken och Dojo 0.04.
4.5 Bäst presterande implementationen: jQuery
Det ramverk vars implementation presterade med bästa resultat i undersökningen var jQuery. I poängsättningen fick implementationen 22 poäng. Scriptet hade den snabbaste genomsnittliga svarstiden av dem alla. Den enda punkten där jQuerys resultat inte var undersökningens bästa var underhållbarhet. Skillnaden mellan den bäst presterade
implementationen i underhållbarhet och jQuery kan ses som relativt liten. MooTools fick ett värde på 94.16, jQuery ett på 93.64. Det är alltså endast en skillnad på 0.52. Trots detta presterade jQuery med bästa resultat i denna undersökning.
4.6 Slutsats och sammanfattning
I detta kandidatarbete undersöktes det hur JavaScriptramverk presterade jämfört med ren JavaScript, baserat på utvalda mätvärden.
Den slutsats jag drar av resultatet är att implementationer skapade med JavaScriptramverk presterar bättre baserat på de mätvärden som användes i undersökningen. Med detta menar jag inte att script med ren JavaScript presterar med ett dåligt resultat, utan ramverks implementationer presterar bättre i undersökningens avseende.
Den bidragande faktorn, av resultatet att döma, är att mätvärdet ”estimerade antal fel”
verkat påverka resultatet på alla frågor förutom svarstid. JavaScript som fick sämst resultat innehöll 0.1 stycken antal estimerade fel samtidigt som jQuery innehöll 0.02 stycken.
JavaScripts underhållbarhet var 76.1, jQuery hade 93.64. Det som styrker denna slutsats är
28 resultatet från AngularJS. Den implementationen fick 0.08 stycken estimerade fel och ett underhållbarhetsvärde på 86.31. Prototype visade sig innehålla 0.06 stycken estimerade fel och hade ett underhållbarhetsvärde på 93.02. Här går det att se en tydlig korrelation mellan mätvärdet ”estimerat antal fel” och ett underhållbarhetsvärde. Ett lägre antal estimerade fel leder till en bättre underhållbarhet.
Snabbheten i exekvering av implementationerna ser inte ut att ha påverkat resultatet på något sätt. Det som styrker detta resonemang är antal rader kod. Implementationen med ren JavaScript innehöll 15 rader kod och exekveringen tog 1.382 millisekunder. I jämförelse med Dojo som innehöll 14 rader kod och en svarstid på 14.533 millisekunder. Skillnaden är endast en rad kod och 13.131 millisekunder i svarstid.
Resultaten visar att användandet av JavaScriptramverk ökar underhållbarhet och minskar antal estimerade fel. Antal rader kod ser inte ut att ha påverkat någon implementations resultat. Gällande Lint‐fel producerades det inte några. Vilket indikerar att dokumentation som granskats gällande ramverken, även den med ren JavaScript, har varit av värde (Jones 2007) och korrekt syntax används i scripten.
