Speed Performance Comparison of JavaScript MVC Frameworks Alexander Svensson Facultyof Computing Internet :www.bth.se Blekinge InstituteofTechnology Phone :+46 455385000 SE-371 79Karlskrona Sweden Fax :+46 455385057 Contactinformation: Author: AlexanderSvensson Email: [email protected] Program: Webprogramming Supervisor: GuohuaBai Email: guohua.bai@bth,se Department: Ph.DProfessor,School ofComputing Facultyof Computing Internet :www.bth.se Blekinge InstituteofTechnology Phone :+46 455385000 SE-371 79Karlskrona Sweden Fax :+46 455385057 ABSTRACT Context: Manywebsites today are very interactive andtheusers are getting usedto sites thatchange hundreds of elements every second. Often aJavaScript framework is usedto buildtheweb siteandwith many changing elements onthesitetheneed for aJavaScript framework that can handlethe fast changes are needed. Each frameworks doitdifferently toachieving this butmost ofthem dosomemanipulation with theDocument Object Model (DOM). Objectives:This research will showhowfast the selected MCVlikeJavaScript frameworks (AngularJs,AngularJs2.0,Aurelia, Backbone, Ember,Knockout, Mithril, Vue)can create, delete andupdate HTMLelements on thescreen. Methods:This research have used Google ChromesTimeLine tool tomeasure the speed oftheframeworks.Thetest involves creating a HTMLtableand fillit with athousand rows ofdata withsix columns.The tables content are tested tosee howfast the frameworks can create, update and removethe elements. Conclusions:Angular 2.0almost achieved first place in all tests.Angular 1.5did very good intheupdate tests andwas good inthecreate elements test.Backbone and Ember didnot dosowell in thecreate andupdate testsbut Backbone was thebest framework in oneofthedelete tests.Aureliagot very good results andsodidVuewhich almost hadthe samevalues asAurelia throughout thetests. Mithriland Knockout performed well in the createtest which placed them in themiddleamong all theselected frameworks.When it came tothe updatetests Mithriland Knockout also found them self inthe middle positionsofall theframeworks. KeyWords: JavaScript, Framework, performance,Angular,Aurelia, Backbone, Ember,Knockout, Mithril,Vue. Facultyof Computing 3 Internet :www.bth.se Blekinge InstituteofTechnology Phone :+46 455385000 SE-371 79Karlskrona Sweden Fax :+46 455385057 CONTENTS 1. Introduction......................................................................................................................5 2.Background......................................................................................................................6 2.1Document Object Model........................................................................................6 2.2CSSObject Model (CSSOM)................................................................................7 2.3Rendering tree........................................................................................................7 2.4Webbrowser rendering..........................................................................................8 2.4.1Rendering performance...............................................................................9 2.5Selected JavaScript frameworks...........................................................................11 2.5.1Angular 1.5................................................................................................12 2.5.2Angular 2.0................................................................................................13 2.5.3Aurelia.......................................................................................................13 2.5.4Backbone.js...............................................................................................14 2.5.5Ember........................................................................................................15 2.5.6Knockout...................................................................................................15 2.5.7Mithril.......................................................................................................16 2.5.8Vue............................................................................................................17 3.Method...........................................................................................................................18 3.1Research questions...............................................................................................18 3.2Literature ReviewDesign....................................................................................18 3.3Empirical StudyDesign.......................................................................................18 4. Results............................................................................................................................20 4.1Dataresults and metrics.......................................................................................20 4.1.1Resultfrom create 1000rows...................................................................20 4.1.2Resultfrom update all rows......................................................................22 4.1.3Resultfrom delete all rows.......................................................................24 4.1.4Resultfrom update 1/3 of1000rows........................................................25 4.1.5Resultfrom delete 1/3 of1000rows.........................................................26 5.Analysis..........................................................................................................................27 5.1Summary..............................................................................................................27 5.1.1Research Question 1- Createelements.....................................................27 5.1.2Research Question 2- Updateelements....................................................28 5.1.3Research Question 3- Deleteelements.....................................................28 5.2ValidityThreats....................................................................................................29 6.Conclusion......................................................................................................................30 6.1Summary..............................................................................................................30 6.2FutureWork..........................................................................................................31 7.References......................................................................................................................32 AppendixA........................................................................................................................36 1. Introduction ComparingJavaScript framework to each otherare a hottopicin theweb development communities[27][28]and thisresearch will focus onthe performance whenworking with theDOM.This research will putan extralight onhowfast they creates, remove and updateelement from theDOM tothescreen.Web pages with much content oneach page likeforums, blogs, social media, statisticsites aresomeexamples ofsites themay gain from aJavaScript framework that performs well. Today web browsers are very fast compare to olderversions andthey are constantly makingthem faster[17]but notall the users have thenewest version or maybe aweb browser thatdoesn’t perform sowell.Witha newer web browser that display awebsite thathave fewer elements/content the speed performance values may not differsomuch between theJavaScript frameworks but whenthe webpage content gets really big the performance metrics have much more impact.Websites likeFacebook andTwitterthat havea lotofcontent oneach page are sitethat musthave aframework that performs fast updateto thescreen. Other sitethat maybeare not sopopular butalso havemuch content todisplay onthescreen could gain from selection afast performingJavaScript framework. There are already afew similarstudies madeonweb sites but notto this reseach extent and with therapid update changes theframeworks doeach monththeperformance values could drastically change. Most ofthestudies that are made are also only focusing ona feweramount of frameworks. Theselected JavaScript frameworks for thisresearch are selected based onpopularity or hownewit is andfora moredetailed elucidation read the“Selected JavaScript frameworks”section.This studyhavealso focused more onMVC(ModelView Controller)likeframeworks that usually are thebase for theapplication and can often performmany different tasks.There are alot offrameworks andto testall of them would beimpossiblefor thisresearch but theonce that will beexamined are: - AngularJs1.5 - AngularJs2.0 - Aurelia - Backbone - Ember - Knockout - Mithril - Vue There are someotherlibraries that would have been interesting to include likeReact and Incremental DOM butthey are mostly justusedas theViewinMVC. Thisresearch willonly focus onthe JavaScript frameworks rendering speed performance values from theweb browser.Howfast the framework renders things onthescreen are theinteresting part. Other aspects oftheframeworks are notvaluated in this studylike usability,learnability,documentation, useful additions/functions thatalso are importantto evaluate whenchoosing a JavaScript framework. 2. Background In order for usto understand howtheselected JavaScript frameworks manage their performance wefirst have to understand thebasic ofhowaweb browser work. Webbrowser are built with some main components like browser engine, rendering engine, JavaScript Interpreter,User Interface, Data storage, Networking and UIbackend[9].We willfocus ontherendering enginepart oftheweb browser and showthebasichowit works.Tomeasure theJavaScript frameworks performance andcompare themto each otherwehave tounderstand someconcepts that are explained below. 2.1 Document Object Model TheDocument Object Model (DOM) is aprogramming interfacefor HTML, XMLand SVGdocuments [1][2].The DOM provides a object-oriented structure ofthedocument (HTML,XMLorSVG)and each element is turned intoa object that have itsown methods,properties and values. It also creates astructured interface nodetree representation ofthedocument that can be manipulated in someway.Whentheweb browser first receives thepage’s document text(HTML, XMLor SVG)itparses it into theDOM andwith aprogramming language you can access theDOM nodes. Figure1.0-Image:HTMLdocumentconvertedtoaDocumentObjectModeltree Thetop ofthetree(in figure 1.0)is theHMTLobject andin theimage exampleabove we can see that ithave two child nodes which are HEAD andBODY.Theimage withthe tree isjust asimplified exampleof theDOM interface andtheHTMLelement isachild of the document object which istheroot oftheDOM. Wecan easily traverse thenodetree and select theelements wewant withthe DOM interface.Wecan select aspecific element bysearching thetreefor an elements id attributeorselect many elements bytheirclass name attribute.Thenodes that are on the samerow andhavethe sameparent node arecalled siblings andifanelement have a parent element it’s also called achild node tothe parent node. Each node inthe treerepresent anelement, anattribute, content orsomeother object[3] andwiththeDOMAPIwecan add, removeor updatethenodes. Each change tothe DOM creates achain of actions theweb browser mustdobefore the usercan see thenew updated web pageand itcould be timeconsuming. Somechange stakes moretimethen others andone ofthemoretimeexpensiveones are when we change thelayout which means ifwe change thegeometrics ofanelement likeitsheight orwidth. Today’s webpages often uses JavaScript to manipulatethe DOM insome waylike adding, removing orupdating elements in theDOM tree.The DOM was not created to onlywork with onespecific programming language likeJavaScript but JavaScript have become oneofthemost popularlanguage to manipulatethe DOM. 2.2 CSS Object Model (CSSOM) Whenthe webbrowser is constructing theDOM itfinds a linkelement that references to aexternal CSSstylesheet and fetches it.If there are nostylesheet link element in the HTMLmarkup ituses the webbrowsers default stylesheet.After thestylesheet is downloaded the webbrowser converts theCSSstyles intoa tree structure liketheDOM butthis timeit`s only for theCSS.Whencomputingthefinal set ofstyles for anyobject onthepage, thebrowser starts withthe mostgeneral rule applicable tothat node (e.g. ifit isa child ofbodyelement, then all bodystyles apply) andthen recursively refines the computed styles byapplying more specific rules - i.e. therules “cascade down”[4]. Soa stylethat effect many object element down thetree will recursively add itto all ofthem. Let saywe havea BODYnodein theCSSOM andunder itthere is a Pnode which have a childnode ofaSPANandnow wehave astyle that only apply to that SPANelement, body>p>span.TheCSSOM becomes likea treemap ofall theCSSstyles combined and tells what style adifferent elementhave depending onwhere in thetreeit is. 2.3 Rendering tree TheRendering tree is a combined tree oftheDOM andtheCSSOM which contains everything that is going to be displayed ontheweb page.When we combinethetrees an element in theDOM could have theCSS styleproperty from the CSSOMset to “display: none”and then that nodewill not beincluded in theRender-tree.The Rendertree only includethings that will bevisibleto theusers intheweb browser sofor examplethe HEADwill not beincluded.TheRender-tree tells thewebbrowser howto layout the pageand howto paint it.The nameRendering tree may have different names depending onwebbrowser.TheRendering tree couldalso be seen as a set ofobjects being rendered [5]Webkit(Layout engine usedin e.gSafari) and Blink(Layout engine usedin e.g ChromeandOpera)calls each ofthosea “renderer” or“render object” while Gecko(Layout enginefor Mozillaused ine.g Firefox,SeaMonkey) calls it a“frame”[5]. If we doanything onawebpage likescrolling thepage, changing theDOM with JavaScript, CSSanimations orbasically anything we doona webpage theRendering tree willbeupdated around sixtytimes each second[10].Therendering ofeach frame differ fordifferent web browsers and thetree are created a littlebitdifferent between theweb browser. 2.4 Web browser rendering Webbrowser rendering happens every timewe interact with thewebsite andeach web browser has itsown engineto calculateeach frame.Awebbrowser engine(sometimes called layout engine orrendering engine)[6] are very complex andtheterminology used bythedifferent web engines my differbut they often mean thesame thing.Webbrowsers e.gGoogleChrome,Apples Safari usesWebKit as there web engine and e.gMaozilla Firefox,SeaMonkey uses Gecko engine[6].All web browsers striveto achieve sixty frames per second sothat theflowof thepage feels smooth for theusers.The web browser rendering dodifferent steps likelayout andpainting thecontent tothe webpage soit feels likethepageload faster.Anexampleofthis isthat we seethe textonthe web pagebefore we see theimages but in theold browsers wehad to wait untilall theimages arefully loaded before we could see anything onthepage. It’s importantto understand thatthis is agradual process andengine willnot wait until all theHTMLis parsed before startingto build andlayout therender/frame tree[9]. Each web browser engine havethere own wayof creatinga page andupdating each frame but themain floware basically the same. Figure1.1-Image:TheflowofWebkitengines,imageinspiredby[7][8][9] Figure1.3-Image:TheflowofMozilla’sGeckoengines,imageinspiredby[7][8][9] Wecan see from theimages above(figure 1.2and 1.3)that theDOM andthe CSSOM(Styles rules) are combined tothe render/frame treeand in thelayout/reflow the content(HTML) gets theright position,widthandheight to theweb browser.After that it paintsthe siteafter thegiven style(CSS)likebackground-color,color,show text, images and morethat each node(HTMLelement) havein therender/frame tree. Sothebasic flowofa rendering engineis to first to parse theHTMLandCSSto construct theDOM tree and theCSSOM tree.Then therender/frame tree is created and after that thelayout/reflow(the position,width andheight of theelements onthepage) are calculated.Thelast step is thepainting. 2.4.1 Rendering performance Mostdevices have arefresh rate ofsixtyframes persecond which thebrowsers dowhen ananimation, transition(likewith CSS), orthepage is scrolled[10]. Each frame must be donein 16ms(1 second / 60=16.66ms)but thebrowser needs around 6ms for housekeeping soyou only have less then 10ms foreach frame[10]. If wetake morethen 10msthebrowser willstart dropping frames which willresult in juddering images onthe screen. Thetests ontheselected JavaScript frameworks are going to bedone inthe webbrowser Chromesoweare going to explain howtheysee a frame.The tests are alsogoing tobe executed in ChromeDeveloperTools(DevTools)which can be usedmeasure the timethe web browser spendondifferent things likeJavaScript, style andlayout calculations. Each timewe dosomething withthescreen likescrolling thepageor someother JavaScript,CSSorWebAnimationsare being triggered thebrowser takes different calculations paths depending ontheaction. Soifwe dosomekindof visual change tothe screen anew frame is constructed. Each framework have already optimized theirrendering performance but inthis research theDevToolwill beusedto see howmuch timeittakes to calculate theJavaScript, Style, Layout, Paintand Composite. It’s also very good to usetheDevToolto optimizeyour codeand see ifthere is something that isslowing downyour site. Thisis howtheGoogle Development team describe flowof apixel to thescreen(the pixel pipelineshownin figure 1.4): Figure1.4-Image:Googlesvisionofpixeltoscreenflow.[10] (cid:1) JavaScript.Typically JavaScript is usedto handle work that will result in visual changes, whether it’s jQuery’sanimate function,sorting a dataset, or adding DOM elements to thepage. It doesn’t haveto be JavaScript that triggers a visual change, though: CSSAnimations,Transitions,andtheWebAnimationsAPIare also commonlyused. [10] (cid:1) Stylecalculations.This is theprocess offiguring out which CSSrules apply to which elements based onmatching selectors, e.g..headline or .nav > .nav__item.From there, once rules are known,they are applied andthe final styles for each element are calculated. [10] (cid:1) Layout.Once thebrowser knowswhich rules apply toan element it can begin to calculate howmuch space it takes upand where itis onscreen.Theweb’s layout modelmeans that oneelement can affect others, e.g.thewidth ofthe<body> element typically affects itschildren’swidths and soonall theway upand down thetree, so theprocess can be quiteinvolved forthebrowser.[10] (cid:1) Paint.Painting isthe process of fillingin pixels. It involves drawing out text, colors, images, borders, and shadows, essentially every visual part of the elements. Thedrawing istypically doneonto multiple surfaces, often called layers. [10] (cid:1) Compositing.Sincetheparts ofthepage were drawn into potentiallymultiple layers they need to bedrawn to thescreen inthecorrect order sothat thepage renders correctly.Thisis especially important for elements that overlap another, sinceamistake could result in oneelement appearing overthe topofanother incorrectly.[10] There are three different paths theweb browser takes when a changeis made onthe screen. Figure1.5-Image:Firstpixelpipelineflow.[10] In figure1.5the flowof thewebbrowser will doJavaScript, Style, Layout, Paint and Composite.Whenwefor examplechange aHTML’s elements widthor heightwe have changed theLayout and therefor iteffect all theother calculations inthe pixelpipeline.