Document Object Model

52 Pages·2016·1.4 MB·English

Speed Performance Comparison of
JavaScript MVC Frameworks
Alexander Svensson
Facultyof Computing Internet :www.bth.se
Blekinge InstituteofTechnology Phone :[phone]
SE-371 79Karlskrona Sweden Fax :[phone]
Contactinformation:
Author: AlexanderSvensson
Email: [e-mail]
Program: Webprogramming
Supervisor: GuohuaBai
Email: guohua.bai@bth,se
Department: Ph.DProfessor,School ofComputing
Facultyof Computing Internet :www.bth.se
Blekinge InstituteofTechnology Phone :[phone]
SE-371 79Karlskrona Sweden Fax :[phone]
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 :[phone]
SE-371 79Karlskrona Sweden Fax :[phone]
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.