RENDERING OCH MANIPULERING AV DOM
Undersökning av AngularJS och ReactJS
RENDERING AND MANIPULATION OF DOM
Examination of AngularJS and ReactJS
Examensarbete inom huvudområdet Datalogi Grundnivå 30 högskolepoäng
Vårtermin 2016 Erik Åstrand Handledare:
Examinator: Mikael Berndtsson
Sammanfattning
Webben växer och webbapplikationer blir mer och mer komplexa och innehållsrika.
Med detta så ska dessa växande applikationer även kunna presenteras på ett tilltalande och effektivt sätt. Jättarna Facebook, Twitter, Instagram och små bloggar har alla börjat använda sig av en teknik för att kunna dynamiskt ladda in ytterligare innehåll på en sida utan att behöva ladda om den. Denna teknik kallas för Infinite Scroll eller oändlig scrollning. Infinite Scroll kan resultera i enormt stort innehåll vilket tidigare studier visar på att det bidrar till bristande prestanda för rendering och manipulering av innehållet. Arbetet kommer utföra ett experiment där målet är att undersöka hur två populära SPA-ramverk AngularJS och ReactJS hanterar detta problem.
Nyckelord: Infinite Scroll, AngularJS, ReactJS, DOM
Innehållsförteckning
1. Introduktion ...1
2. Bakgrund ...2
2.1. Single-Page Application ...2
2.1.1. AngularJS 3 2.1.2. ReactJS ...4
2.2. Infinite Scroll ...5
3. Problemformulering ...7
3.1. Metodbeskrivning ...7
3.1.1. Experiment ...7
3.1.2. Alternativa metoder ...8
3.1.3. Metoddiskussion ...8
3.1.4. Forskningsetik ...9
4. Genomförande ...10
4.1. Förstudie ...10
4.2. Progression ...10
4.2.1. Grundstrukturen ...10
4.2.2. Manipulering av DOM ...13
4.2.3. AngularJS ...13
4.2.4. ReactJS ...15
4.3. Pilotstudie ...17
4.3.1. Specifikationer ...17
4.3.2. Resultat av pilotstudie ...17
5. Utvärdering ...19
5.1 Presentation av undersökning ...19
5.2 Analys ...19
5.2.1 Mätning av webbläsare ...19
5.2.1.1 Rendering ...19
5.2.1.3 Slutsats ...23
5.2.2 Mätning av ramverken ...24
5.2.2.2 Slutsats ...26
5.2.2.3 Manipulering ...26
5.2.2.4 Slutsats ...28
6. Avslutande diskussion ...30
6.1 Sammanfattning ...30
6.2 Diskussion ...30
6.3 Framtida arbeten ...31
Referenser ...33
1. Introduktion
Den snabbt ökande mängden av media och data som används på webben idag öpnnar upp nya utmaningar för webbutvecklare att på bästa sätt presentera innehållet. Zapeda & Chapa (2007) hävdar att under de senaste åren så har webbutvecklare börjat titta på olika sätt att hantera detta på ett effektivt sätt och kunna presentera det för användaren. Single-Page Application (SPA) är ett sätt att strukturera en webbsida så att allt innehåll finns på en och samma sida vilket eliminerar behovet av att ladda om sidan när ytterligare innehåll måste läggas till. I arbetet ska vi titta närmare på två populära SPA-ramverk AngularJS och ReactJS, skapade av Google och Facebook. Infinite Scroll eller oändlig scroll är en teknik för att dynamiskt ladda in ytterligare innehåll på en sida och skapa en oändlig ström av innehåll.
Infinite Scroll användas på populära sociala medier som Facebook, Twitter och Instagram för att hantera deras enorma flöden och presentera det på ett effektivt sätt för användaren (Koukouletsos, Moustris & Paliatsos, 2014).
Zhu & Reddi (2013) menar på att DOM (Document Object Model) har ett problem att hantera trädstrukturer av ökande storlek och det är just detta som Infinite Scroll gör.
AngularJS och ReactJS hanterar rendering och manipulering av DOM på två olika sätt där AngularJS har en mer konservativt tillvägagångssätt medan ReactJS använder sig av en teknik kallad Virtuell DOM.
Arbetet kommer utvärderas med ett experiment som undersöker hur laddningstiden för rendering och manipulering av ett ökande DOM-trädstorlek hanteras av de både SPA- ramverken. Arbetet tar inspiration för experimentet av en tidigare studie utförd utav (Zhu &
Reddi, 2013) där man undersökte hur ökande trädstorlek av DOM påverkade laddningstiden för rendering och manpulering av DOM.
2. Bakgrund
2.1. Single-Page Application
Zapeda & Chapa (2007) menar att Multi-Page Applications (MPA) eller den klassiska strukturen för en webbapplikation kräver oftast en förfrågan av användaren genom en länk eller formulär för att sedan behöva vänta på att webbservern skall svara. Efter att servern har skickat tillbaka en ny sida till klienten så uppdateras sidan med den nya informationen (Se Figur 1). Problemet med denna klassiska MPA-modellen är att sidan behöver laddas om på detta vis varje gång användaren begär ny information. Detta leder till bristande prestanda, överdriven bandbredd, begränsad interaktivitet och redundant programmeringskod.
De senaste åren har modern webbutveckling försökt eftersträva klassiska desktop- applikationernas mer naturliga designmodell där användargränssnittet är integrerat i ett enda fönster. I motsats till MPA där man har flera sidor som har sin egna information på varje sida så har man endast ett fysiska fönster där man dynamiskt laddar in ny information vid behov. Denna designmodell har en betydligt bättre användbarhet då man får en mer interaktiv applikation med snabbare responstider och laddningstider samt bekvämare navigering (Tesařík, Doležal & Kollmann, 2008). Adaptionen av denna designmodell till webben fick namnet Single-Page Applications (SPA).
Februari 2005 i artikeln ”AJAX: A New Approach to Web Applications” så myntades termen AJAX (Asynchronous JavaScript and XML) av Jesse James Garrett. Ett väldigt stort intresse för AJAX uppstod efter artikeln blev publicerad och man började snabbt utforska vilka möjligheter som kom med AJAX. Detta var inte ett nytt programmeringsspråk eller teknik utan det var mer ett nytt sätt att designa och utveckla webbapplikationer. AJAX byggde på existerande tekniker som HTML, DOM, XML och XHR. AJAX fungerar som ett tredje lager mellan klienten och servern som gör det möjligt att implementera denna SPA-modell på webben. AJAX kan i bakgrunden kommunicera med servern för att sedan skicka vidare information till klienten och dynamiskt ändra informationen på en sida, vilket tar bort behovet av att ständigt ladda om sidan (Zapeda & Chapa, 2007). Se Figur 1 för visualisering av asynkron server/klient-interaktion.
! 2 Figur 1
Synkron(MPA) & asynkron(SPA) klient/server-interaktion
2.1.1. AngularJS
Angular är ett open-source SPA-ramverk utvecklat av Google och är uppbyggt med en MVC (Model-View-Controller) arkitektur. Angular har över de senaste åren blivit ett populärt val för att snabbt skapa dynamiska HTML-sidor och etablerat sig som det mest populäraste SPA-ramverket enligt Google Trends, sökresultat och Github-aktivitet. (Scully, Fraunhofer &
Jung, 2015) hävdar att en av teknikerna som förenklar implementationen av SPA är en teknik kallad data-bindning som Angular använder. Data-bindning i Angular fungerar som så att en modells data är direkt bunden till element i motsvarande vy. Om data ändras i modellen så ändras det även direkt i den motsvarande vyn och vice-versa om ändringar sker i vyn så ändras även modellen. Denna typ av länkning gör att det inte är någon direkt DOM- manipulering så som i jQuery. Angular har istället introducerat något som kallas för direktiv där man kan direkt binda ett element med en modell.
Figur 2: Kodexempel över data-bindning med AngularJS
I Figur 2 så visas hur en simpel data-bindning fungerar i Angular. Här så binder vi input- elementet i vyn till en model (myName) och Angular förstår nu om användaren ändrar värdet i input-elementet så uppdateras detta värde i motsvarande modell (myName) och skriver ut värdet från modellen med ”{{myName}}”. Figur 3 visar kontrastet till jQuery där varje interaktivt DOM-element, så som ett input-element, har lyssnare som reagerar på när ett event har inträffat och i sin tur kör igång funktioner i respons. I exemplet med Angular så har vi ingen direkt interaktion med JavaScript vilket gör att vi får betydligt mindre redundant kod.
Figur 3: Kodexempel över data-bindning med jQuery
2.1.2. ReactJS
ReactJS är ett annat SPA-ramverk som FaceBook skapat för användning på sin egna plattform och blev i maj 2013 open-source. React använder en arkitektur som liknar det som omnämns som one-way dataflow och enligt Demetrescu, Finocchi & Ribichini (2011) innebär det att datan endast strömmar en väg. Datan kan bara föras åt ett håll igenom olika lager med sitt egna ansvarsområde och datan kan endast åka från förälder till barn och inte tillbaka. I AngularJS kan datan däremot skickas åt båda håll eftersom varje DOM-element har en direkt motsvarande hanterare i modellen. När ett DOM-element ändras i vyn så ändras det direkt i modellen och vice-versa, denna struktur kallas för två-vägs strömning av data (T. Scully, 2015). I kontrast till AnglarJS hanterar man DOM mer reaktivt i React. När ett DOM-element har ändras registreras detta genom event för att sedan avgöra vad som ändrats och till slut renderar ändringen i vyn, en vägs strömning av data (Salvaneschi, Margara & Tamburrelli, 2015). Se Figur 4 för exempel över hur en komponent i React skapas och hur man hanterar uppdatering av den komponenten.
Figur 4: Kodexempel över data-bindning med ReactJS
För att effektivisera denna reaktiva process så har React implementerat en annat teknik för att hantera DOM kallad “Virtuell DOM” (Virtual DOM). Psaila (2008) menar att Virtuell DOM är en teknik för att skapa en abstrakt representation av den aktuella DOM och används för att spåra och uppdatera ändringar i DOM. Virtuell DOM används som en representation av DOM och när en ändring i DOM har skett så avgör man vad ändringen var genom att jämföra representationen av den tidigare oförändrade DOM med den nuvarande förändrade DOM och sedan rendera ut ändringen i det verkliga DOM. Detta leder till att det går betydligt snabbare att avgöra vart ändringen skett och vilken data som ändrats eftersom man arbetar med en virtuell representation av DOM snarare än att direkt jobba med DOM. DOM har alltid haft problem med att lagra stor mängd data i minnet och framförallt hålla reda på en stormängd DOM-element. Denna teknik utesluter detta problem eftersom DOM inte behöver oroa sig över vilka element som hör ihop utan behöver bara rita ut det på sättet som Virtuell DOM säger.
! 4
2.2. Infinite Scroll
Webbplattformer som FaceBook, Twitter och Instagram har under de senaste åren utvecklats väldigt mycket och är nu mer komplexa, innehållsrika och användbara. Dessa tjänster har ett behov att kunna hantera väldigt stora mängder information och samtidigt visa det på ett bra sätt för användaren. Med den mobila revolutionen medföljde ett behov från användaren på en högre standard för design och bekvämlighet (Zhu & Reddi, 2013). Ett utav dessa behov var att kunna få in så mycket innehåll som möjligt på en och samma sida för att användaren inte skulle vara tvungen att ladda om sidan för att få in ytterligare innehåll. Det skulle inte fungera att ladda in t.ex. FaceBooks hela flöde vid initiala renderingen av sidan. Så man delade upp flödet i delar där man laddar in en liten del av flödet först och sedan när användaren gått igenom det stycket så laddas en ytterligare del av flödet. Denna teknik för scrollning har fått namnet Infinite Scroll eller oändlig scrollning och är en teknik för att dynamiskt ladda in nytt innehåll när användaren når botten av sidan för att undvika så kallad paginering där man kommer till en ny sida för att ladda in ytterligare innehåll (Breton, Bergeron & Hallé, 2015). Infinite Scroll används i praktiken väldigt ofta i bloggplattformer, sociala medier och E-handelssidor för att ge användaren uppfattningen av en oändlig ström information.
Infinite Scroll är en teknik som har sina för- och nackdelar och studier visar på att det i vissa fall undvikas. Koukouletsos, Moustris & Paliatsos (2014) hävdar att ur ett användbarhets perspektiv så har Infinite Scroll specifika tillämpningsområden där innehållet flödar i en kontinuerlig ström. Några exempel på tjänster som använder sig av denna teknik är bland annat FaceBook, Twitter och Instagram. Dessa är perfekta tillämpningsområden då man vill ha kvar användarens sin plattform så länge som möjligt och Infinite Scroll gör så att användarens inte tröttnar på att behöva ladda ny sida för att fortsätta i flödet.
Infinite Scroll är ett intressant forskningsområde då ingen direkt forskningsundersökning ur ett prestandaperspektiv har gjorts inom området. Infinite Scroll handlar som sagt om att dynamiskt ladda in nytt innehåll på en sida när användaren har gått igenom det förrenderade innehållet. Denna studie är relevant inte bara för att se hur implementationen av Infinite Scroll hanteras av de både SPA-ramverken Angular och React. Utan även för hur de både ramverken hanterar rendering och manipulering av DOM vilket är en oerhört viktig egenskap för SPA.
Figur 6: Visualisering över paginering kontra Infinite Scroll
! 6
3. Problemformulering
Enligt Zhu & Reddi (2013) så blir webben mer och mer användbar och webbapplikationer mer interaktiva och komplexa. Med den ökade komplexiteten i webbapplikationer så medföljde problemet att hantera denna ökande komplexitet och inte få för höga laddningstider i applikationerna. Laddning- och renderingstid är viktigt att fokusera på som webbutvecklare eftersom användaren har dåligt tålamod, framförallt mobila användare.
Studier visar på att användaren förväntar sig att en sida ska vara laddat inom två sekunder och 40% av användarna vägrar vänta längre än tre sekunder innan dom lämnar sidan (Mickens, 2010).
Det finns olika orsaker till varför laddningstiden är problematisk och det problem vi ska undersöka närmare på är själva DOM-rendering i en webbapplikation. Zhu & Reddi (2013) gjorde ett experiment där man undersökte hur laddningstiden påverkas av ökande storlek på DOM-trädet. De kom fram till att när DOM-trädet expanderar så påverkas laddningstiden av applikationen negativt. Arbetet ska utföra ett liknande experiment med en addition utav att testa manipulera denna data för att bäst simulera Infinite Scroll. Om man tar Twitter som exempel så lägger man dynamiskt in ny information med Infinite Scroll, men alla tweets är inte statiska efter det. Om användaren har gått igenom ett långt flöde och börjar bygga upp ett stort DOM-träd är det intressant att se hur de både ramverken hanterar ändringar längre upp i flödet. Artikeln siktar på att besvara frågan om Angular eller React är ett svar på detta rendering och manipulering problem man har med DOM och vilket ramverk och efterfrågas i olika situationer.
Hypotesen är att ReactJS skall hantera rendering och manipulering av DOM-träd med ökande storlek bättre än AngularJS och jQuery i form av laddningstid.
3.1. Metodbeskrivning
3.1.1. Experiment
För detta arbete kommer ett experiment användas som utvärderingsmetod för att få en mer kontrollerbar miljö där man på bästa sätt kan bekräfta hypotesen och säkerställa att mätningen är korrekt. Experimentet kommer utföras på tre olika simuleringar av Infinite Scroll gjorda i jQuery, AngularJS och ReactJS med jQuery som baslinje för experimentet.
Experimentet siktar på att försöka besvara hypotesen som är att ReactJS skall prestera bättre än baslinjen och AngularJS i form av laddningstid av rendering och manipulering av DOM.
Psaila (2008) utförde en liknande experiment där de undersökte hur DOM och Virtuell DOM hanterade ett ökande antal DOM-element. I experimentet så gjordes iterationer av DOM- laddning och tittade på vilka situationer som DOM hanterade bra och vilka DOM hanterade mindre bra. De variabler man tittade på var dels laddningstiden för rendering och manipulering av DOM men även hur ökande antal DOM-element påverkade minnet.
Undersökningen i denna artikel kommer ta inspiration utav Psaila (2008) och utföra ett liknande experiment men med några justeringar. Den stora justeringen är att istället för att ha ett statiskt bestämt antal DOM-element som renderas och manipuleras så skall testapplikationen tillåta att DOM-element dynamiskt läggs till efter initiala rendering för att kunna simulera en mer verklig miljö för Infinite Scroll.
3.1.2. Alternativa metoder
Enligt Wohlin (2014) finns det olika metoder för att utvärdera arbeten och vilken metod som väljs skall anpassas efter vilka behov utvärderingen av arbetet har. De olika metoder som finns att välja mellan är användarstudier, fallstudier och experiment. Användarstudiers huvudsakliga medel för att samla in kvalitativ eller kvantitativ data är genom intervjuer och frågeformulär vilket bidrar till att man får en minskad kontroll över utförandet och mätning av studien. Användarstudier är bra när man snabbt vill försöka besvara många frågor eller eftersträvar många utvärderingsvariabler och datainsamlingen är ofta baserad på åsikter och tycke.
Den andra alternativa metoden är fältstudier och Wohlin (2014) menar på att fältstudier används för att i en tidsram undersöka en entitet eller fenomen i sin verkliga miljö.
Fältstudier och experiment är relativt lika metoder då de båda är utforsknings metoder där man förändrar beteenden och ser hur de reagerar. Men skiljer såg åt just under detta faktum att i en fältstudie så observerar man en entitet eller fenomen i en verklig miljö. I kontrast till detta så behöver man med experiment inte använda någon verklig miljö utan kan ändra variablerna fritt och se vilket resultat man får ut. Fördelen med fältstudier är att de är lättare att planera och mer realistiska, men nackdelen är att resultaten från studien är svåra att generalisera och tolka eftersom man inte kan modifiera variablerna och kan göra mindre uteslutningar. T.ex. om undersökningen använde Twitter som testapplikation för Infinite Scroll så kan vi inte utesluta att det inte är Twitter som manipulerar resultaten av studien.
Baserat på överstående så blir det svårt i arbetet att använda användarstudier eller fältstudier. Användarstudier som baseras på användarens tycke kommer inte fungera då användaren inte har en möjlighet att uppfatta de olika laddningstiderna. Och en fältstudie kommer inte fungera eftersom det inte finns tillgång till att undersöka en applikation i sin verkliga miljö och risk för att resultatet inte kan tolkas.
3.1.3. Metoddiskussion
Experimentet för detta arbete kommer undersöka om AngularJS eller ReactJS har en snabbare laddningstid för rendering och manipulering av DOM än baslinjen jQuery.
Undersökningen kommer först mäta laddningstiden för rendering av DOM och sedan kolla på laddningstid för manipulering av DOM. Laddningstiden definieras som den tid det tar för DOM att rita upp alla element, en start punkt innan rendering och en sluttid efter rendering är färdig. Denna mätning kommer ske på tre konstruerade applikationer kodade med de två SPA-ramverken AngularJS och ReactJS samt JavaScript-biblioteket jQuery. Efter insamlad data kommer mätdatan jämföras med varandra. Webbläsarna Chrome, Firefox och Safari kommer användas under testerna för att kunna få ett mer genuint resultat än om testerna endast gjordes på en webbläsare.
På grund av bristande tillgång till större sortiment av testenheter så kan problem uppstå med experimentet med att man inte får ett generaliserat resultat eftersom inte alla operativsystem eller webbläsaren kommer testas. Så det finns risk för att datan visar en sak men skulle visa ett annat resultat på andra enheter eller webbläsare. Experimentet kommer även ske online och enligt Wohlin (2014) så kan online experiment vara problematiskt då man får en försämrade kontroll över undersökningen då man inte riktigt kan utesluta faktorer som kan förvränga resultatet, som t.ex. nätverksbelastning.
! 8
3.1.4. Forskningsetik
Enligt Cai, Nerurkar & Wu (1998) så är datan från många mätningar korrupt och för att undvika detta så skall mätningen vara optimal genom att inte ha potentiella skadliga faktorer som dålig kod eller plugins samt mätningen skall gå att återupprepa. Mätningen i detta arbete kommer gå att återupprepa eftersom jQuery, AngularJS och ReactJS alla har stöd för de populäraste webbläsarna (Chrome, Firefox, Safari, Internet Explorer 8+, Opera).
Mjukvaru- och hårdvarukonfigurationer som används för mätningen kommer även dokumenteras eftersom det är även viktigt för att skapa en studie som går att återupprepa.
Arbetet strävar efter att ha optimal kod genom att undvika ”död kod” och genvägar. Det är även viktigt att väl dokumentera mjukvaru- och hårdvarukonfiguration och detta
Experimentet kommer inte involvera några testpersoner så det finns inga risker för oetisk hantering av känsliga personuppgifter. Datan som kommer användas under mätningen är ingen data som är verklig utan kommer vara helt slump genererad.
4. Genomförande
4.1. Förstudie
Innan konstruktionen av webbapplikationen så utfördes en förstudie för att kunna få mer inspiration, idéer och bättre förståelse om de områden som studien tar upp. Både ReactJS och AngularJS är två väldigt populära ramverk och har mycket intresse omkring sig ifrån webb-samhället. Hunt (2016) har varit en stor kunskapskälla för att få en djupare inblick inom ReactJS och hur dess komponenter arbetar ihop.
Eftersom både ramverken är väldigt populära så var det inga problem att hitta andra studier inom ramverken. De flesta studiers fokus var att utsätta dom för utmaningar som man inte direkt ser i verkligen och se hur de presterar. Valet togs att ta detta till en mer verklig testmiljö och försöka efterlikna en applikation som faktiskt skulle kunna existera. En av de studier som jag utforskade var Miles (2016) och där gjorde man ett experiment vars mål var att se hur Angular, React och jQuery stod emot varandra i en testmiljö som inte eftersträvar verkligheten. Man genererade en tabell med önskad storlek och mäter sedan tiden varje ramverk utför denna rendering. Denna studie kommer till slutsatsen att både Angular och React skall vara ganska jämna men skall prestera betydligt bättre än jQuery. Intresset ligger i att se om denna studie och liknande studier visar liknande resultat som min studie som är i en mer verklig miljö.
Inspirationen för själva applikationen är tagen från Twitter (2016) då jag såg deras applikation som perfekt att utföra detta experiment på. Twitter utsätts, likt Facebook, för denna översvämning av DOM-element. En användare scrollar och scrollar och förstorar i processen DOM:en. Så mycket fokus ligger i detta fall på skalbarhet och att applikationen skall tåla att hantera ändringar i ett DOM-dokument bestående av över en miljon element.
4.2. Progression
Under denna del så kommer stegen som tagits för att komma fram till den slutliga applikationen vars mål är att söka efter svar på hypotesen.
4.2.1. Grundstrukturen
Den första versionen av applikationen eftersträvade att få ut ett grafiskt gränssnitt över hur applikationen skulle se ut. Eftersom Twitter var målet tidigt så eftersträvades en nära replikation över Twitter’s gränssnitt. Se Figur 7 för applikationens grundstruktur.
! 10
Figur 7
Gränssnitt för grundstruktur
Gränssnittet har använt sig utav ett CSS-bibliotek som heter Bootstrap för att få lite hjälp designen. Första versionen av applikationen utfördes med jQuery för att det var mer familjärt och lättare att utveckla en grundstruktur på. Jag valde att implementera en liten sektionen i applikationen som visar resultatet. Det visar hur många tweets som renderades, hur många totala DOM-element samt givetvis hur lång tid det tog för renderingen. Även en knapp med en dropdown-meny för att enkelt kunna rendera önskat antal tweets och en knapp för att manipulera DOM men denna funktionalitet var inte implementerat i denna version. Design-mässigt så har det inte varit någon direkt vidare utveckling av applikationen eftersom målet med designen var förförstått innan studien började.
Ur ett back-end perspektiv så började alla tweets med statisk data, det vill säga att alla tweets hade samma innehåll. Men återigen för att skapa en mer verklig applikationen så behövde datan var slumpmässig. Brohede (2016) användes som inspiration för hur man kunde generera dessa slumpmässiga tweets. En JavaScript-fil skapades för att lagra alla dessa 50 000 tweets. Detta gör nu att denna fil kan återanvändas i de andra applikationen med React och Angular så alla jobbar med samma data för att utesluta att datan påverkar mätningen. Se Figur 8 byggnaden av dataobjektet med tweets går till.
! 12 Figur 8
Uppbyggnad av dataobjektet innehållande tweets Börja skriv för att lägga in text
Ett stort problem under utvecklingsprocessen var hur man skulle mäta start- och sluttid för mätningen. jQuery’s html-funktion används för att rendera ut HTML så den första versionen av mätningen bestod utav en starttid innan html-funktionen och en direkt efter slutfunktionen. Detta fungerade bra för att mäta själva exekveringen av html-funktionen men den mätte inte hur lång tid det tog för DOM att rendera. Anon (2016) gav inspiration för hur man kunde mäta när DOM var färdig renderat och DOM var redo för användning och svaret på detta var JavaScript-funktionen window.onload. Denna funktion drogs som slutsats att den ligger närmast självaste slutpunkten för rendering. Skiftade mätningsfunktion från date.now till performance.now då enligt StackOverflow (2015) skall vara en mer precis funktion för mätning. Se Figur 9 för kod över renderingsfunktionen.
Figur 9 Rendering av tweets
4.2.2. Manipulering av DOM
Manipuleringen av DOM:en efter rendering var ett dilemma, dels vad som skulle manipuleras och hur de skulle manipuleras var oklart. Varje tweet har en “like”-räknare (Se Figur 7) och den första versionen av manipuleringen bestod utav att en slumpmässig tweet fick sina likes ökade med ett. Men denna typ av manipulering visade bara på hur bra de olika ramverken egentligen var på att leta upp denna slumpmässiga tweeten, inte hur bra de är på att hantera ändringar i DOM:en. Så manipuleringen var tvungen att få en bredare skala och började istället kolla på om dessa slumpmässiga tweeten fick sitt text-innehåll redigerat och hur de reagerade på detta.
Detta visade sig även inte vara något vidare problem att hantera och började istället titta på att öka antalet tweets som blir redigerade för att skapa ett mer verkligt scenario. Om en användare har renderat ut över 10 000 tweets så är det inte riktigt sannolikt att endast en tweet ändrats. Så den slutliga formulan för antalet tweets som skall manipuleras är tio procent av det antal tweets som är renderade. Om 1 000 tweets har renderats så skulle 100 manipuleras. Slutliga manipuleringen ser ut så att tweets får sin text ändrad till en “Lorem Ipsum” snutt och dess bakgrundsfärg ändras för att markera ändringen. Valet för att använda en statiskt text som “Lorem Ipsum” är för att kunna utesluta att olika mätningar får jobbigare text-strängar att hantera.
4.2.3. AngularJS
Angular har ett annorlunda tillvägagångssätt där man jobbar med datan direkt i vyn (HTML). Angular har inte direkt något stöd för att leta upp element och göra ändringar i dom, vilket är lösningen på DOM-manipulering i jQuery. AngularJS använder sig av som tidigt nämnt två-vägs dataström, det vill säga att datan i kontrollern och vyn är direkt kopplade till varandra. Om ena ändrar beteende eller värden så ändras även den andre. Se Figur 10 där datan med tweets skickas till vyn med Angular’s Scope-funktion och öppen för användning i vyn.
För mätningen i Angular så har den första versionen använt Angular’s funktion postDigest som slutpunkt för rendering (Se Figur 10). Digest är en funktion som håller koll på Angular’s processcykel och postDigest är en slutpunkt för när man är i slutet på denna processcykel. Detta resulterade tyvärr i samma problem som med jQuery att det endast är en slutpunk för exekveringen av koden och inte för renderingen.
Figur 10
Kontroller för kommunikation till vyn i AngularJS
! 14
För att lösa detta så togs inspiration utav Langton (2014) och skapade ett direktiv för “ng- repeat”, det är en form av lyssnare som under själva utskriften så görs en koll och ser vart i renderingen man befinner sig (Se Figur 11). “if (scope.$last)” är en koll för att se om sista tweeten har renderas ut. Detta har varit den punkt som varit närmast den faktiskt slutpunkten för rendering.
Figur 11
Ett direktiv som ser över mätningens start- och slutpunkt
Med detta i åtanke så gjordes en koll under “ng-repeat” med Angular’s “ng-if”-funktion (Se Figur 12). Hur hela denna funktionalitet fungerar är att knappen “Manipulate DOM” har en lyssnare så när knappen trycks så körs buttonClicked-funktionen. Denna funktion genererar en array med ett antal slumpvis valda siffror beroende på hur många tweets som har renderas. Så när knappen tryckts och arrayen skapats så börjar Angular köra sin ng- repeat, vilket är en form av foreach-loop som loopar igenom varje index i en array (item in data). Om en index i denna ng-repeat har samma index som ett av värdena i denna genererade array så manipulerar vi innehållet för denna tweet.
Figur 12 Vyn för Angular
4.2.4. ReactJS
ReactJS är mer likt jQuery på det sättet att de båda har en-vägs dataström. Det vill säga att datan kan inte skickas åt båda hållen, från vyn till modell och vice versa. React använder sin egna funktion ReactDOM för att skriva ut innehåll till vyn. När man använder ReactDOM så lagras även detta i den tidigare nämnda Virtuella DOM. Detta gör att React lättare kan hantera ändringar i DOM eftersom man har en abstrakt kopia av den verkliga DOM i JavaScript.
Förstudien i React gav uppfattningen om att React endast uppdaterar DOM om det är så att ett så kallat tillstånd har ändrat värde eller beteende. Dessa tillstånd har lyssnare som reagerar när de ändras och resulterar i att React börjar om sin cykel. I Figur 7 så visas det hur en av dessa tillstånd deklareras med hjälp utav React’s getInitialState().
Figur 13
Deklaration utav tillstånd
ReactDOM är på ytan lik jQuery’s html-funktion med att de båda skriver ut till html. Med åtanke på hur mätningen gick i jQuery när mätningen cirkulerade runt html() och dess exekvering så antogs att samma resultat skulle komma ifrån React. Men med närmare undersökning i ReactDOM så visade det sig att denna funktion inte fungerade på samma vis som jQuery och kunde faktiskt användas som mätningspunkt. I Figur 8 så visas det hur starttiden kan börja precis innan exekveringen av ReactDOM och en sluttid direkt efter. Detta visade sig efter tester vara den mätpunkten som var mest precis.
Figur 14
Mätning av DOM rendering
! 16
För mätningen över manipulering togs inspiration utav Heath (2015) och framförallt React’s didComponentUpdate-funktion som körs igång direkt när en komponents uppdateringar har renderats i DOM. Detta var den perfekta funktionen för att använda som sluttid vilket även tester visade. Denna funktion skall endast köras efter manipuleringen för att avgöra vilken komponent det är som har uppdateras så implementerades en if-sats (Se Figur 9) som kollar om lorems-arrayen inte är tom. Om den inte är tom, det vill säga att manipuleringsknappen har tryckts och vi förväntar oss en manipulering av DOM så görs en ytterligare koll om DOM är redo och har renderas så vi slutligen kan lagra sluttiden. Dessa if-satser kompletterande comonentDidUpdate för att få en ännu mer precis sluttid.
Figur 15
Funktion för att beräkna när manipuleringen är färdig
4.3. Pilotstudie
En pilotstudie utfördes för att kunna se om mätningen var funktionell innan nästa steg i att försöka besvara hypotesen utförs. Pilotstudien undersöker om mätningen fungerar på olika webbläsare och ramverken. Studien utför en mätningen på de tre olika ramverken jQuery, Angular och React. Mätningen sker genom tio iterationer av rendering samt manipulering av 10 000 och 50 000 tweets.
4.3.1. Specifikationer
Mätningen utfördes på en MacBook Pro (Retina, 13-tums, 2015 kollektionen) och följande specifikationer:
- Webbläsare
- Google Chrome, Version 49.0.2623.112 (64-bit) - Mozilla Firefox, Version 45.0.2 (64-bit)
- Apple Safari, Version Version 9.1 (64-bit) - CPU: 2,7 GHz Intel Core i5
- Minne: 8 GB 1867 MHz DDR3
- GPU: Intel Iris Graphics 6100 1536 MB 4.3.2. Resultat av pilotstudie
Figur 16 Resultat för rendering
Figur 16 visar resultatet ifrån pilotstudien för rendering av tweets. Undersökningen utfördes i tio iterationer där först 10 000 tweets renderades och dess individuella renderingstid lagrades. Efter de tio iterationerna var färdiga så skapades ett genomsnittligt värde för de tio iterationerna. Detta är värdet som resultatet visar och samma process utfördes för 50 000 tweets. Renderingstiden defineras från den punkt mellan där renderingen börjar och slutar.
Resultatet från renderingsundersökningen visade sig intressant då jQuery hade en snabbare renderingstid än React. Detta skall vidare studieras i nästa steg för att kolla om jQuery är det bästa alternativet för rendering eller om det är så att jQuery’s skalbarhet är bistande.
Angular’s resultat var inte överraskande på grund av dess två-vägs dataström. Angular har betydligt mer lyssnare och element som behöver bindas ihop.
Figur 17 visar resultatet ifrån manipuleringen av 10 000 och 50 000 tweets. Processen för undersökningen utfördes på samma vis som för renderingen med tio iterationer vardera.
Resultatet från denna undersökningen börjar visa mönster på möjligheten att besvara hypotesen. Skalbarheten är uppenbarligen ett problem för jQuery att hantera medans React och Angular hanterar detta betydligt bättre. Vidare undersökningen inom detta så kommer mindre värden som 100, 1 000 och större 100 000 testas och kolla närmare på vilket ramverk som föredras i de olika storlekskategorierna.
Undersökning i hur valid mätningen är kommer även utföras i nästa steg för att kunna utesluta att mätningen visar korrupt data.
! 18 Figur 17
Resultat för manipulering
5. Utvärdering
5.1 Presentation av undersökning
Detta kapitel presenterar undersökningen som har utförts för att försöka svara på hypotesen.
Undersökningen bestod utav mätningar på de tre applikationerna konstruerade i jQuery, Angular samt React. Mätningarna utfördes på tre populära webbläsare som var Safari, Google Chrome och Mozilla Firefox. Alla mätningar utfördes på en MacBook Pro 2015 (Se kapitel 4.3.1 för specifikation).
Den slutliga mätningen använder samma upplägg som pilotstudien. Där varje applikation mäts i iterationer av 100 med ökande antal DOM-element. De storlekskategorierna som har används för mätningen är 100, 1000, 10000 och 50000. För att kunna få ett bättre svar på hypotesen så dessa tre olika webbläsare används för att kunna utesluta att mätningen endast svara på hypotesen för en viss webbläsare.
Undersökningen kommer presenteras med diagram över hur varje webbläsare hanterar ramverken samt hur ramverkens rendering- och manipuleringstid står sig emot varandra.
5.2 Analys
5.2.1 Mätning av webbläsare 5.2.1.1 Rendering
I detta kapitel så ska vi undersöka på hur ramverken presterar i olika webbläsare och leta efter mönster över webbläsarna hanterar dessa ramverk. Kan det t.ex. vara så att en webbläsare är betydligt bättre för ett ramverk? Eller någon webbläsare som hanterar manipulering bättre?
Figur 18 visar resultatet ifrån mätningen av jQuery-applikationen i olika webbläsare. Här ser vi att Safari är den snabbare webbläsaren för rendering i detta testfall. Chrome är väldigt nära samma tider som Safari fram tills då vi kommer till 10 000 och över. Då börjar Safari dra sig ifrån Chrome, vilket tyder på att Safari i detta fall har en bättre skalbarhet än konkurenterna. Resultatet av detta var ganska väntat eftersom Safari är mer anpassat för testdatorn men kunde inte förutspå att skillnaderna skulle vara så markanta. Skulle vara intressant att se hur detta spelade ut sig på ett Windows-system, misstänker att Safari kommer hamna på andra sidan av diagrammet och prestera sämst.
Figur 19 visar resultatet ifrån samma mätningen fast med Angular istället för jQuery. Här så ser man snarlika mönster med hur Firefox ligger efter de andra webbläsarna och Safari betydligt bättre. Det som skiljer sig för Angular är att Chrome lyckas inte hänga med Safari lika bra som med jQuery. I denna mätningen så har Safari dubbelt så snabbt renderingstid när man kommer över 10 000 renderade tweets.
Testfallet för Angular visar återigen på hur Safari dominerar de andra webbläsarna när det kommer till rendering och det är inte förens mätningen över React som denna dominans börjar skifta. I Figur 20 så ser vi hur React presterar bäst i Chrome med Safari på andra plats. Alla tre webbläsare ligger extremt nära varandra upp till 10 000 och ser hur Firefox för första gången är snäppet snabbare fram till detta steg.
Vad dessa mätningen ger som slutsats är att Safari överlag är den webbläsaren att föredra för rendering av ökande antal DOM-element med specifikationerna som används för
!
20 Figur 19
Rendering med Angular i olika webbläsare Figur 18
Rendering med jQuery i olika webbläsare (x=antal tweets,y=millisekunder)
mätningarna. Samt att React är mer anpassat för Chrome än någon annan webbläsare. För att kunna utesluta att mätningen inte favoriserar Safari på grund av testenheten så måste en liknande undersökningen utföras på flera enheter.
5.2.1.2 Manipulering
Mätningarna över hur de olika webbläsarna hanterade ramverken för rendering visade på att Safari var den webbläsaren att föredra för jQuery och Angular, men att Chrome var det bättre alternativet för React. För att kunna göra en mer precis undersökning så utfördes även samma undersökning på hur ramverken hanteras i webbläsarna för andra delen av DOM- hanteringen, det vill säga manipulering.
Figur 21 visar resultaten från undersökningen av manipulering med jQuery i olika webbläsare. Denna mätningen visar hur Safari har bytt plats med Chrome med en prestandaskillnad på tio sekunder. Firefox visade sig inte kunna förbättra sig på manipuleringens-fronten heller utan samma trend fortsätter med Safari och Chrome som utmanar varandra medan Firefox får står utanför.
Figur 20
Rendering med React i olika webbläsare
I Figur 22 så redovisas resultaten från mätningen av manipulering med Angular i olika webbläsare. Dessa resultat visade sig väldigt intressanta då Firefox för första gången stod som marginal segrare. Ett potentiellt svar på varför resultatet visar en sådan stor skiftning kan vara att Firefox är optimerat för dessa nya ramverk som Angular och React. Återstår att se hur React hanteras av webbläsarna och framförallt Firefox.
! 22 Figur 21
Manipulering med jQuery i olika webbläsare
Figur 22
Manipulering med Angular i olika webbläsare
Figur 23 visar resultatet från den sista mätningen av webbläsarna och undersöker hur React hanteras. I denna mätningen så fortsätter trenden från den tidigare med Angular och visar hur mycket bättre Firefox hanterar manipulering än rendering. Chrome visade sig vara det alternativet att föredra för DOM-manipulering i React. Detta kom inte som en överraskning då React är ett väldigt nytt ramverk och Chrome är den populäraste webbläsaren så Chrome är förmodligen den webbläsaren man främst optimerar ramverket för.
5.2.1.3 Slutsats
Mätningen för hur anpassade ramverken var för olika webbläsare visade sig intressant.
Mätningen för rendering av DOM visade på att Safari var det bästa alternativet för både jQuery och Angular samt jämlik med Chrome för React. För denna testenhet så kan vi fastställa att i två av tre ramverk så renderas DOM snabbare i Safari. Samt att Firefox är marginellt långsammare än de andra webbläsarna. Rendering av DOM är däremot endast ena delen av DOM-hantering och mätningen av manipuleringen visade en helt annan berättelse. Mätningen av manipulering visade att Safari inte alls vara lika dominant som för renderingen utan det stod mellan Chrome och Firefox. Angular hanterades betydligt bättre utav Firefox än Chrome vid större antal manipuleringar. Firefox hade en genomsnittlig manipuleringstid på 2,4 sekunder vid 50 000 tweets medans Chrome hade 4,1 sekunder.
Detta tyder på att Angular är bättre anpassat för Firefox än Chrome och Safari och att React är bättre anpassat för Chrome.
Genom att mätningar så har Chrome varit väldigt konsekvent och har lyckats antingen hamnat först eller på andra plats. Så den slutsatsen som kan dras när det kommer till vilken webbläsare som är mest kompatibel överlag för ramverken så måste Chrome vinna. Safari hanterar rendering bättre men hanterar manipulering sämre medan Chrome har presterat bra genom alla tester.
Figur 23
Manipulering med React i olika webbläsare
5.2.2 Mätning av ramverken 5.2.2.1 Rendering
Undersökningen av vilken webbläsare som är bäst anpassad för de olika ramverken gav slutsatsen att Safari var den webbläsare som vad bäst anpassad för rendering av ramverken, medan Chrome var det bättre alternativet för manipulering. Nästa steg i processen för att besvara hypotesen är att mäta hur de olika ramverken står sig emot varandra i de olika webbläsarna.
Figur 24 visar resultaten från mätningen av ramverkens DOM-rendering i Chrome. Denna mätning visade jQuery som det snabbaste ramverket i Chrome för rendering. Likt pilotstudiens resultatet så fortsätter jQuery ha snäppet bättre renderingstid än React. Samt Angular fortsätter att ligga långt efter de andra ramverken, vilket beror på dess två-vägs dataström. Angular har fler beroenden och bindningar än de andra ramverken som måste sättas upp och installeras, där av den längre renderingstiden. Denna trenden förväntas ändras under manipuleringsmätningen. När vi tidigare mätte vilken webbläsare som var bäst anpassad för vardera ramverk så visade resultaten på att Chrome var det bästa alternativet för React. Och det faktum att jQuery ändå vinner så skall vi förmodligen se en ännu större förbättring för jQuery i Safari och Firefox.
Figur 25 visar resultaten från DOM-rendering med ramverken i Firefox. Som förutspått så har gapet mellan jQuery och React ökat då React är inte lika anpassat för Firefox som för Chrome. Angular renderingstid fortsätter att öka drastiskt och ser nästan en dubbelt så lång renderingstid i Firefox. Börjar se tydliga spår på hur mycket bättre React hanterar skalbarhet än Angular. Angular lyckas hålla snarlika renderingstider som jQuery och React fram tills 1 000 tweets, men faller bakom mycket från 5 000 och över.
! 24 Figur 24
Rendering med ramverken i Chrome
Figur 25
Rendering med ramverken i Firefox
Figur 26
Rendering med ramverken i Safari
I den sista mätningen DOM-rendering i de olika ramverken så mäts de i Safari. Figur 26 visar resultatet från mätningen och gav resultatet att jQuery är marginell segrare. Denna mätningen visar även på ett större gap mellan jQuery och React vilket tyder på att React inte är bra optimerat för Safari jämfört med de andra webbläsarna.
5.2.2.2 Slutsats
Resultaten från dessa mätningen över DOM-rendering i ramverken fortsatte att stötte upp resultaten från pilotstudien. jQuery är tydlig vinnare när det kommer till DOM-rendering i alla tre webbläsare. Ett potentiellt svar på detta kan vara att React och Angular är nya och moderna ramverken medan jQuery är ett väldigt etablerat ramverk och stödet för detta har funnits länge. jQuery har alltid varit bra på att rendera DOM men på grund utav bristande optimering för manipulering av DOM så kommer förmodligen denna trend skifta i den uppkommande mätningen över DOM-manipulering. För att återkoppla till hur de olika ramverken hanterar manipulering så skiljer de sig åt väldigt mycket. jQuery är dålig på att hantera ändringar i DOM eftersom man lämnar över mycket logik till DOM. DOM är dålig på att hålla reda på hur element håller ihop och hur de skall ändras, men väldigt bra på att rendera ut ett färdigt DOM-träd.
Detta påstående med att jQuery är väldigt bra på att rendera ut färdiga DOM-träd visar resultaten från mätningen. Vilken som då är den potentiella nackdelen med jQuery är hur den kommer hantera manipulering utav DOM. React har ett unikt tillvägagångssätt till detta med att man lämnar över logiken bakom hur element skall hanteras och ändras till JavaScript, med tekniken Virtuell DOM. Med detta så skall enligt hypotesen React prestera bättre på denna front än de andra ramverken.
5.2.2.3 Manipulering
Denna mätningen kommer undersöka hur effektivt ramverken hanterar ändringar i DOM och om denna mätningen motsäger resultatet från renderingsmätningen. Figur 27 visar resultaten från den första mätningen som är utförd i Chrome. Som förutspått så visar detta jQuery’s bristande hantering av DOM-manipulering. jQuery har enorma problem med skalbarhet och skalar inte inkrementellt. Det vill säga att om man manipulerar 100 tweets och sedan 1 000 tweets så bör laddningstiden vara tio gånger så lång, eftersom det helt enkelt är 10 gånger så många. Men med jQuery så går laddningstiden från 2,5 sekunder vid 10 000 tweets till 30 sekunder vid 50 000 tweets. Även om vi har ökat antalet tweets med 5 gånger så många så blir inte laddningstiden 5 gånger längre, utan blir istället 12 gånger så långsam. Angular och React hanterar skalbarheten betydligt bättre och har en mer logisk inkrementell ökning vid tillägg av ytterligare tweets.
React skall enligt hypotesen prestera bättre än både Angular och jQuery på denna front och i resultaten så ser vi att React är snäppet snabbare än Angular. Båda ramverken har ett marginellt mer effektivt sätt att hantera manipulering än jQuery. React med sin Virtuell DOM och Angular med sin två-vägs dataström. Det som är intressant är att se vilken av dessa tekniker som är det bättre alternativet.
! 26
Figur 28 visar resultaten från mätningen i Firefox. Här ser vi att Angular var det snabbaste ramverket och jQuery har rekordhöga renderingstider med över 60 sekunder vid 50 000 tweets. I den tidigare undersökningen om vilken webbläsare som var bäst anpassad för ramverken såg vi att Angular var bäst optimerat för Firefox. Med tanke på hur nära React och Angular var i Chrome så var det förväntat att Angular skulle vara det snabbare ramverket i Firefox.
Figur 27
Manipulering med ramverken i Chrome
Figur 28
Manipulering med ramverken i Firefox
Den sista mätningen för manipulering utfördes i Safari. Figur 29 visar resultaten från mätningen och visar i princip samma resultat som för Firefox att Angular är snabbast och jQuery långt efter resten. Det ramverk som var sämst optimerat för Safari var React så det var inte förvånat att React skulle ha sämre tider i denna mätning än Firefox.
5.2.2.4 Slutsats
Den slutsats som kan dras över denna manipulerings mätning är att jQuery som såg så bra ut på renderingsfronten presterar exakta motsatsen när det kommer till manipulering.
Moderna sidor idag består inte av en av de två sidor utav DOM-hantering utan de består utav både rendering och manipulering. Men man kan också använda argumentet att applikationer sällan består utav över 50 000 DOM-element (10 000 tweets). Och fram till denna storlek så hänger jQuery på relativt bra med React och Angular när det kommer till manipulering.
Mot förväntan så är Angular det ramverk att föredra i manipulering av DOM. Enligt hypotesen så skall React prestera bättre än både jQuery och Angular i rendering och manipulering av DOM. Undersökningen visade att detta inte var fallet, utan det var jQuery som var det snabbaste ramverket för rendering och Angular för manipulering. Vilka slutsatser kan dras för React? Det är ett ramverk som är väldigt konsekvent och optimerat för skalbarhet. I rendering så var React jämlik med jQuery och för manipulering jämlik med Angular. Det är balanserat för båda världarna och samma sak kan inte sägas om antingen Angular eller jQuery där de båda har motsatta brister.
Som resultat från denna mätning så har vi möjligheten att kategorisera ramverken med vad de är bra på och mindre bra på samt vilka användningsområden som är lämpade för de olika
!
28 Figur 29
Manipulering med ramverken i Safari
ramverken. Se Figur 30 för kategorisering av ramverken. Här får man en bättre inblick över hur Angular och jQuery är bra på motsatta områden och hur React är ett mer balanserat ramverk med inga svaga områden.
De tillämpningsområden för jQuery är när behovet är att kunna rendera ut stora statiska DOM-träd. Angular används där man inte renderar ut stora DOM-träd på en och samma gång, utan kan användas när man renderar ut DOM-trädet i sektioner. Skiner vid manipulering av stora DOM-träd men tar som sagt tid att installera och rendera alla DOM- element. React är att föredra om kravet är att kunna hantera båda världarna med snäppet mindre prestanda.
Överlag så är React det ramverket att föredra då man får en bra balans mellan de båda världarna och de flesta scenarios idag innehåller krav på att applikationen skall kunna hantera båda sidor.
Ramverk Rendering Manipulering R. Skalbarhet M. Skalbarhet Balanserad
jQuery ✔ ✖ ✔ ✖ ✖
Angular ✖ ✔ ✖ ✔ ✖
React ✔ ✔ ✔ ✔ ✔
Figur 30
Kategorisering av ramverken
6. Avslutande diskussion
Detta kapitel kommer sammanfatta studien följt av en diskussion av arbetet och vidareutveckling av studien.
6.1 Sammanfattning
Frågan som arbetet var efter att svara på var om dessa nya SPA-ramverk hanterar rendering och manipulering, med deras egna tillvägagångs sätt, bättre än traditionell DOM-hantering med jQuery. Hypotesen var att ReactJS skall hantera rendering och manipulering bättre än jQuery men även AngularJS. Den vetenskapliga metoden som används för att försöka svara på denna fråga var experiment. Experiment gav möjligheten till en mer öppen mätning med få begränsningar. Man kunde ändra variabler samt beteenden och se hur de reagerade.
Experimentet inleddes av en förstudie för att få en djupare förståelse utav dessa nya ramverk React och Angular samt att försöka komma fram till hur applikationen skall konstrueras. se kapitel 4.1. Förstudien kom fram till att applikationen skulle efterlikna en applikation som är byggd efter Infinite Scroll-tekniken. Twitter var det naturliga valet för att applikationen har en simpel design som enkelt kunde återskapas i alla tre ramverk.
Under utvecklingsfasen utav dessa tre applikationer skapta i jQuery, React och Angular så var det ett återkommande problem som uppstod. Detta problem var start- och sluttid för varje individuella applikation eftersom alla ramverk är konstruerade olika så var det svårt att komma fram till en lösning som fungerade genom alla applikationer. En mindre undersökningen utfördes för att få en bra punkt för när renderingen och manipuleringen börjar samt när den slutar. Detta för att fortsätta jobba med likvärdigheten mellan applikationer och utesluta orättvisa resultat i mätningen.
När alla applikationer var färdiga och det var slutställt att alla applikationer mäter start- och sluttid likvärdigt så började mätningen utföras. Mätningen utfördes på 100, 1000, 10000 och 50000 tweets och mättes i iterationer av 100 på varje storlekskategori. Resultaten från studien visade sig motsäga hypotesen eftersom jQuery var det snabbaste ramverket för rendering och Angular det snabbaste för manipulering, så på båda fronterna så React sig besegras. Detta kan dock diskuteras då överlag React ses som det bättre ramverket för rendering samt manipulering än de andra två. React är ett balanserat ramverk medan de andra två ramverken är endast snabba på en av de två aspekterna i DOM-hantering. Med detta så kan hypotesen inte bekräftas eftersom React tekniskt sätt inte var bättre på båda delarna. Men kan ses som det bättre ramverket för DOM-hantering då den hanterar rendering samt manipulering bra, vilket inte kan sägas för de andra två ramverken.
6.2 Diskussion
Syftet med denna studie är att svara på de problem som man idag har med DOM och dess hantering utav expanderande DOM-dokument som man får med den populära Infinite Scroll-tekniken. Det finns vetenskaplig forskning som pekar på detta problem som DOM har.
Vad arbetet vill svara på är hur nya ramverk som Angular och React tacklar dessa problem med deras unika tillvägagångssätt, två-vägs dataström för Angular och Virtuell DOM för React. I nuläget finns det ingen vetenskaplig forskning i hur ramverk kan förbättra hanteringen av DOM men med denna undersökning visa på hur dessa två ramverk kan användas för att förbättra hanteringen utav expanderande DOM-dokument.
!
30
Kodens kredibilitet är något som kan diskuteras då tre individuella applikationer var tvungna att konstrueras. Det är i princip omöjligt att skapa tre olika applikationer i tre olika ramverk och samhålla en perfekt likvärdighet mellan dem, vilket kan visa sina spår i resultaten. För att försöka skapa en bättre likvärdighet så har ett mål varit att skapa så pass snarlika applikationer som möjligt. Svarstiden var något som hanterades väldigt olika i ramverken, vissa ramverk jobbade mer hand-i-hand med webbläsaren där deras exekvering var beroende utav webbläsarens respons. För att hitta en bra punkt för start- och sluttid så gjordes mindre undersökningar för varje ramverk för att komma fram till deras individuellt optimala start- och slutpunkt för rendering och manipulering av DOM. När börjar själva rendering? Är det när ramverket har exekverat sin kod, eller är det när webbläsaren har renderat ut innehållet och är redo att manipuleras? Den referenspunkt för slutrendering togs då när webbläsarens har renderat ut hela DOM-dokumentet och det är redo att användas.
Genom alla applikationer så har även gränssnitt och hantering av data varit en kontinuerlig faktor som måste hållas likvärdig.
Miljön för applikationerna är något som är värt en diskussion. Kan det vara så att konstruktionen av applikationer favoriserar något ramverk? Är det så att exempelvis React är oerhört bra på att hantera dessa typer av utmaningar som applikationerna är konstruerade för? Detta är svårt att svara på då det inte finns någon vetenskaplig forskning som understödjer detta påstående. Kan det vara så att om man skapade en mer verklig applikation att resultaten från mätningen blir irrelevanta? Dessa frågor är intressanta att undersöka för att kunna svara på hur ramverken jobbar i en mer verklig miljö. Syftet med studien var att endast kolla på renderingen och manipuleringen av DOM. Vilket, för denna studie, gör aspekter som interaktion med databaser, nätverk etc. irrelevanta. Men vill man ha en mer utförlig undersökning av ramverken så är detta aspekter som man måste ta hänsyn till.
Hur studien bidrar till någon form av samhällelig nytta är att vi kunnat svara på hurvida dessa två populära tekniker som finns i ramverken, två-vägs dataström och Virtuell DOM, hanterar DOM rendering och manipulering bättre än klassiskt direkt DOM-interaktion som man har med jQuery. Arbetet ger tydliga användningsområden och genom resultaten från undersökningen kan svara på under vilka omständigheter ramverken är bäst anpassat för.
Webbutvecklare kan granska undersökningen och få en uppfattningen om vilket ramverk passar bäst för ämnat syfte. Är det att skapa en massiv ström av innehåll likt Twitter och är i behov utav konstakt manipulering och snabb rendering av detta innehåll är React det bättre alternativet. Är kraven att det skall vara mindre rendering och mer fokus på manipulering är Angular bästa alternativet. Och slutligen om kraven är att innehållet är mer statisk utav behov av stor mängd manipulering så är jQuery svaret. Denna undersökningen ger en bra bas för webbutvecklare som är intresserad utav just detta, hur kan hanteringen av DOM förbättras med hjälp utav ramverk.
6.3 Framtida arbeten
Ur ett kortare perspektiv så skulle det fortsatta arbeten i studien vara att mäta flera variabler, få en mer verklig testmiljö och använda flera enheter. Detta för att kunna få ett mer detaljerat svar och kunna utesluta faktorer som eventuellt påverkat mätningen. Några av dessa variabler som även skulle kunna mätas är framförallt minneshantering. Jag misstänker att Angular är mer beroende utav minne än React då Angular har fler beroenden och förhållanden i dess kod. Men kan också vara så att Reacts abstraka representation utav DOM använder en stor del minne.
Ur ett längre perspektiv så hade det varit intressant att se hur denna mätning såg ut i en mer verklig applikation och verkligen försöka implementera en realistisk miljö för Infinite Scroll.
Det är även intressant att se hur ramverken hanterar andra typer av applikationer som inte använder Infinite Scroll. Kan det vara så att vissa ramverk är mer lämpade för just Infinite Scroll-liknande applikationer? Detta är en bra fråga att försöka svara på och mer skulle kunna bidra till ett svar på användningsområden för ramverken.
! 32
Referenser
Anon (2016) GlobalEventHandlers.onload. Tillgänglig på Internet: https://
developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onload [Hämtad:
April 3, 2016]
Breton, G. L., Bergeron, N. & Hallé, S. (2014) A Reference Framework for the Automated Exploration of Web Applications. Engineering of Complex Computer Systems (ICECCS 2014), 19th International Conference on. Tianjin, Kina. IEEE. ss. 81-90.
Brohede, M. (2016) HGustavs/AstarLib. GitHub. Tillgänglig på Internet: https://github.com/
HGustavs/AstarLib [Hämtad April 2, 2016].
Cai, J.-Y., Nerurkar, A. & Wu, M.-Y. (1998) Making benchmarks uncheatable. Computer Performance and Dependability Symposium, 1998. IPDS ’98. Proceedings. IEEE International. September s. 216–226.
Demetrescu, C., Finocchi, I. & Ribichini, A. (2011). Reactive imperative programming with dataflow constraints. Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications. Portland, Oregon, USA.
ACM. ss. 407-426.
Heath, G. (2015) React ”after render” code?. Tillgänglig på Internet: http://
stackoverflow.com/questions/26556436/react-after-render-code [Hämtad: April 4, 2016]
Hunt, P. (2016) Thinking in React. Tillgänglig på Internet: https://facebook.github.io/react/
docs/thinking-in-react.html [Hämtad: Mars 14 2016].
Koukouletsos, K., Moustris, K.P. & Paliatsos, A. (2015). The impact of long scrolling web pages on users. eRA-11 International Scientific Conference. Piraeus, Grekland. ss. 1-7.
Langton, C. (2014) Angular.js final callback after ng-repeat. Tillgänglig på Internet: http://
www.nodewiz.biz/angular-js-final-callback-after-ng-repeat [Hämtad April 2, 2016]
Mickens, J. (2010) Silo: Exploiting JavaScript and DOM Storage for Faster Page Loads.
Proceedings of USENIX Conference on Web Application Development. Boston, MA, USA.
Miles, J. (2015) React.js, jQuery and Angular.js rendering performance tests. Tillgänglig på Internet: https://github.com/jonmiles/react-performance-tests [Hämtad: Mars 15, 2016]
Psaila, G. (2008). Virtual DOM: an Efficient Virtual Memory Representation for Large XML Documents. Database and Expert Systems Application, (DEXA 2008), 19th International Workshop on. Turin, Italien. IEEE. ss. 233-237.
Salvaneschi, G., Margara, A. & Tamburrelli, G. (2015) Reactive Programming: A Walkthrough. Software Engineering (ICSE), 2015 IEEE/ACM 37th IEEE International Conference on. Florens, Italien. IEEE. 953-954.
Scully, T., Doboš, J., Sturm Fraunhofer, T. & Jung, Y. (2015) 3drepo.io: building the next generation Web3D repository with AngularJS and X3DOM. Proceedings of the 20th International Conference on 3D Web Technology. Kreta, Grekland. ACM. ss. 235-243.
Tesařík, J., Doležal, L. & Kollmann, C. (2008) User interface design practices in simple Single Page Web Applications. Applications of Digital Information and Web Technologies (ICADIWT 2008), First International Conference on the. Ostrava, Tjeckien.
IEEE. ss. 223-228.
Twitter (2016) Connect with your friends. Tillgänglig på Internet: https://twitter.com [Hämtad: Mars 5, 2016]
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B. & Wesslén, A. (2012) Experimentation in Software Engineering. Berlin Heidelberg: Springer-Verlag. ISBN 978- 3642290435.
Zependa, J.S. & Chapa, S.V. (2007) From Desktop Applications Towards Ajax Web Applications. Electrical and Electronics Engineering (ICEEE 2007), 4th International Conference on. Mexico City, Mexico. IEEE. ss. 193-196.
Zhu, Y. & Reddi, V.J. (2013) High-performance and energy-efficient mobile web browsing on big/little systems. High Performance Computer Architecture (HPCA2013), 2013 IEEE 19th International Symposium on. Shenzhen, Kina. IEEE. ss. 13–24.
! 34
APPENDIX A - JQUERY-APPLIKATIONEN: HTML
<html>
<head>
<meta charset="UTF-8">
<title>jQuery</title>
<script src="js/jquery.min.js" type="text/javascript"></
script>
<script src="js/script.js"></script>
<link rel="stylesheet" href="css/bootstrap.min.css">
<link rel="stylesheet" href="css/style.css">
</head>
<body>
<div class="container text-center">
<button type="button" class="btn btn-warning btn-lg"
onclick="manipulate();">Manipulate DOM</button>
<button type="button" class="btn btn-primary btn-lg"
onclick="flushStorage();">Flush storage</button>
<hr>
<h2 class="text-left benchCount"></h2>
</div>
<div class="container">
<div id="itemList"></div>
</div>
<script>
var itemLimit = location.search.split('itemLimit=')[1] ? location.search.split('itemLimit=')[1] : 10000;
if(!localStorage.benchString){
localStorage.benchString = "";
localStorage.manBenchString = "";
}
benchmark(itemLimit);
</script>
</body>
</html>
APPENDIX B - JQUERY-APPLIKATIONEN: JAVASCRIPT
function require(script) { $.ajax({
url: script,
dataType: "script",
async: false, // <-- This is the key success: function () {
// all good...
},
error: function () {
throw new Error("Could not load script " + script);
} });
}
function flushStorage(){
localStorage.removeItem('benchString');
localStorage.removeItem('benchCount');
console.log('flushed');
}
function render(itemLimit){
var data = _buildData(itemLimit);
var html = "";
$.each( data, function( key, value ) {
! 36
html += "<div class='item i"+key+"'><h4>" + value.name +
" < / h 4 > < p > " + v a l u e . t e x t + " < / p > < d i v c l a s s = ' i t e m - bottom'><span>"+value.likes+"</span></div></div>";
});
window.startTime = performance.now();
$('#itemList').html(html);
}
function clearList(){
$('#itemList').html("");
}
function benchmark(itemLimit){
clearList();
window.itemL = itemLimit;
render(itemLimit);
}
function manipulate(){
var items = $('.item');
var randomItems = getRandomItems();
var startTime = performance.now();
for (var i = 0;i<randomItems.length;i++){
mTarget = $('.i'+randomItems[i]);
mTarget.addClass("highlight");
mTarget.find('p').html("Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.");
}
var totalTime = performance.now() - startTime;
return totalTime.toFixed(3);
//$('#manloadtime').html(totalTime.toFixed(3));
