Building User Interfaces UsingVirtual DOMA comparison against dirty checking and KVO

Marianne GrovMaster’s Thesis Spring 2015

Building User Interfaces Using Virtual DOM

Marianne Grov

20th May 2015

ii

Abstract

Background: The concept of a virtual DOM in front-end development isnew compared to well-established techniques. There is an ongoingdiscussion among JavaScript developers on whether the methodshould be used or not.

Aim: The aim of the thesis is to explore the use of virtual DOM to renderapplication content to the DOM. The method will be comparedagainst the main rendering alternatives of today, dirty checking andkey-value-observation (KVO).

The areas examined are performance, handling of existing problemsand general impact of using virtual DOM in front-end development.

Method: Performance tests are executed on test cases with differentstructures and amounts of data. A survey was conducted amongstudents at the Department of Informatics, University of Oslo, toinvestigate their degree of familiarity with frameworks and renderingmethods. Ten experienced developers were interviewed to obtaininformation about how the techniques function in large-scale projects.

Results: The results show that virtual DOM performs well compared withthe two other techniques focused on in this thesis. Dirty checkingrevealed serious performance issues that are of no concern usingvirtual DOM. KVO potentially gives the best performance, but at thecost of much more manual work than is required by virtual DOM.Virtual DOM also improved several of the problem areas found inuse of the other techniques.

Conclusion: Virtual DOM showed to simplify application development.It provides a higher abstraction level than KVO and a more reliableabstraction level than dirty checking. Less details have to be takencare of manually, leaving more focus to the actual functionality beingdeveloped.

The virtual DOM approach has changed the perception of how thecode beneath user interfaces should be structured. The techniqueexpands the usage areas of JavaScript, and the advantages of one-way dataflow and declarative programming have been spread inthe JavaScript community. A lot of projects are replacing the othertechniques with the virtual DOM approach.

iii

iv

Acknowledgements

I would like to express my gratitude to my supervisors Erik Wendel andYngve Lindsjørn for the useful comments, remarks and support throughthe process of writing this master thesis. Also, I want to thank thedevelopers who have willingly shared their time during the process ofinterviewing.

Thanks to family and friends for being supportive and tolerable. A spe-cial thank to Simen for proofreading and giving useful feedback. Last, butnot least, my gratitude goes to Thomas for the encouragement and positiv-ity during my work on the thesis.

This thesis could not have been finished without your contributions.

Thank you!

v

vi

Contents

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Clarification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 52.1 From static web pages to dynamic applications . . . . . . . . 6

2.1.1 Basic Web Communication . . . . . . . . . . . . . . . 72.1.2 Client-side applications . . . . . . . . . . . . . . . . . 7

2.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Challenges with JavaScript . . . . . . . . . . . . . . . 82.2.3 JavaScript Design Patterns . . . . . . . . . . . . . . . . 9

2.3 JavaScript Applications Today . . . . . . . . . . . . . . . . . . 102.3.1 Characteristics . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Time to market . . . . . . . . . . . . . . . . . . . . . . 112.3.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . 122.3.4 Application structure . . . . . . . . . . . . . . . . . . . 122.3.5 MVC pattern . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 The Rendering Path . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1 The DOM . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.2 Browser rendering . . . . . . . . . . . . . . . . . . . . 15

2.5 Change detection . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.1 Data Binding . . . . . . . . . . . . . . . . . . . . . . . 172.5.2 Object.observe() . . . . . . . . . . . . . . . . . . . . . . 182.5.3 Web Components . . . . . . . . . . . . . . . . . . . . . 192.5.4 Today’s situation . . . . . . . . . . . . . . . . . . . . . 19

2.6 Key-Value Observation . . . . . . . . . . . . . . . . . . . . . . 202.6.1 The Observer Pattern . . . . . . . . . . . . . . . . . . . 202.6.2 Accessors on Container Objects . . . . . . . . . . . . . 202.6.3 Dataflow . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7 Dirty checking . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.1 Listeners . . . . . . . . . . . . . . . . . . . . . . . . . . 232.7.2 Interaction with the browser event loop . . . . . . . . 232.7.3 Performance considerations . . . . . . . . . . . . . . . 24

vii

2.7.4 Dataflow . . . . . . . . . . . . . . . . . . . . . . . . . . 252.8 Virtual DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.8.1 Components . . . . . . . . . . . . . . . . . . . . . . . . 282.8.2 Diff algorithm . . . . . . . . . . . . . . . . . . . . . . . 282.8.3 Event handling . . . . . . . . . . . . . . . . . . . . . . 292.8.4 Rendering . . . . . . . . . . . . . . . . . . . . . . . . . 302.8.5 Facilitates declarative programming . . . . . . . . . . 312.8.6 Dataflow . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.9 Declarative and imperative programming . . . . . . . . . . . 322.9.1 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.9.2 Mental representation . . . . . . . . . . . . . . . . . . 322.9.3 Sequential and circumstantial information . . . . . . 322.9.4 Simple start . . . . . . . . . . . . . . . . . . . . . . . . 332.9.5 Simple semantic . . . . . . . . . . . . . . . . . . . . . . 332.9.6 Programmer productivity . . . . . . . . . . . . . . . . 33

3 Research methods 353.1 The methods used . . . . . . . . . . . . . . . . . . . . . . . . . 353.2 Performance testing . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2.1 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2 Implementations . . . . . . . . . . . . . . . . . . . . . 363.2.3 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.4 Test execution . . . . . . . . . . . . . . . . . . . . . . . 393.2.5 Testing tools . . . . . . . . . . . . . . . . . . . . . . . . 39

3.3 Student survey . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4.2 The interviewees . . . . . . . . . . . . . . . . . . . . . 413.4.3 The interview process . . . . . . . . . . . . . . . . . . 41

4 Results 434.1 Performance testing . . . . . . . . . . . . . . . . . . . . . . . . 43

4.1.1 A: TodoMVC . . . . . . . . . . . . . . . . . . . . . . . 434.1.2 B: Sortable datatable . . . . . . . . . . . . . . . . . . . 434.1.3 C: Sortable datatable with windowing . . . . . . . . . 454.1.4 D: Filterable datatable . . . . . . . . . . . . . . . . . . 454.1.5 E: Button click counter . . . . . . . . . . . . . . . . . . 454.1.6 F: Initial load . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 Student survey . . . . . . . . . . . . . . . . . . . . . . . . . . 484.3 Interview results . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Discussion 535.1 Rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.1.1 The rating system . . . . . . . . . . . . . . . . . . . . . 545.2 The performance . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1 Important factors . . . . . . . . . . . . . . . . . . . . . 555.2.2 Experienced issues . . . . . . . . . . . . . . . . . . . . 575.2.3 Initial load . . . . . . . . . . . . . . . . . . . . . . . . . 58

viii

5.2.4 Render time . . . . . . . . . . . . . . . . . . . . . . . . 595.2.5 The significance of data volume . . . . . . . . . . . . 635.2.6 Interaction . . . . . . . . . . . . . . . . . . . . . . . . . 645.2.7 Memory usage . . . . . . . . . . . . . . . . . . . . . . 645.2.8 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2.9 The highlights . . . . . . . . . . . . . . . . . . . . . . . 665.2.10 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 67

5.3 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.3.1 Startup and Understandability . . . . . . . . . . . . . 685.3.2 Onboarding . . . . . . . . . . . . . . . . . . . . . . . . 715.3.3 Customization . . . . . . . . . . . . . . . . . . . . . . 735.3.4 Uniform usage . . . . . . . . . . . . . . . . . . . . . . 745.3.5 The mental model . . . . . . . . . . . . . . . . . . . . 75

5.4 Abstraction level . . . . . . . . . . . . . . . . . . . . . . . . . 765.4.1 Degree of involvement . . . . . . . . . . . . . . . . . . 775.4.2 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . 775.4.3 Declarative vs Imperative Programming . . . . . . . 785.4.4 Underlying details . . . . . . . . . . . . . . . . . . . . 805.4.5 Coupling and cohesion . . . . . . . . . . . . . . . . . 81

5.5 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 825.5.1 Problems at scale . . . . . . . . . . . . . . . . . . . . . 825.5.2 Dataflow . . . . . . . . . . . . . . . . . . . . . . . . . . 835.5.3 Cascading updates . . . . . . . . . . . . . . . . . . . . 845.5.4 Bug fixing & Testability . . . . . . . . . . . . . . . . . 845.5.5 Adding new functionality . . . . . . . . . . . . . . . . 85

5.6 Familiarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.6.1 Preferences . . . . . . . . . . . . . . . . . . . . . . . . 855.6.2 Long-term solutions . . . . . . . . . . . . . . . . . . . 865.6.3 Standardization . . . . . . . . . . . . . . . . . . . . . . 875.6.4 Benefit vs cost . . . . . . . . . . . . . . . . . . . . . . . 87

5.7 The influence of virtual DOM . . . . . . . . . . . . . . . . . . 875.7.1 One-way dataflow and declarative programming . . 885.7.2 Towards component-based structure . . . . . . . . . . 885.7.3 Increased usage . . . . . . . . . . . . . . . . . . . . . . 895.7.4 Expanding JavaScript’s usage areas . . . . . . . . . . 895.7.5 The goal behind React . . . . . . . . . . . . . . . . . . 89

5.8 The future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 905.8.1 Browser Virtual DOM . . . . . . . . . . . . . . . . . . 905.8.2 Angular is following . . . . . . . . . . . . . . . . . . . 915.8.3 The future web . . . . . . . . . . . . . . . . . . . . . . 91

5.9 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Conclusion 936.1 Research question 1: Performance . . . . . . . . . . . . . . . 936.2 Research question 2: Problem Areas . . . . . . . . . . . . . . 946.3 Research question 3: Impacts . . . . . . . . . . . . . . . . . . 94

7 Future work 95

ix

A Source code 101A.1 PhantomJS script . . . . . . . . . . . . . . . . . . . . . . . . . 101A.2 B: Sortable datatable . . . . . . . . . . . . . . . . . . . . . . . 102

A.2.1 React implementation . . . . . . . . . . . . . . . . . . 102A.2.2 Angular implementation . . . . . . . . . . . . . . . . 104A.2.3 Backbone implementation . . . . . . . . . . . . . . . . 106

B Survey Scheme 109

C Interview questions 111

D Quotations in Norwegian 113D.1 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113D.2 Simplicity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113D.3 Abstraction level . . . . . . . . . . . . . . . . . . . . . . . . . 114D.4 Familiarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114D.5 Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

x

List of Figures

1.1 JavaScript’s popularity. . . . . . . . . . . . . . . . . . . . . . . 3

2.1 The DOM tree structure. . . . . . . . . . . . . . . . . . . . . . 162.2 Object.observe() used in console . . . . . . . . . . . . . . . . 182.3 Three depths of dirty checking. . . . . . . . . . . . . . . . . . 242.4 How Angular interacts with the browser. . . . . . . . . . . . 252.5 Data binding in Angular. . . . . . . . . . . . . . . . . . . . . . 262.6 Virtual DOM: compare trees level by level. . . . . . . . . . . 292.7 Virtual DOM: effect of keys in list comparisons. . . . . . . . . 292.8 Virtual DOM: matching components. . . . . . . . . . . . . . . 302.9 Virtual DOM: dirty elements. . . . . . . . . . . . . . . . . . . 302.10 Virtual DOM: selective re-render. . . . . . . . . . . . . . . . . 31

3.1 The TodoMVC application . . . . . . . . . . . . . . . . . . . . 38

4.1 Test case A.1 and A.2: render times . . . . . . . . . . . . . . . 444.2 Test case A.3 and D: render times . . . . . . . . . . . . . . . . 444.3 Test case A-D: memory usage . . . . . . . . . . . . . . . . . . 444.4 Test case B: render times presented in charts . . . . . . . . . . 454.5 Test case C: results presented in charts . . . . . . . . . . . . . 454.6 Test case E: Memory usage. . . . . . . . . . . . . . . . . . . . 464.7 Test case E: render time results . . . . . . . . . . . . . . . . . 474.8 Test case F: initial load time . . . . . . . . . . . . . . . . . . . 474.9 Survey: framework familiarity in percentage . . . . . . . . . 484.10 Survey: degree of knowledge . . . . . . . . . . . . . . . . . . 494.11 Survey: difficulty in getting started . . . . . . . . . . . . . . . 494.12 Survey: familiarity with underlying concepts . . . . . . . . . 494.13 Survey: preferred framework among the students . . . . . . 50

5.1 Shallow and deep tree structure. . . . . . . . . . . . . . . . . 575.2 Visual progress on initial load. . . . . . . . . . . . . . . . . . 595.3 Structure of datatable element . . . . . . . . . . . . . . . . . . 625.4 Structure of TodoMVC item . . . . . . . . . . . . . . . . . . . 625.5 The frameworks’ popularity. . . . . . . . . . . . . . . . . . . . 89

xi

xii

List of Tables

1.1 The framework representing each technique . . . . . . . . . 4

2.1 Common JavaScript events used to notify changes . . . . . . 21

4.1 Test case E: Number of listeners. . . . . . . . . . . . . . . . . 464.2 Survey results specific to the frameworks . . . . . . . . . . . 514.3 Interview results specific to Angular . . . . . . . . . . . . . . 524.4 Interview results specific to Backbone . . . . . . . . . . . . . 524.5 Interview results specific to React . . . . . . . . . . . . . . . . 52

5.1 Rating of central properties of the techniques . . . . . . . . . 545.2 Rating of performance properties . . . . . . . . . . . . . . . . 555.3 Performance in O-notation . . . . . . . . . . . . . . . . . . . . 565.4 List rendering with dirty checking vs virtual DOM. . . . . . 645.5 Memory usage in test case E . . . . . . . . . . . . . . . . . . . 665.6 Framework size, production version . . . . . . . . . . . . . . 675.7 Rating the simplicity . . . . . . . . . . . . . . . . . . . . . . . 685.8 Rating the abstraction level . . . . . . . . . . . . . . . . . . . 775.9 Rating the scalability . . . . . . . . . . . . . . . . . . . . . . . 82

6.1 Total amount of points given . . . . . . . . . . . . . . . . . . 93

xiii

xiv

Listings

2.1 Using Object.observe() to observe changes on an object. . . . 182.2 Example of the set()-method . . . . . . . . . . . . . . . . . . . 212.3 Example of event listening . . . . . . . . . . . . . . . . . . . . 212.4 Watch expression in Angular . . . . . . . . . . . . . . . . . . 232.5 An example of the $watch() function . . . . . . . . . . . . . . 272.6 An example of the $apply() function . . . . . . . . . . . . . . 27A.1 PhantomJS script - 1 todo 1000 times . . . . . . . . . . . . . . 101A.2 Sortable datatable: React - HTML . . . . . . . . . . . . . . . . 102A.3 Sortable datatable: React - JavaScript . . . . . . . . . . . . . . 103A.4 Sortable datatable: Angular - HTML . . . . . . . . . . . . . . 104A.5 Sortable datatable: Angular - JavaScript . . . . . . . . . . . . 105A.6 Sortable datatable: Backbone - HTML . . . . . . . . . . . . . 106A.7 Sortable datatable: Backbone - JavaScript . . . . . . . . . . . 106

xv

xvi

Chapter 1

Introduction

During the last years, a lot has changed when it comes to the web and howwe use it. Earlier, the web consisted of static web pages, where the wholepage was re-rendered when something changed. During the last years,the browser engines have gone through a huge performance improvement,making it possible to put more logic on the client side. There has been achange in the way web pages are updated. Earlier, the whole page wasre-rendered, but today only relevant parts of the page are touched.

An increasing amount of web traffic comes from mobile devices, andtoday’s applications need to be designed with this in mind. Mobile deviceshave smaller screens, lower capacity and in general more limitations thanthe personal computers that have ruled the market until a few years ago.The applications are getting larger, with more complex user interfaces andunderlying data that is constantly changing.

The programming language JavaScript is used to a great extent indevelopment of web applications. One important point is to avoid tyingthe application data to the DOM. The web was built for documents, andthe DOM is therefore not suitable for the applications that are built today.However, the need for interactive applications is present, and we needsolutions for interactivity today.

The APIs offered by the web browsers are both inconsistent andslow. This has contributed to the development and usage of frameworks.Another reason for the widespread use of frameworks and libraries isfound in the language JavaScript itself. Like all programming languages,JavaScript has its drawbacks, and these have made it necessary to take useof third party frameworks and libraries to structure and organize complexapplication code. Without such frameworks it gets difficult to keep allparts of the application up-to-date and unnecessary dependencies are oftenfound.

The frameworks use different approaches to structure the code andkeep the underlying data and the user interface (UI) in sync, and thisthesis will focus on the techniques that can be used for this purpose.One technique that has been introduced newly is the use of virtual DOM.This technique opens for a new way of thinking and can be used asan alternative to the techniques mainly used in today’s well established

1

structuring frameworks, namely the techniques called dirty checking andkey-value-observation (KVO). The concept of a virtual DOM is not new,but it has not been used in the context of frontend development earlier.The virtual DOM technique minimizes the need for interaction with thereal DOM and attempts to provide a DOM better suited for applications.

This thesis explores the use of virtual DOM in front-end developmentand takes a closer look at what it brings. The problems encountered in theother popular techniques, dirty checking and KVO, are discussed, and welook at how the use of virtual DOM addresses these problems, and if newproblems occur.

1.1 Motivation

JavaScript has become popular and its usage is increasing. The followinglist gives an impression of its extent:

• 800 000 questions asked about JavaScript at StackOverflow.com, aquestion and answer site for programmers.[48]

• 600 vacant positions requiring JavaScript knowledge at StackOver-flow Careers.[49]

• 100 vacant positions requiring JavaScript knowledge at Finn.no,Norway’s biggest site for advertisements and services.[20]

• 60 000 repositories with the JavaScript tag at GitHub.com.[22]

Figure 1.1 shows the number of questions asked about JavaScript onStackOverflow each month from 2008 until today.[46] This graph confirmsthe rising popularity and usage of the language.

The topic discussed in this thesis is highly relevant today. There numberof JavaScript frameworks and libraries to choose among is high, and newones are constantly being developed. During the last years, dirty checkingand KVO have been used to a great extent in frameworks implementingthe popular MVC pattern. At the same time, the applications have gottenlarger and more complex, and problems that occur as a consequence of thisstructure have been discovered. There is an ongoing discussion about howapplications should be structured. There are a lot of different opinions onthe topic, and there is no agreement on what is the best method to use. Thevirtual DOM technique is new on the market, but has already become quitepopular among JavaScript developers. It is interesting and topical to takea closer look at the virtual DOM technique as it is a popular and highlydiscussed subject among JavaScript developers today.

The biggest virtual DOM framework, React, has become among the10 most popular JavaScript frameworks on GitHub, and the number ofquestions on StackOverflow is growing fast.[21, 47]

2

Figure 1.1: JavaScript’s popularity: questions asked on StackOverflow permonth from 2008 until today

1.2 Research Questions

The impression in advance is that virtual DOM brings some nice featuresand contributes to more efficient application development. The virtualDOM technique is well promoted by Facebook, and it is interesting to takea closer look at it to see if it is as good as it seems. Will the introduction ofvirtual DOM in this area lead to changes in the way applications are built,and make the development simpler and more efficient? To figure this out,the following topics and research questions will be investigated:

1. Performance: How does the performance of virtual DOM compareto the performance of dirty checking and KVO?

2. Problem areas: How does virtual DOM meet problem areas found inuse of KVO and dirty checking?

3. Impacts: What are the impacts of using virtual DOM in User Interfacedevelopment?

1.3 Clarification

The goal is to make a comparison of the virtual DOM and the techniquesdirty checking and KVO. To compare them, it is useful to look atperformance and experiences in real projects. To do this, each ofthe techniques must be represented by a framework implementing thetechnique. There are many structuring frameworks implementing thetechniques that are going to be compared, and throughout this thesis, thefocus is on one framework for each technique. There are variations betweenthe frameworks, but in the whole, the technique is used similarly. Theframeworks are presented in table 1.1. These are popular and widely used,and are therefore good representations of the techniques they rely on.

3

Table 1.1: The framework representing each technique

Technique Framework exampleDirty checking AngularKVO BackboneVirtual DOM React

1.4 Contributions

The contributions given by this thesis is a deeper insight to what the virtualDOM approach gives. The use of virtual DOM in frontend developmentis quite new, and the amount of research material available is thereforelimited. The research performed through performance tests, studentsurvey and interviews contributes in giving guidelines to which of thetechniques that are suitable for different applications. Different aspectsthat should be taken under consideration are discussed, and problems thatcome as a result of the techniques are clarified.

After reading the thesis, the developer should have a deeper under-standing of what the consequences of each of the techniques are, and why.The work performed in this thesis should give a better understanding ofthe advantages and disadvantages of the virtual DOM approach and makeit easier to decide whether or not it is suitable for a specific application.

1.5 Outline

Chapter 2: Background gives relevant information about web applica-tions, the language JavaScript and how the application data and theDOM are kept up-to-date. Different rendering techniques are ex-plained, and information about the two programming styles, imper-ative and declarative programming, is given. At last, the relevantframeworks implementing these techniques are described.

Chapter 3: Research Methods contains the research methods used in thisthesis. The performance tests are described in detail, together withinformation about the interviews and the student survey.

Chapter 4: Results presents the results from the performance tests, thestudent survey and the interviews.

Chapter 5: Discussion contains a discussion of the results in light of theresearch questions. Topics for discussion are performance, simplicity,abstraction level, scalability, the future and the virtual DOM’s impact.

Chapter 6: Conclusion concludes the research questions in light of thediscussion.

Chapter 7: Future Work presents suggestions to future work.

4

Chapter 2

Background

This thesis explores the use of virtual DOM in front-end development. Theconcept of a virtual DOM is not new, but it has not been used in this contextearlier. Facebook has taken use of an already existing idea and applied itto a new usage area. As the application UIs are getting more complex,Facebook started to search for complex user interfaces in other areas, andlook at what techniques they were using to handle the complexity. 3Dgames handle this by using the minimal change between two states todraw a new frame efficiently, and Facebook started to investigate the use ofthis technique in web applications. This led to development of the virtualDOM technique used in Facebook’s framework, React, where its task isto optimize the DOM interaction.[6] Virtual DOM has also been used inJavaScript earlier, to sandbox third-party scripts. Here the virtual DOMworks as a mediator that intercepts all access to the browser and decideswhat requests to accept and reject.[50]

The usage of virtual DOM in application development has beenadopted by several companies, and some of them are listed below.[6]

• Facebook is using their virtual DOM framework, React, internally fora lot of features. This includes the chat system, which was rewrittento use React.

• Instagram’s whole web application is build using React.

• New York Times takes use of it for parts of their page.

• The largest bank in Russia is built upon React.

• Khan Academy, a page offering exercises, videos and other elementsto teach math and other fields, transitioned their page from usingBackbone views to React.

• Firefox is using React internally.[36]

• Netflix announced the use of React.[31]

• Ember will adopt the virtual DOM technique in Ember 2.0 to simplifycommunication between components.[12]

5

• PayPal is using React in their applications, and even use it end-to-endin some applications.[44]

These companies that are taking use of the virtual DOM technique arebig and influential in the JavaScript community, and as a result, a lot ofsmaller companies are starting to use it too.[16]

The goal of using virtual DOM in front-end development is to simplifythe development of complex applications. To better understand whythis is needed, we need some background information. The languageJavaScript is used to build the applications, and this language has itsweaknesses. These weaknesses, together with the characteristics of today’sapplications, make it necessary to take use of frameworks and librariesto develop well-structured applications. The most used structuringframeworks are built upon a pattern called MVC, and the techniquesdirty checking and key-value binding (KVO) are mainly used to handle datachanges in the applications and render them in the UI. The rendering pathcontaining the DOM construction is relevant in understanding why re-renders and DOM operations are expensive, and why the virtual DOM canbe helpful. Different popular frameworks implement these techniques, andthe frameworks Backbone, Angular and React will be used throughout thisthesis to represent the techniques. Backbone uses KVO, Angular takes useof dirty checking, while React implements virtual DOM.

This chapter presents how applications have evolved, the languageJavaScript and its weaknesses, followed by characterization of today’sapplications. To better understand the value of using a virtual DOM, therendering path and the DOM construction are explained. Variations of theMVC pattern are presented in addition to the techniques dirty checking andKVO, before the frameworks Angular, Backbone and React are explained.

2.1 From static web pages to dynamic applications

The content of the web and the way we use it has changed drastically.In the beginning, web browsers were slow and used to display simplestatic web pages. As the time has passed, the web browser engines havebeen significantly improved and are now capable of running complexapplications.

Dynamic behavior was added to the web pages, and the user interfacebecame more important. Bigger parts of the web applications were movedto the client-side, to give better user experience. The introduction ofthe V8 JavaScript Engine, a high-performance engine to power the webapplications, enables for more logic at the client side, and makes it possibleto develop application that run fully on the client-side after the initialload. To give a better understanding of how the web has evolved, webcommunication will be described briefly.

6

2.1.1 Basic Web Communication

The communication is done over the HTTP protocol, between a Server anda Client, which usually is a web browser. The server is responsible forserving the web page, while the client’s task is to request the page fromthe server, and display it to the User. The following example shows howthe communication is done.

1. User: opens the web browser (the Client) and goes to http://google.com(the Server)

2. Client: sends an HTTP request to the Server requesting the page

3. Server: sends an HTTP Response message containing the requestedsource

4. Client: renders the received source into a human readable website

The User can continue interacting with the page, causing subsequentHTTP messages to be sent between the client and server.

2.1.2 Client-side applications

An application can be divided into server-side and client-side. The server-side includes everything that is performed at the Server, while the client-side includes everything that is run on the Client. This thesis focuses onthe client-side applications, more specifically the rendering techniques usedat the client-side.

As mentioned, more work has been put on the client as the perfor-mance of the web browsers has increased significantly through the web’sexistence. The work done at the client side includes making dynamic andinteractive web pages, taking care of temporary storage and communicat-ing with the server. To perform these tasks, client-side languages are used.The primary language is JavaScript, which is seen as the language of thebrowser.

Single Page Applications

A Single Page Application (SPA) is an application running in the browser.It does not require any page reload, as the whole application is kept inthe client. SPAs have been used for a long time, with various degree ofsuccess. Java applets and Flash were popular SPA platforms, but bothrequired third-party plugins to function. With the increase in JavaScript’spopularity, and the improved browser engines, JavaScript SPAs have takenover. A JavaScript SPA doesn’t require any plugin to be installed, and is theobvious choice today.[33]

Partial re-rendering

The traditional web pages re-render the whole page on every userinteraction. The browser interacts with the server and redraws the whole

7

page over again. If the web page is large, the web traffic is high, or if theInternet connection is slow, the reload of the page can take several seconds,resulting in a bad user experience.

As the client-side applications have become richer and contain morelogic, the need for a full reload has been minimized. More informationis stored at the client side, and updates can be made to the web pagewithout having to interact with the server. A SPA minimizes the timespend re-rendering, as the processing is done in the browser instead ofcommunicating with the server. All necessary data is retrieved with onesingle page load. The client contains the data and business logic necessaryto make decisions locally, and it can therefore perform quickly. Only theparts that changed need to be updated, and a full reload of the page isavoided.[33]

2.2 JavaScript

JavaScript has become very popular during the last years and is widelyused. The applications are growing in size and complexity, and JavaScript’snature makes the development of such big applications a challengingprocess. The code easily gets unclear in big applications. To avoid this,we need to take a closer look at the language JavaScript, its problems anddifferent ways to handle them.[8]

2.2.1 History

As more people started to use computers and the web, Netscape wantedto add interactivity to websites. They hired Brandon Eich to do this. Eichtook the syntax from Java, function model of Scheme and prototype objectsfrom the programming language Self, and put it all together in a newlanguage called JavaScript. Eich made this language in 10 days in May1995, because Netscape needed it to be finished quickly. Unfortunately,this has resulted in some flaws in the language, as it normally takes yearsto make a good, new programming language. Even though JavaScriptcontains some mistakes, it has become the most popular programminglanguage in the world and is the language of the browser.[51]

JavaScript is a language with a lot of possibilities, and this is one ofthe reasons why it has become so popular. It contains first class functions,which means that functions are objects and can be treated as any otherobject. Functions can have their own methods and data, and they canbe given as parameters to other functions. In addition, almost everythingin JavaScript is objects, which makes it possible to write object orientedcode.[14]

2.2.2 Challenges with JavaScript

Netscape wanted JavaScript to have Java syntax, and the intentions weregood. The idea was that the new language should be easy to use forbeginners, and in some ways it is. Many start programming in JavaScript

8

without any knowledge about it. They have experience from class-basedlanguages and want to take use of these experiences, but there are somefundamental differences. We will now take a look at how JavaScript isstructured, and some of the bad parts it contains.

The lack of classes

JavaScript is an object oriented language that uses objects and prototypes,but there is no concept of classes in the language. In class-based languages,every instance of a class has the same behavior, and optimized executablecode must be generated only once for each class and can be used for allinstances. In JavaScript, this is more difficult because of the lack of classes.The overhead of generating this code is often big enough to outweighthe performance improvements it gives, and it’s better to use the slowdictionary lookup in many cases. The JavaScript engine V8 takes use ofsynthetic hidden classes to avoid this problem, and this adds an extra levelof complexity. The lack of classes in the language has also led to manyJavaScript libraries containing their own emulation of class-based objects.By having classes as a part of the language, it would therefore have beeneasier to develop JavaScript libraries and engines. They would have beeneasier to use and more efficient.[8]

The lack of modules

There is no built-in module system in JavaScript, and this makes thedevelopment of large applications a challenging process. The built-inlibrary is small, and JavaScript applications depend on third-party librariesto a great extent. The lack of a modular system makes it difficult toensure that different libraries won’t conflict with each other. For instance,two different libraries might create objects with the same name and theapplication is broken.[8]

The application code is usually distributed over many JavaScript filesto make it easier to maintain overview of the different functionality. Thisresults in a large amount of HTML requests if the files are requested oneby one. To reduce the amount of data to be downloaded by the browser,libraries are used to avoid this problem by creating bundle files, which areminified versions of the source files grouped together.[52]

2.2.3 JavaScript Design Patterns

In software design, i.e. when writing JavaScript applications, thereare some commonly occurring problems. Design patterns are reusablesolutions to help solving these kind of problems. The patterns can be seenas solution schemes that make it easier for developers to solve problemsthat occur during a development process. The patterns are not solutionsthemselves, but offer support during the process of solving the problems.

A big advantage in using patterns is the support in structuring andorganizing the projects, making it possible to think less about the structureand more about the content of the application. By applying a clear code

9

structure from the start, it will be easier to maintain the code later, withouthaving to do a lot of refactoring. Some patterns also help in reducingrepetitive code and hence reduce the size of the code base.[38]

JavaScript offers a lot of possibilities and few restrictions on how tostructure the code, and this makes the use of patterns very helpful inthis language. There is no single pattern or group of patterns that arethe correct ones to use. Each individual application is different and hasdifferent structuring needs. It is important to choose patterns that benefitthe implementation. Some projects will benefit from using the observerpattern, which helps decoupling the code, while other projects are too smalland simple for this to offer real value to the implementation. Applyingunnecessary patterns to a project, just to use patterns, may result in morecomplex code and a heavier development process than what is necessary.

It is important to have knowledge about the different design patternsand what problems they aim to solve, as this will make it easier to choosethe right patterns for the applications, and also make it easier to integratethem into the application architecture.[38]

Today’s applications are large and complex, and most of the implemen-tations therefore take use of frameworks implementing different patterns.The characteristics of today’s applications will be explored next.

2.3 JavaScript Applications Today

The applications developed today are complex and often contain bigamounts of underlying data that is changing. Examples of such applica-tions are social media applications, like Facebook, Instagram and Twitter,email applications, like Google Mail, banking applications and newspa-pers, like VG. These applications, and a lot of others, have grown in sizeand complexity and are heavily using JavaScript. JavaScript is used by al-most 90%1 of all websites. These applications have some things in common,and the characteristics of today’s applications will be explored next.

2.3.1 Characteristics

Social media applications are popular today. The applications have a largeamount of users, and a large amount of underlying data. The data isusually changing, and these changes need to be reflected in the applicationview. The view is often formed as a list of information, where changes tothe underlying data lead to small changes in the list displayed. The usercan also trigger data changes by interacting with the application.

Another thing that is important is the constant evolution of theapplications. New features are implemented as the users’ needs andwishes are changing, and the functionality of the applications are expandedand changed. To sum it up, the following characteristics describe howapplications are build today, and give information about what needs to betaken into account when developing such applications.

1Report at w3techs.org, as of March 2015

10

• Complex user interfaces

• User interface formed as list with information

• Large amount of underlying data

• Changing data

• User interface reflects changes in underlying data

• Often small data changes that lead to small updates in the UI

• User interaction with the application can cause underlying data tochange

• Evolving applications - new features gets added

These characteristics raise the need for structured application develop-ment. With such complex applications bugs occurring are inevitable, and itis important to have an application structure that makes bug detection andcorrection as easy as possible. As new features are expected to be addedlater on, it is important to design the applications with this in mind. Itmust be possible to add new features without making major changes toexisting code to get it to work properly.

One of the big advantages with such applications is how easy it is torelease new versions. Web applications don’t require the user to downloadnew versions, and the problem with users having outdated versions istherefore avoided. Because it is so simple to add new features, it is possibleto make small changes over time, so that the users are getting used to thenew features instead of releasing a new, completely different interface withunfamiliar functionality.

2.3.2 Time to market

As the users are expecting new functionalities, and the needs are changingrapidly, it is important to get new functionality on the market as fastas possible. The competition between different providers is high, and itis important to be the first one to release new functionality to capturethe consumers. In addition to releasing new features in short time, it isimportant to fix bugs quickly.

All in all, the time to market is really important. The shortest time tomarket wins the consumers and this is where the money lies. To achieve ashort time to market, it is important with efficient development and testing.The application structure is significant here. By having an applicationstructure that simplifies the implementation phase, minimizes the amountof bugs and makes testing easy, it will be much simpler to make the productavailable quickly.

11

2.3.3 Performance

The way we look at performance has changed over the last years. Mobiledevices are used to great extent, and memory has become as importantas CPU, if not more important, on mobile devices. If CPU is wasted on amobile device, the application will be slow and the user will get a sluggishuser experience. However, if memory is wasted, the browser window willbe killed by the operating system, and the user gets no user experience atall.

Another limiting property of mobile devices is the battery. If CPU cyclesare wasted, it results in high battery usage, which must be avoided. TheJavaScript applications have become large and highly complex, with a lotof work being performed at the client, causing client-side performanceto become an issue. The JavaScript speed in browsers has increaseddrastically, but the performance is still a problem. There are severalcommon traps that give performance problems, and one of them is DOMaccess. DOM interaction is slow, as explained in section 2.4, and it shouldtherefore be minimized.

Frame rate

To get an application that is working smoothly, the frame rate is important.Frame rate is a measurement of number of frames per second (fps). Thehigher the frame rate is, the smoother the application will look. At thesame time, a high frame rate means more processing, as more work needsto be done.

The screens today usually refreshes at a rate of 60 Hz, and the goalshould therefore be to aim for a frame rate of 60 fps. A frame rate of 60fps means there is 16,7 ms to get all work done within a frame. To beable to achieve this, it is important to optimize the application code. InJavaScript, the function requestAnimationFrame can be used to optimizeperformance. By using this function, the browser will perform the updateat the next available opportunity. This makes it possible for the browser tobatch several updates into one re-render. The result is fewer CPU cyclesand less battery usage, which is important on mobile devices. It will alsobe possible for the browser to optimize the performance based on hiddenelements and battery status. If the elements are scrolled out of view, theuser switches to another tab, or the battery level is low, the update rate canbe decreased.[35]

2.3.4 Application structure

The MV* Patterns are architectural patterns that have been used a lot instructuring desktop and server-side application in the past, but it’s not untilthe last few years that these patterns have been applied to JavaScript.[38]

The MV* patterns consist of

MVC - Model-View-Controller

12

MVP - Model-View-Presenter

MVVM - Model-View-ViewModel

Nowadays, most JavaScript developers are applying these patterns totheir project during use of different frameworks that implement variationsof the patterns. There exist a lot of widely used frameworks giving supportfor variations of MV*. These frameworks simplify the developers’ task tocreate well-structured applications without a lot of extra work.[38]

The underlying principles are the same for the different MV* patterns.The MVC pattern and the components it consists of will be explained togive a better understanding of the patterns.

2.3.5 MVC pattern

The MVC pattern, Model-View-Controller, is an architectural designpattern that aims to improve the code structure by separating differentparts of the application. This pattern was in use back in the 70s, butin modern times it has been applied to a lot of programming languages,among them JavaScript. Each component has responsibility for a separatepart of the application, and it is easier to avoid unclear and unorganizedcode. The MVC pattern consists of three core components; model, viewand controller.[38]

Because of the modularization, it is easy to know where changes haveto be made when something needs to be updated. If the changes are data-centric, there will be changes in the models and perhaps controllers. If thechanges are visual, it means changes have been made to the views. Themodularization also makes it easier to write unit tests for business logic,and duplication of code will be avoided. Since the core logic is separatedfrom the user-interfaces, it is possible for developers to work on these partssimultaneously.[38]

MVC can be seen as a variation of three classical design patterns. Theseare the Observer, the Strategy and the Composite patterns. Depending onimplementation, it may also use the Factory and the Template patterns.Knowledge about these patterns could be useful when working withMVC.[38]

In MVC, the observer pattern is used in the communication betweenmodel and views, as a model notifies its observers, or views, when ithas changed. Views and controllers communicate differently and use thestrategy pattern. Controllers help deciding what views should respond todifferent user input.[38]

Model

A model contains the data in an application. It doesn’t contain anyinformation about user-interface or how the data is presented, its task is justto manage the data only. The model has observers that are interested in itsdata, and these observers get notified when a change in the data occurs.These observers are views, which will be explained shortly. Multiple

13

views may be observing the same model, because a model may containinformation that is interesting to display in different views.[38]

Modern MV* frameworks often give the possibility to group modelstogether. This makes it possible for observers to observe the whole groupinstead of having to observe each individual model instance manually.This grouping functionality is given through the use of a Collection inBackbone.[38]

View

Views are responsible for the visual representation of data in the appli-cation. The view builds a DOM element and maintains it as the modelsit observes change. The view observes the model, and it will be notifiedwhen the model changes. This makes it possible for the view to updateitself when changes occur to the data it represents. The view needs to havesome utility that handles the rendering of the user interface when changesoccur at the model it observes. By using the observer pattern, the modeltriggers its observers to update by using this utility defined in the view.[38]

Views are the presentation layer of an application, they are the userinterfaces and normally display the data in a user friendly way. The userscan interact with the views and read and edit the data displayed.[38]

The view gives the user access to the data contained in the models andthe possibility to make changes to the information. If the user changesthe data, it needs to be updated in the model where it came from. Theview only displays the information, it doesn’t decide what to do when theuser interacts with it, for instance clicks on an element within the viewor changes a value. The task of deciding what should happen when auser clicks an element, or the task of updating the data in the model, musttherefore be performed by another component, and the controller discussednext is responsible for this.[38]

Controller

Controllers manage logic and coordination between the views and themodels in an application. They are responsible for updating the modelwhen the user interacts with the view and makes changes. The viewdelegates the handling of user events to the controller, and the controllerdecides what should happen. The use of controllers is an easy way tohandle changes between a model and a view.[38]

2.4 The Rendering Path

To better understand how applications should be optimized for moreefficient rendering, it is important with knowledge about what happensin the browser to get the application displayed on screen. The browser hasto go through several steps to perform this task. In this section, importantconcepts and the steps in the rendering path are described.

14

2.4.1 The DOM

The DOM, the Document Object Model, provides a structured representa-tion of HTML documents. This representation is structured by organizingthe elements in the document into a tree, called the DOM tree. The ele-ments of the tree have properties and methods that can be used to modifyit, which makes it possible for programs to dynamically access the DOMand make changes to its structure, content and style.[34]

The DOM was designed to be language-independent and offer a single,consistent API to access and modify the DOM representation of thedocument. JavaScript can be used to access and modify DOM elements.

Most of today’s browsers implement the DOM following the specifica-tions in the W3C DOM standard2. There are still some variations betweenthem, but every browser contains some DOM to make it possible to scriptweb pages.

Browser reflows

DOM interactions can make it necessary for the browser to change how theelements are displayed on the screen, and this process is called browserreflow. Browser reflow can be triggered by direct DOM manipulations,changes in the elements’ CSS styles, resizing the browser or changinglayout properties like offsetHeight and offsetWidth. Each browserreflow is time consuming, and it is therefore important to minimize theneed for browser reflows to achieve more efficient applications.[25]

DOM interactions

As mentioned, we use JavaScript to update the document in the browser.We can change, add or delete elements, and this is done by interacting withthe DOM. The DOM interactions can be done in different ways, and thereis no single method that is the correct one. However, it is not indifferenthow the interactions are carried out, as it can affect the performance of theapplication. Some patterns can be followed to reduce the amount of reflowstriggered in the browsers, and the key behind them all is minimizing theamount of DOM access. [25]

2.4.2 Browser rendering

The browser is responsible for rendering the page to display, and it needsto construct the Document Object Model (DOM) and CSS Object Model(CSSOM) to do this. These two object models are independent and describedifferent aspects. The DOM describes the content of the page, while theCSSOM handles the styling.

2More information about the W3C DOM standard is available at www.w3.org/DOM

15

Figure 2.1: The DOM tree structure. Figure from [23]

DOM construction

The browser reads raw HTML bytes received, and converts them intoobjects with properties and given rules.3 HTML markup defines howdifferent tags are related, and this makes it possible to arrange the createdobjects in a tree-structure that captures the relationships in the originalHTML markup, as shown in Figure 2.1. The result of this process is theDOM, which is used in all further processing of the page.[23]

The browser needs to construct the DOM every time it processes HTMLmarkup. This process can be time consuming, especially if the amount ofHTML to process is large. The process of creating the DOM is incremental,which means that the browser can start creating the DOM before the entireHTML document has been received.[23]

CSSOM construction

The HTML markup used to construct the DOM can also contain CSS stylesheets that the browser needs to be able to render the page. In the sameway as with the DOM construction, the browser creates a tree structure. Itprovides a set of default styles to be used where no custom CSS styles havebeen provided and these are also part of the tree. The tree created is theCSSOM.

Render-tree construction

After the DOM and CSSOM have been created, they need to be puttogether. The browser starts at the root in the DOM tree and traverses allvisible nodes. Only content that should be visible on the screen is part ofthe render tree. Nodes that are invisible, like script tags and metadata, andnodes hidden by use of CSS are excluded from the render tree.

For each of the visible nodes, the browser uses the CSSOM to findmatching style rules and adds them. The render tree constructed nowcontains information about both content and styles to be displayed.

3Details have been left out. There exists a lot of material on the topic on the web.

16

Layout and paint

Now that the render tree is created, the browser needs to decide whatthe layout should look like. The layout step is also referred to as reflow.The browser needs to calculate the exact size and position of the elementsin the render tree. Once again, the browser starts from the root node inthe render tree and traverses it to calculate the size and position of eachelement. When this information is computed, everything is ready to startthe painting step. In the painting step, each node in the render tree istransformed to pixels on the screen.

Time consuming

The time spent creating the render tree, layout and paint depends on thedocument size, styling and the device the browser is running on. Largedocuments with advanced styling are more time consuming than small,simple documents. If the DOM or CSSOM is modified, the whole processneeds to be repeated. This is the reason why DOM operations are slow. Itis therefore important to optimize the rendering path to minimize the timespent in the rendering phase. The amount of DOM interactions should beminimized to reduce the time spent on rendering.

2.5 Change detection

Data often changes and it is necessary to keep track of the changes tobe able to perform the actions that should be done due to the changes.When developing JavaScript applications, it is desirable to detect changesinstantly after their occurrence. This might be addition, deletion or changesmade to raw JavaScript objects, properties or arrays. There are severalapproaches used to detect changes and update the application accordingly,and this topic will be discussed in detail.

2.5.1 Data Binding

There is need for separation of concerns, like MVC, in large applications. Tokeep the DOM up-to-date and reflect the data, information needs to be sentbetween the data models and user-interfaces. Doing this manually requiresa lot of repetitive code which increases the complexity of the applicationand is time consuming. This is where frameworks that handle data-bindingare useful.

Data-binding means that whenever data in the model changes, the UIis updated to reflect these changes. Two-way data binding is data bindingin both directions - when data models change, UI is updated, and when UIis changed, data models are updated accordingly.

Instead of having to write code manually to do this, frameworks takecare of data-binding by setting up relationships between properties in thedata models and elements in the views. Today’s large MV* frameworks usedifferent techniques to carry this out. The techniques are presented in thenext sections.[37]

17

1 \\ creating empty person object

2 var person = {};

34 \\ observing the person object

5 Object.observe(person , function(changes) {

67 \\ asynchronous callback

8 changes.forEach(function(change) {

9 \\ writing changes to console

10 console.log("Person changed:", change.type , change.name ,

change.oldValue);

11 });

12 });

Listing 2.1: Using Object.observe() to observe changes on an object.

Figure 2.2: Object.observe() used in console

2.5.2 Object.observe()

Object.observe() will be part of a future version of JavaScript. Somebrowsers already support it, like Chrome 36 stable.[11] Object.observe()’stask is to observe changes on JavaScript objects asynchronously. Thismakes it possible to implement two-way data-binding without the needfor any additional framework or library. The example in listing 2.1 showshow the method is used.

In this example, the empty object person is created. Next, the methodObject.observe() is used to observe the object. Information will be writtento the console on change. In figure 2.2, a property name with value Bob

is added to the person object. The change is observed and a messagecontaining change name, type and old value is printed in the console.When a nonexistent property is added, the change type is add, while itis update when an existing value is changed. If an observed elementis deleted, the change type is delete. To stop observing an object,Object.unobserve is used; Object.unobserve(person, observer;).[37]

18

2.5.3 Web Components

Web Components are a set of four W3C specifications, and the standardsare developed by Google. The standards are supposed to part of the webbrowsers, but for now it is under development and only supported by someof the newest browser versions. Web Components promise encapsulation,composability and reusability with HTML elements, and the goal is tobring component-based development into the World Wide Web. Thesespecifications provide new features that don’t already exist in HTMLnatively, without the need for any additional libraries or frameworks.Because the API is the web platform itself, the Web Components areportable.[40]

Web Components are composed of the following four standards:

Custom Elements that makes it possible to create your own HTML tags

Shadow DOM makes it possible to put styles and markup in a separate,hidden DOM tree.

HTML Templates are used to define blocks of markup with dynamiccontent

HTML Imports makes it possible to import and use HTML documents aspart of other HTML documents

Custom Elements and Shadow DOM are the most important parts here,and will be briefly explained.

Custom Elements

Custom Elements opens for the possibility of developers creating their ownHTML tags and use them natively in their HTML. These custom elementsenables for easier component reuse, as they doesn’t require any specificframework or library to be used. The custom elements are supportednatively in the browser.[29]

Shadow DOM

Shadow DOM gives the ability to create a shadow root underneath a DOMelement, which can possibly be a custom element. The shadow DOM isa hidden node tree underneath the element and opens for style and DOMscoping. Other DOM nodes and style tags can be put in this tree, and it willnot affect parent elements outside the tree. In the same way, styles definedoutside the tree will not have any impact within the tree.[30]

2.5.4 Today’s situation

Today, it is not possible to observe changes on plain JavaScript objects. TheObject.observe() method is not fully available yet, and it is necessary totake use of other techniques to detect changes. Techniques used to achievethis today are key-value observation, dirty checking, and the newcomer virtualDOM. These techniques will be explored in the following sections.

19

2.6 Key-Value Observation

One technique that is highly used in MVC frameworks is key-value-observation, often referred to as KVO. This technique takes use of changeevents and change listeners to detect changes and do the necessaryupdates. The observer pattern and the similar Publish/Subscribe patternare important here.

2.6.1 The Observer Pattern

The Observer Pattern is a highly used pattern in data binding. Here wehave subjects that fire events, and objects, or observers, that observe theseevents. This is done by having the observers subscribe directly to the objectfiring the event.

This pattern may lead to unwanted dependencies between the subjectand the observers, and there is another similar pattern that can be used toavoid these dependencies. This pattern is the Publish/Subscribe pattern.A topic/event channel is used between the object firing events and theobjects that want to receive notifications. This pattern is used widely incommunication between components in different structuring frameworks,like Backbone. These patterns are useful in the case when we needconsistency between objects, but don’t want them to be tightly coupled,like when designing decoupled systems.[38]

2.6.2 Accessors on Container Objects

The concept of container objects comes from objects being created byextending classes provided by a framework. The plain JavaScript objectswith the actual data are contained in objects predefined by the framework.These container objects have methods to access the data in the objects. Aget() method is used to get the data, while set() is used to change thedata.

The use of accessors makes it possible to keep track of the changes atthe time they happen and inform the view about what has changed. Theinformation about changes is given by use of the observer pattern describedabove. This method is used by many of today’s popular frameworks,including Backbone.

The set() method

The set method is used to update the data and notify those who need toknow about the change. When the method gets executed, the data changesare performed, and relevant events are triggered. These events are thechange event in addition to change:attribute for each of the changedattributes. In Listing 2.2, we assume the model Person is instantiated,and the attributes name, age and address are set. The name and ageattributes of the model person is changed. This causes the events "event","event:name" and "event:age" to be triggered.

20

1 var person = new Person ({name: "James", age: 40, address:

Albuquerque });

23 person.set({name: "Saul", age: 41});

Listing 2.2: Example of the set()-method

Table 2.1: Common JavaScript events used to notify changes

Event type Descriptionadd a model gets added to a collectionremove a model gets removed from a collectionchange an attribute of the model changessort the collection has been resortedreset the collection’s content has been fully replaced

The get() method

The get method is much simpler. The only task of this function is to getthe required attribute from within the container object. The reason why theattributes are not accessed directly is the need for change detection madepossible by these accessors.

Event listening

There exist different types of events that are used to notify different typesof changes. In addition to the events being triggered by the frameworks, itis also possible to trigger events manually. Table 2.1 presents some of themost common events.

Objects interested in getting notified of changes can listen to the eventsfired. A callback function is registered to the events of interest. Each eventcontains an array with the bound callback functions. When an event getstriggered, the callback functions bound to the event gets fired. It is alsopossible to stop listening for further changes. The callback function willthen be removed from the event’s list of bound callbacks.

In Listing 2.3, view is listening to name changes, while view2 is listeningto all changes on person. This means that the callback function view.render

is bound to the "change:name" event, and view2.render is bound to the"change" event.

1 view.listenTo(person , 'change:name', view.render);

2 view2.listenTo(person , 'change ', view2.render);

3 view.stopListening(person);

Listing 2.3: Example of event listening

21

2.6.3 Dataflow

Events are used for communication between the data and the views. Whenan action in the UI causes a data attribute to change, a change event istriggered. The event makes it possible for all views displaying the datamodel’s state to update according to the data changed. When the modelchanges, the views update themselves.[5]

The data binding can be done by using manual events, or throughthe use of a separate key-value observing library. The event-drivencommunication gives explicit control over what is happening, and thedeveloper decides how the data flows by adding event listeners where heor she wants.

2.7 Dirty checking

Dirty checking is another technique used to detect changes. Whenever itis possible that a change might have happened in the application, a loopis executed to see if any of the data values in the application actually havechanged. This loop is performing what is called dirty checking. The loopexamines all data elements and checks if it is different from the previouselement version. The value is said to be dirty if it has changed, and this isthe reason for the name dirty checking. The data that should be watchedfor changes is registered, so that the dirty checking algorithm knows whatdata to check or not.

The dirty check is done through the execution of a digest or changecycle. The dirty check needs to be done whenever it is possible that a datachange might have happened, for instance on user interaction. The checkcycle is costly, as it needs to traverse all the watched data and compare itto the previous version of the data, and it is therefore important to onlyexecute it when it is needed.

With dirty checking, there is no need for container objects or accessors,as opposed to KVO. All watched expressions are traversed to lookfor changes, whenever something might have changed, and ordinaryJavaScript objects can therefore be used.

Angular is the most popular framework using dirty checking, and thisframework will therefore be used in the explanation of how dirty checkingworks. All data elements within Angular’s concept of a scope will bewatched by the dirty checking algorithm, and elements, or expressions,that might change is therefore registered within this scope.

The dirty check is performed within a digest cycle. When the digestcycle is executed, it loops through all the data elements within the scope,and compare them to their previous values. Angular’s $apply method isused to signal a possible data change. The execution of the $apply methodstarts a digest cycle, where the dirty checking is performed.[4]

All watched expressions are examined and their values are comparedwith their previous values in the digest cycle. The dirty checking is doneasynchronously, which means that a change to a watched value will notcause a change event to be fired immediately. The watchers are not notified

22

1 $scope.name = 'James ';

23 $scope.$watch( function () {

4 return $scope.name;

5 }, printChange);

67 var printChange = function(newValue , oldValue) {

8 console.log('$scope.name was changed to ' + newValue + '!')

;

9 }

Listing 2.4: Watch expression in Angular

about the change until the digest cycle is executed and the change isdetected. The advantage with this approach is that the delay gathers upseveral changes into one watch notification.[4]

2.7.1 Listeners

When the dirty check has finished and one or more changes have beendetected, the listeners, also called watchers, will be notified. The listenersregister a listener callback to the expression that it wants to observe.Angular uses the $watch function, as shown in Listing 2.4. The printChange

function will be called when the digest cycle detects that the name haschanged from the previous version. The callback function has access toboth the new and the previous value.[3]

The listener can possibly change the model, which again causes otherlisteners to be fired. This is solved by rerunning the comparisons of thewatched expressions until no changes are detected. Angular has limitedthe maximum reruns to 10 to avoid infinite loops.[3]

2.7.2 Interaction with the browser event loop

Figure 2.4 gives an overview of the interaction between Angular and thebrowser’s event loop. The event loop in the browser is waiting for an event,which might be a result of user interaction, a timer- or a network event.When receiving an event, the event’s callback gets executed in JavaScriptcontext.

Angular adds an Angular context within the JavaScript context. Onlyfunctions executed in the Angular context will take use of the framework’sfunctionality. It is possible to enter this context through use of Angular’s$apply function. The callback most probably changes the application state,and the digest loop is entered. When the digest loop has finished, theexecution leaves the Angular and JavaScript context. The callback mayresult in DOM modifications, and the browser re-renders the DOM toreflect these changes.[4]

23

Figure 2.3: Three depths of dirty checking. Figure from [4]

2.7.3 Performance considerations

The dirty checking is performed often, and it is important that thealgorithm is efficient. The dirty checking should not interact with or accessthe DOM, as DOM operations are much slower than accessing propertieson plain JavaScript objects. There are three strategies that can be usedto perform the dirty checking. They are different in how deep they lookfor changes and therefore perform differently. The three strategies aredescribed by [4] in the following way:

Watching by reference is the most efficient strategy. A change is onlydetected if the whole value is replaced by a new value. In otherwords, the value’s reference must be changed for a change to bedetected. If the watched value is an object or array, changes to thevalues within the object or array will not be detected. Because nodeep comparison is performed, this is an efficient strategy. As shownin Figure 2.3 under By Reference, the change will only be detected ifthe reference is replaced.

Watching collection contents goes one step deeper and detects changeswithin an object or array, in addition to reference change. Thisdetection covers addition, deletion or reordering of the elementswithin the watched object, but not changes inside these objects. Anexample is shown in By Collection Items in Figure 2.3 This strategydoesn’t perform as well as the previous method, because copies ofthe collection content must be maintained.

24

Figure 2.4: How Angular interacts with the browser. Figure from [4]

Watching by value detects any change that happens within the watchedelement. This strategy is the most powerful, but also the mostperformance demanding. In every digest cycle, all nested datastructures must be fully traversed, and a full copy of the data needsto be kept in memory. An example of how it works is shown in Figure2.3.

2.7.4 Dataflow

The dirty checking approach gives a two-way data binding. When awatched element is changed in the DOM, it is detected by the dirtychecking algorithm and is reflected in the model. The same holds the otherway around - a change is detected in the data and reflected in the DOM.

Data-binding in Angular

In angular, the view always reflects the model. When a change happens inthe view, it is reflected in the model, and similarly the other way around.Angular uses two-way data-binding in contrast to most other frameworks.Any changes made to the view are immediately performed to the model,and any change to the model is propagated to the view, as shown in figure2.5. The model works as the single-source-of-truth for the application state,and the view can be seen as an instant projection of the model.

25

Figure 2.5: Data binding in Angular. Figure from [2]

When a data binding is created between the view and a data elementin the $scope, a watch will be created internally. This is done by defininga variable in the scope and using it in the following way: <span>{{value}}</span>. The value in the template will always reflect the value in the scope.

It is also possible to create watches by using the function $scope.$watch().The function $digest() is the function that updates the data binding. Thefunction is executed whenever a change might have occurred, and its taskis to detect changes and notify the corresponding listeners, which makereactions to the change, like updating a DOM element to reflect the newvalue of the changed element. In most cases, the $watch() and $digest()

functions are called internally. The $apply() function is used to integrateAngular with other JavaScript code. This function executes some code andcalls the $digest() function in the end, so that possible changes are de-tected and reacted upon. The rest of the section will be used to explainthese central functions in more detail, to give a better understanding onhow the data binding in Angular is done.

$watch()

The $watch() function is used to watch, or listen to changes, to someexpression. Listing 2.5 shows how the function is used. The first parametergives the variable to be watched. This variable can also be given as afunction returning the expression to be watched. When the dirty checkis performed, the watched value is compared to the previous version of thewatched value. If the value has changed, the listening function specified in

26

1 $scope.value = 1;

23 $scope.$watch('value', function () {

4 alert('value changed!');

5 });

Listing 2.5: An example of the $watch() function

1 $scope.$apply(function () {

2 $scope.value = 2;

3 });

Listing 2.6: An example of the $apply() function

the second parameter will be executed.

$digest()

The digest function is where the dirty checking is performed. All watchedexpressions are iterated over, and the values are compared with theprevious values. If differences are detected, the corresponding listeners arecalled. The function is executed whenever Angular detects that somethingmight have changed, for instance after a button click. In some cases, whena data change is performed outside Angular’s control, changes are notdetected by the framework, and the digest function will not be triggered.In this case, it is possible to call the $digest() function manually, or takeuse of the $apply() function explained below.

$apply()

The $apply() function can be seen as a function used to integrate Angularwith the code outside the framework’s control. If a watched expressionis changed within the framework’s control, Angular will know that itmight have changed and perform the dirty checking. However, if thewatched values are changed outside the framework’s control, Angulardoesn’t detect the change and needs to be notified. The $apply() functiontakes a function as parameter and executes the function before executingthe $digest() function. Listing 2.6 shows how the function is used.The variable value is changed, and the $digest() function is executedafterwards.

2.8 Virtual DOM

The virtual DOM approach lets the developer describe how the applicationshould look at any given time, and the virtual DOM takes care of makingthe UI updates to display the correct view. When the underlying data inthe application changes, the virtual DOM updates the UI by only updatingthe parts that has changed.[18]

27

The concept of a virtual DOM concerns the creation of a shallow DOMrepresentation without constructing the actual DOM representation. Thevirtual DOM representation is created using JavaScript and is way moreefficient than creating the real DOM representation. A new virtual DOMrepresentation is created on change. By computing the differences betweenthe new and the previous virtual DOM representations, the minimalchanges that need to be executed on the DOM are found.[18]

The technique is not new and has been used in areas like 3D gamesearlier. What is new, is the use of a virtual DOM in front-end developmentto update the UI both efficiently and automatically without having to writebig amounts of boilerplate code. The developer describes how the UIshould look, and the rest is taken care of automatically.

To find the minimal difference between two virtual DOM representa-tions, a diff algorithm is used. This algorithm needs to be efficiently imple-mented to give well-performing applications. There are several ways toimplement the algorithm, but the concept is the same. The framework Re-act is the biggest virtual DOM implementation today, and its diff algorithmwill be explored to give an insight in how the diffing is done. The goal ofthe algorithm is to find the minimal number of steps that needs to be exe-cuted to go from the existing UI render to the next one. React will be usedto represent the virtual DOM approach throughout the thesis.

2.8.1 Components

The virtual DOM representation is a tree structure consisting of combinablecomponents. Each component consists of a JavaScript representation ofthe different DOM elements it contains. A component can be built ofsubcomponents, and in this way, the tree structure is created. There isone component at the top-level, containing sub-components, which againmight contain components, and so on. All code regarding the functionalityof the component is found within the component itself.

2.8.2 Diff algorithm

Finding the minimal set of differences between two trees can be done inO(n3) time, which is too slow for this usage. The following implementationtakes use of a simple heuristic that gives a good approximation in O(n)time. The idea is simply to compare the trees level by level, as shownin Figure 2.6. The Before-tree represents the virtual DOM representationcreated before the change, and the After-tree is the new representation.Components are usually moved among the children at the same level andare rarely moved to another level in the tree. The consequence is a muchless complex algorithm with little loss, as the excluded cases rarely happen.The component structure and unique key values are also used to optimizethe diffing.[9]

28

Figure 2.6: Virtual DOM: compare trees level by level. Figure from [9]

Figure 2.7: Virtual DOM: effect of keys in list comparisons. Figure from [9]

Keys and Components

If a list with components gets changed, for instance by adding or removinga component at the middle of the list, it is hard to map the old list and thenew one correctly, as the naive approach is to associate the first one withthe first in the other list, and so on. By using a key attribute, where eachchild component has a unique key, it is possible to improve this mappingby comparing the components’ keys. This is illustrated in Figure 2.7 Asa consequence, the time spent doing comparisons can be significantlyreduced, as the unique key is used to decide which components belongtogether and should be compared. This contributes in making the diffalgorithm faster.

In React, an application usually consists of user defined componentsthat are put together in some way. The virtual DOM tree that is createdmainly consists of div tags, which is the most common native HTMLtag, but the user defined component classes are also taken into account.This makes it possible to avoid spending time comparing divs that arerepresenting different components. For instance, if a <ListElement> isreplaced by a <ListStatistics> element, the element will be replacedwithout spending time trying to match the components’ content. Figure2.8 illustrates this. The result is a more efficient diff algorithm.[9]

2.8.3 Event handling

It is both slow and memory-consuming to add event listeners to DOMnodes, and React has therefore chosen to implement a new event systemcompliant to W3C. One single event listener is added to the root of the

29

Figure 2.8: Virtual DOM: matching components. Figure from [9]

Figure 2.9: Virtual DOM: changed elements marked as dirty and sub-treesget re-rendered. Figure from [9]

document. When an event is fired and the browser delivers the targetDOM node, React doesn’t need to traverse the virtual DOM tree. Becausethe components in React have unique identifiers that encode the hierarchy,string manipulation can be used to retrieve the identifiers of all parents ofthe target node. The event listeners are stored in a hash map instead ofattached to the virtual DOM, because it performs better.[9]

2.8.4 Rendering

When the data contained in a component is changed, the component ismarked as dirty and will be re-rendered at the end of the event loop.This is shown in Figure 2.9. During an event loop, the DOM is updatedexactly once. The batching of the updates is an important property inbuilding well-performing applications. The diff algorithm is used to findthe differences between the current virtual DOM and the new virtual DOM.When these are found, they are used as instructions for modifying the realDOM in one big batch using requestAnimationFrame. As a result, thedeveloper doesn’t have to perform DOM operations himself.[9]

Sub-tree Rendering

When a component is marked as dirty, the virtual DOM for the compo-nent’s children is rebuilt. If the root element is marked as dirty, the en-tire application is rebuilt. Even if some components did not change, theirrender method will still be executed. Because the execution of the render

30

Figure 2.10: Virtual DOM: selective re-render. Figure from [9]

method never interacts with the real DOM, and the JavaScript code exe-cutes fast, this is not a problem. Usually the state is changed at a componentclose to where the change event happened. This causes only the sub-treewith the dirty component as a root to re-render, as shown in Figure 2.9.[9]

Selective Rendering

Even though a component is marked as dirty, it doesn’t mean thatall subcomponents need to be re-rendered. In React, the methodshouldComponentUpdate() can be implemented to increase the perfor-mance. By using information about the previous and next state it is possi-ble to prevent the component from re-rendering if it has not changed. Thismethod will be called often, so it is important that it is efficient and less timeconsuming than the process of actual re-rendering the component. Figure2.10 illustrates the advantage of selective rendering.[9]

2.8.5 Facilitates declarative programming

The use of virtual DOM opens for a declarative programming style. Theprogrammer only needs to specify what the DOM should look like (as astatic function of the application state), and not how it should be done, asthis is taken care of by the underlying virtual DOM.

2.8.6 Dataflow

All data flows in one direction, and it can be thought of as one-way databinding. Data changes cause the view to update. Many applications needthe ability to read data and flow it back into the program too, for instance toupdate the state when the application receives user input through a form.This is solved by the use of event listeners. When a change event occurs,the data source is read, and the state is updated by calling a function, thesetState() function in React. React also provides a ReactLink that canbe used to set up two-way binding. ReactLink is syntactic sugar for themethod described above.[17]

31

2.9 Declarative and imperative programming

Declarative- and imperative programming are two different ways ofwriting code. In imperative programming, the focus is on describing thesteps that should be done, rather than on what will be done as a result ofthese steps. In declarative programming, the focus is on what should bedone, rather than on how it should be done. In other words, imperativeprogramming states how a task should be performed, while declarativeprogramming states what the task is and lets the system take care of how itis done.[39]

2.9.1 State

The two approaches can also be differentiated by the concept of astate, which are the values that make up the intermediate results of acomputation. The state can be implicit or explicit. Implicit state onlyresides in the head of the programmer and does not require supportfrom the computational model. Explicit state exists over more thanone procedure call, without being part of the procedure’s arguments.The explicit state is visible in both the program and the computationalmodel.[19]

The declarative approach is seen as stateless because an evaluation canbe carried out on partial data structures. The imperative approach, onthe other hand, is seen as stateful programming, because the result of acomponent depends on both its arguments and its internal state.[32]

2.9.2 Mental representation

When developing an application, the code is not written sequentially.The developer works on different parts of the problem, which resultsin constants revisits to the current work context. For programmingto be efficient, it is important that the external program maps to theprogrammers’ mental representation. The "mental operations theory"states that the fewer mental operations that are required from a person toperform any task, the better are the performance.[19]

2.9.3 Sequential and circumstantial information

A program may contain both sequential and circumstantial information.Sequential information describes how input conditions give a certainoutcome, while circumstantial information describes the conditions thatproduced a certain outcome. There are empirical evidence to thatimperative programming display sequential information in a clear way,and that declarative languages display circumstantial information in aclear way. At the same time, imperative programming seems to makecircumstantial information obscure, and declarative programming makessequential information unclear.[19]

32

2.9.4 Simple start

It has been found that it is easier to start with declarative programmingfor people that start with programming. This is because the goal ofprogramming is to solve a task, and by being able to focus only on thestatement of the logic to perform this task, it is easier for beginners to get itdone. Normally, everything is not correct at once, and debugging is neededto find the mistakes. Declarative languages can take use of a debuggingtechnique called declarative debugging. In short, the main idea behind thistechnique is that knowledge about the intended interpretation of the codeis enough to detect the cause of wrong or missing answers.[32]

2.9.5 Simple semantic

A simple semantic in the programming language is important for severalreasons, including program analysis and optimization. Declarative pro-gramming is important in this area, as it gives simpler semantics. Thesemantics of most popular programming languages is complicated andfar from being ideal. Programmers program at a low level, starting fromscratch on every application. The consequence is long development time,and expensive applications. It is useful to move the programming processto a higher abstraction level and avoid having to care about lower leveldetails. Tools should be used to handle low-level implementation issues,and the programmer would be able to focus more on the correctness of theprogram.[32]

2.9.6 Programmer productivity

Arguments about getting higher efficiency are often used to justify the useof low level programming. Even though efficiency is important to somedegree, it is not necessary to have the most efficient algorithm. The cost ofprogramming time, application maintenance and -upgrading is high, and itis therefore more important to solve the problems in a reasonable efficientway, than the best way possible. By using declarative programming andletting the system take care of low-level details, the programming timecan be spent on solving the actual task, and the programming productivityincreases.[32]

The same improvements are not possible to achieve in imperativeprogramming. The logic and control is mixed together, and it is thereforeimpossible for the programmers to avoid dealing with low-level details.When logic and control is separated, like in declarative programming, it ispossible to move the responsible of creating the control component awayfrom the programmer. A declarative program is simpler to write and easierto understand than a corresponding imperative program. Research has alsoshown that it is easier to reason about and transform declarative code thanimperative code.[32]

33

34

Chapter 3

Research methods

The concept of a virtual DOM in UI development has not been discussedmuch until the last few years, and little work has been done on the topic.The amount of existing literature is therefore limited. However, the topichas become quite popular among JavaScript developers, and articles, blogposts and presentations are published continuously by developers withinthe field. To get further insight into the topic, research has been done toreveal properties of the different rendering techniques.

3.1 The methods used

Information has been collected by use of both quantitative and qualitativemethods.

Qualitative methods are used to discover and understand the experi-ences, perspectives and thoughts of the participants. It allows for detailedexploration through the use of case studies and interviews, among othermethods. It is a flexible and open research method, which implies that dif-ferent results could be obtained by different researchers. Replicability andgeneralizability is therefore generally not the goal of using this method.[24]

Quantitative methods are attempting to maximize the replicability andgeneralizability of the results. The results are expected to be objective andnot affected by the experiences and opinions of the researchers. Tests andsurveys are often used to collect data.[24]

The performance has been analyzed through the use of a quantitativemethod. Performance tests have been run to obtain numerical performancedata. A quantitative method was used to obtain information aboutexperiences done on real projects. The information was collected throughthe use of interviews between experienced developers and the researcher,and the goal was to retrieve information about how the techniques work inpractice.

A student survey has also been used to get information from the studentperspective. This survey is used to obtain numerical data, in addition toinformation about the perspectives and thoughts of the participants. Themethod used is not entirely qualitative, but neither falls under the categoryquantitative methods. According to [24] this research method falls under

35

the category mixed methods, which combines elements from both qualitativeand quantitative methods.

3.2 Performance testing

To take a closer look at how well virtual DOM performs compared to theother popular techniques, KVO and dirty checking, some performancetests were made. The goal of the tests is to get performance numbersthat show memory usage and render times for the different frameworks.The numbers will be used to reveal if there are some clear differencesbetween the frameworks, and if the results are consistent with analyzesin O-notation.

The goal with the tests is to obtain sufficient information to be able toanswer research question 1, regarding performance.

3.2.1 Validity

Measuring performance is not easy, as the performance numbers varydepending on platforms, frameworks and how the application is imple-mented. The performance tests carried out in this thesis are not complex,and the code is written as simple as possible, using the frameworks in theintended and recommended way. The same applications have been imple-mented in all the frameworks to assure equal terms for the tests. In addi-tion, all tests have been carried out in the same environment to have thesame conditions apply to all of them. Each test case has been executed sev-eral times, and the resulting numbers are the average of all the test cases.The average is in most cases based on more than 10 executions. The exactamount of executions performed is regulated based on the degree of vari-ations between the individual executions. If the variation is small, fewerexecutions are forming the basis of the average result, while multiple exe-cutions are used in cases with larger individual variations. This is done tominimize the influence of inaccuracies in each case.

It is not the exact performance numbers, but the trends in the resultsthat are important, and inaccuracies in the size of milliseconds willtherefore not be of any importance. Differences at millisecond level arenot significant and will not be emphasized in the thesis.

3.2.2 Implementations

The implementations of the following test cases are available at GitHub.More information, in addition to parts of the source code, is given inAppendix A.

3.2.3 Test cases

The test cases used to obtain information about the performance will bepresented below. The cases will be enumerated, and the enumeration willbe used to reference the specific cases throughout the rest of the thesis.

36

A: TodoMVC

TodoMVC1 is a project that implements the same Todo application usingdifferent MV* frameworks. The implementations are made by experts oneach framework and are therefore implemented in a correct and efficientway using each framework. Because of this, TodoMVC is a great resourceto perform comparisons on, to see if there are any noticeable differencesin performance between the frameworks. In Figure 3.1, the TodoMVCapplication is shown. It is empty in the first picture, three todo items havebeen added in the second picture, and the items have been checked in thelast picture. At the bottom of the Todo list, there are buttons to choosebetween displaying active, completed or all todos.

A.1: 1000 todos and 50 todos In this test, 1000 elements are addedto the list, then they are checked and at last deleted from the list. Thetotal time spent on these operations are measured to see if there are anysignificant differences in performance between the frameworks used toimplement the application.

To get the performance numbers, PhantomJS was used. PhantomJS is"a headless WebKit scriptable with a JavaScript API. It has fast and nativesupport for various web standards: DOM handling, CSS selector, JSON,Canvas, and SVG"2. For the implementation using React, the JSX code wasreplaced by JS code, and a bind-polyfill3 was added to make the PhantomJSscript work. This does not affect performance. The same test was executedwith 50 elements, to see if there are notable differences at smaller scale too.The PhantomJS script used is a modification of the script found in [42].

A.2: 1 todo item 1000 times Like in the previous test case, theTodoMVC application is used to measure the time used to add, check anddelete todo items. In this test case the list only contains one todo item ata time. A todo item is added, checked and deleted, and this process isrepeated 1000 times. The difference from the previous test case is that thelist now contains only one item at a time, in contrast to all 1000 elementsat once. The script used is similar to the one used in the previous test case,except for the order in which the tasks are performed. This version of thescript is available in Appendix A.1.

A.3: Filtering todos In this test the memory usage and render timeof the TodoMVC application are measured. Before starting the test, 200todo items containing a single letter string is added to the Todo list, andevery second of the items are marked as checked. The render times spentin switching between showing "All", "Active" and "Completed" todo itemsare recorded, and the average time is found. The memory consumption ismeasured while no user interaction is performed.

1The TodoMVC project is available at www.todomvc.com2More information at www.phantomjs.org.3Function.prototype.bind is undefined in PhantomJS and must be added

37

Figure 3.1: The TodoMVC application

B: Sortable datatable

1000 elements, each containing a unique identifier, a numeric value and arandomly generated name, are created and displayed in a data table. Theview also contains two buttons - one to update a random data elementand the other to update all elements. These updates are reflected in theview immediately. The data table is sortable and is sorted on the elements’values, which are numerical. The data table needs to be resorted when anelement’s value is changed. The render time is measured for the case whenone random item is changed, and when all items are changed. The memoryconsumption is measured while the application is in a steady state and nouser interaction is performed. The source code is available in AppendixA.2.

C: Sortable datatable with windowing

This test case is similar to the test case above, with one exception. Theunderlying data is the same, but instead of displaying all 1000 elements,only the top 10 elements are displayed. The data table is still sortable andis updated on data change. The amount of underlying data is the same, butthe size of the view is much smaller. The goal is to detect if this has anyimpact on how the frameworks perform. Both memory usage and rendertime is measured in the same way as in the previous test case.

D: Filterable datatable

The data table contains 1000 elements that are similar to the elements usedin the previous test cases. In this case, the application contains an inputfield, where the user can enter text. The text entered is used to filterthe elements shown. Only elements containing the text entered will bedisplayed. The memory usage is measured when no user interaction isperformed. The render time is measured as the average time spent on re-rendering the data table on user input. The same user input is given to allthree implementations.

38

E: Button click counter

10 000 elements, each containing a button, are part of the DOM. Thebutton text displays how many times the button has been clicked. When abutton is clicked, the counter is increased. The goal is to measure memoryconsumption and number of listeners required by the different techniques.Two implementations are built using Backbone, one with and one withoutevent delegation. This is done to see how large impact the amount of eventlisteners has on the application’s total memory usage, and to compare thetechniques KVO, dirty checking and virtual DOM.

F: Initial load

The code from test case E is used. The initial load time is measured for eachof the frameworks in the cases when 10 and 1000 of the 10 000 elements arepart of the DOM. The load time is the time spent until the DOM content isloaded. Each of the implementations contains the minified version of theframework used, in addition to the libraries Underscore and jQuery. Thisis done to reduce the impact of external factors.

3.2.4 Test execution

These tests were performed in a system with the following specifications:

Computer

Ubuntu 14.04 LTS

Memory: 3,8 GiB

Processor: Intel® Core™ i5-2430M CPU @ 2.40GHz x 4

Graphics: Intel® Sandybridge Mobile

OS type: 64-bit

Web Browser

Google Chrome

Version: 42.0.2311.90 (64-bit)

The results will vary based on the system specifications in the testenvironment, but the relation between the numbers should be the sameregardless of the system used to perform the tests.

3.2.5 Testing tools

To get the performance numbers, the Profiles panel in Google DeveloperTools4 in Chrome has been used. The Profiles is a tool to measure executiontime and memory usage of an application.

The render times have been captured by use of the CPU profiler partof the Profiles panel. The CPU profiler displays execution time of the

4More information can be found at developer.chrome.com/devtools/

39

JavaScript functions in the application. To capture the memory usage, theHeap profiler, which displays memory distribution by JavaScript objectsand related DOM nodes in the application, has been used.

The profiles containing the results used in this thesis are saved and canbe made available on request.

In the TodoMVC case, a phantomJS script was used to get executiontimes as explained earlier in this section.

3.3 Student survey

A survey was given to students at the Department of Informatics,University of Oslo. The survey contained 8 questions regarding theirknowledge and preferences when it comes to frameworks, and theirfamiliarity with central concepts that these frameworks are built upon.

As most students have less experience in working with these frame-works than developers with years of work experience, they generally havefewer preconceived opinions on what is the best technique, and they mighttherefore be more objective in their assessment of new frameworks. It isalso interesting to see what frameworks they find easy or hard to learn,and what they emphasize when choosing what framework to use.

This research method is used to obtain information that can be useful inanswering research question 2. The survey scheme is available in AppendixB

3.4 Interviews

As the concept of using a virtual DOM in front-end development is new,there is not much information available about experiences on using thistechnique on production code, compared to the other available techniques.How well the techniques work in practice is of great interest, anddevelopers working on projects using these techniques were interviewed toget a deeper insight in advantages and disadvantages with the techniques,and to see if any significant differences are revealed.

The list of predefined questions is available in Appendix C.

3.4.1 Goal

The goal of the interviews is to get information about experiences in usingthe different techniques. The developers are therefore asked about theirexperience with the use of virtual DOM on real projects, compared to otherstructuring frameworks they have been using earlier. It is interesting toidentify both benefits and drawbacks with the use of virtual DOM whenit comes to performance and the development process in general, andexamine whether it is a more suitable technique than dirty checking andKVO.

The interview results will be central in the discussion of the researchquestions 2 and 3.

40

3.4.2 The interviewees

The interviewees were all developers belonging to a consulting company.They have experience in working on large-scale JavaScript applicationsand have been using different structuring frameworks in the developmentprocess. Ten developers from different projects have been interviewed.Five of the projects have made the choice of taking use of the virtual DOMtechnique through the framework React. Some of the projects are new andwritten from scratch, while others are replacing other frameworks withReact or using React to add additional features to an existing application.The other half was using Angular and Backbone. Developers withknowledge about all three techniques were interviewed to get informationabout benefits and drawbacks with all the three underlying techniques, toform a better basis for comparisons.

3.4.3 The interview process

The topic and the list with predefined questions were the same for allinterviews. This was done to get information about the same topicsfrom all of them, and to obtain different experiences on the same area,so that comparisons could be made. During the interviews, differentadditional questions were asked to get deeper information. In addition, thequestions were adapted to the interviewee, based on his or her experience.Some interviewees had experience with many relevant frameworks andtechniques, while others had knowledge about one of them.

Preparations

The goal was to get as much information as possible from the interviews.To obtain this, there were made a few, bigger questions that coveredthe relevant topics, instead of making a lot of detailed questions. Bygiving open questions, it gives the interviewee the possibility to give moredetailed answers, and he or she can direct the answer into what he or shethinks is the most important lessons learned. The interview questions weregiven to the projects in advance, so that they had the possibility to prepareand think through the different topics. By having the interviewees beingprepared for the questions, the possibility of achieving richer answersincreases.

The interviews

To be able to process the interviews, they were recorded with the consentof the interviewees. As the interviewee answered the questions, there wereasked additional questions where it was relevant with clarification or moredetailed answers.

Supplementary work

The interviewees were all from Norway, and the interviews were heldin Norwegian. All of the interviews have therefore been transcribed

41

in Norwegian. Direct quotations used in the thesis have been freelytranslated into English and the transcriptions of these quotes can be foundin Appendix D. Each quotation will be enumerated to easier find thetranscription belonging to the quotation.

42

Chapter 4

Results

The results of the research work will be presented in this chapter. Theresults will be presented in the same order as used in Chapter 3, ResearchMethods. Section 4.1 presents the results relevant to answer researchquestion 1, while 4.2 and 4.3 will present the research material related toresearch question 2 and 3.

This chapter presents the results from each test case without anydiscussion of the results. Analysis and comparisons will be part of thediscussion in chapter 5.

4.1 Performance testing

The results from the performance tests are presented in this section. Barcharts are used to better give an impression of the differences between theresults.

4.1.1 A: TodoMVC

A.1: 1000 todos and 50 todos The results from adding, checking andremoving 1000 and 50 todo items are shown in Figure 4.1. The results arepresented in the same bar chart to visualize the increase in time.

A.2: 1 todo item 1000 times The resulting render times are presentedin Figure 4.1 together with the results from A.1.

A.3: Filtering todos The render times are presented in Figure 4.2. Theresults of React both with and without optimizations are given. Memoryusage is presented in Figure 4.3.

4.1.2 B: Sortable datatable

The results of the sortable data table containing 1000 elements are given inFigure 4.4. The results include the render times of changing both one andall elements. The memory usage is presented in Figure 4.3.

43

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2·105

1000

item

s

50ite

ms

1by

1

1.9 · 105

693

8,918

29,139

488

10,701

86,827

668

15,156

Time in ms

ReactBackboneAngular

Figure 4.1: Test case A.1 and A.2: render times

0 20 40 60 80 100 120 140 160 180 200

Filte

ring

todo

sFilte

ring

data

tabl

e

185.3

32.14

107.2

42.78

104.3

36.48

61.4

36.58

Time in ms

React + optReactBackAng

Figure 4.2: Test case A.3 and D: render times

A B C D0

10

20 17.9

12.4

8.6

12.5

11.9

9.1

9 9.1

14.3

11.9

8.2

12.2

Memory usage

MB

Angular Backbone React

Figure 4.3: Test case A-D: memory usage

44

0 20 40 60 80 100 120 140 160 180 200 220 240

Cha

nge

one

Cha

nge

all

17.2

185.6

142.9

185.3

73.69

225.62

Time in ms

ReactBackboneAngular

Figure 4.4: Test case B: render times presented in charts

0 5 10 15 20 25 30 35 40 45

Cha

nge

one

Cha

nge

all

12.7

12.3

4.6

40.5

4.5

8.7

Time in ms

ReactBackboneAngular

Figure 4.5: Test case C: results presented in charts

4.1.3 C: Sortable datatable with windowing

Figure 4.5 presents the render time results of the test case where top 10of 1000 are displayed. The render times were measured when one randomelement was changed and when all elements were changed. Memory usageis given in Figure 4.3.

4.1.4 D: Filterable datatable

The render times are presented in Figure 4.2 together with the render timesfrom test case A.3. This is done to visualize the differences and similaritiesbetween the two filtering test cases. The memory usage is presented inFigure 4.3.

4.1.5 E: Button click counter

The results from the tests with both 10 000 elements and 10 of 10 000elements part of the DOM will be given. Backbone is used both with andwithout event delegation, and both results are included. The amount ofevent listeners required by the different frameworks is presented in Table

45

Table 4.1: Test case E: Number of listeners when 10 out of 10 000 and all 10000 elements are in the view

FrameworkNumber of listeners

10 000 in view 10/10 000 in viewAngular 10 008 18Backbone 10 006 16Backbone w/event deleg. 7 7React 8 8

All 10 000 10 of 10 0000

20

40

60

39.6

10.1

34.9

16.122

.6

16.1

42.3

9.7

MB

Angular Backbone Backbone w/deleg React

Figure 4.6: Test case E: Memory usage when all 10 000 and 10 of 10 000 arepart of the view

4.1. The memory usage results are presented in Figure 4.6, and the rendertime results are contained in Figure 4.7.

4.1.6 F: Initial load

The initial load times are given in Figure 4.8. The chart displays the initialload time when all 1000 buttons are part of the DOM, and when 10 of themare part of the DOM. The results of Backbone both with and without eventdelegation are presented.

46

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6

All

1000

0

10of

1000

0

5.1

1

3.1

1.5

3.3

1.9

1.8

1.7

Time in ms

ReactBackbone w/event delegation

BackboneAngular

Figure 4.7: Test case E: render time results

0 100 200 300 400 500 600 700 800 900 1,000

10of

1000

0

1000

of10

000

577

909

633

933

367

768

356

513

Time in ms

ReactBackbone w/deleg.

BackboneAngular

Figure 4.8: Test case F: initial load time

47

4.2 Student survey

The survey was answered by 25 students at the Department of Informatics,University of Oslo. Figure 4.9 displays the percentage of students that wasfamiliar with each of the frameworks.

Degree of knowledge and getting started

Figure 4.10 shows the result of how well the respondents rate theirknowledge about each of the frameworks. The respondents were alsoasked to rate how difficult it was to learn and get started with theframework, and these results are given in Figure 4.11.

Familiarity with underlying concepts

The respondents were asked about how familiar they were with theconcepts dirty checking, virtual DOM and KVO. The results are presentedin Figure 4.12.

It was found that several of the students rated their knowledge aboutthe frameworks to be good without being familiar with the underlyingconcepts used.

Preferred frameworks

The survey asked for the student’s preferred framework. Some studentsspecified two frameworks as the preferred ones. In these cases, bothspecified frameworks have been taken into account. Figure 4.13 presentsthe results.

The students were asked why they liked or disliked a framework. Ingeneral, students prefer the framework they first learned and are mostfamiliar with. They prefer the framework they have most experience withand therefore most knowledge about. Earlier experiences from successfulprojects were also of importance. Many of the respondents are satisfiedwith the framework they already have knowledge about and don’t see any

Angular Backbone React

87.5%70.8% 75.0%

Figure 4.9: Survey: framework familiarity in percentage

48

Angular Backbone React

Low High

12.5%4.2%

29.2%

4.2%

50% 42.9%

14.3%14.3%

28.6% 31.8%

22.7%

31.8%

9.1%9.1%

Figure 4.10: Survey: degree of knowledge

Angular Backbone React

Low High

9.1%4.5%

13.6%

40.9%

31.8%14.3%

14.3%

28.6%21.4%

21.4%

7.1%

14.3%

42.9%7.1%

28.6%

Figure 4.11: Survey: difficulty in getting started

Dirty checking KVO virtual DOM

Unfamiliar

Heard of

Some knowledge

Know a lot

36%

24%

16%

24%40%

28%

12%

20% 16%

16%

20%

48%

Figure 4.12: Survey: familiarity with underlying concepts

49

Preferred framework

Angular

Backbone

React

Other

None

56%16%

16%

4%20%

Figure 4.13: Survey: preferred framework among the students

reason to replace it. The frameworks’ popularity was also mentioned, anda big community is seen as an advantage.

The advantages and disadvantages specific to Angular, Backbone andReact are presented in Table 4.2.

50

Table 4.2: Survey results specific to the frameworks

Angular

+ Well suited for complexSPAs

+ Easy to learn

+ Enforces nice structur-ing of web applications

– Difficult to get hold on what hap-pens behind the scenes

– Difficult to develop applicationsthat doesn’t fit well into the bound-aries of the framework

Backbone

+ Easy to configure

+ Lightweight

+ Flexible

– Too lightweight

React

+ Good performance

+ New

– Unfamiliar code style

4.3 Interview results

The interviews have been transcribed, and direct quotations will be used inthe discussion. In general, it was found that the developers are interested innew technologies and take them into use when they have the opportunity.Sometimes customers decide what frameworks to use, and factors like timeand cost are often limiting the freedom to replace and test new solutions.

Developers don’t want to think of how frameworks handle low-leveldetails and expect it to work properly without any involvement necessary.An overview of some of the findings in Angular, Backbone and React arepresented in Table 4.3, 4.4 and 4.5, respectively. More detailed informationwill be used in the discussion.

51

Table 4.3: Interview results specific to Angular

Angular

+ Easy to get startedquickly

– Performance problems

– Little flexibility

– Difficult to understand what is hap-pening

– Time consuming to understandhow to use it in a good way

– Individual code styles

Table 4.4: Interview results specific to Backbone

Backbone

+ Flexible

+ Easy to combine withother libraries andframeworks

+ Explicit data binding

+ Easy to understand

– Some problems with memory us-age

– High amount of manual operations

– Need to think about DOM-operations and performance

– A lot of boilerplate code

– Problems with endless loops

Table 4.5: Interview results specific to React

React

+ No performance problems

+ Simple to learn

+ Good performance withoutthinking of it

+ Comfortable mental model

+ Clean code

– Problems with componentsgetting too large

– One extra layer on all ren-dering

52

Chapter 5

Discussion

When looking at the virtual DOM approach compared to dirty checkingand KVO, there are several factors that need to be examined. It isinteresting to get a better insight into what the virtual DOM approachbrings to the table. The discussion will address one research question (RQ)at a time.

RQ1 - performance will be discussed in Section 5.2. This discussionwill mainly be built on the performance tests executed, togetherwith experiences done by developers interviewed. The performanceis of high importance in today’s complex applications, and theperformance of the techniques will therefore be subject for discussion.The performance is analyzed by looking at memory usage and rendertimes among other factors.

RQ2 - problem areas will be discussed in Section 5.3, 5.4 and 5.5. Thedrawbacks and problems found in dirty checking and KVO willbe discussed to get an overview of the problem areas. How theseproblems are handled using virtual DOM, and whether virtual DOMimproves the development phase or not will be investigated further.Important areas for research are how well the techniques perform, towhat degree they simplify the development process and how wellthey function at scale. The discussion is based on material fromthe interviews and the survey, together with information shared byexternal companies.

RQ3 - impacts is subject for discussion in Section 5.6, 5.7 and 5.8. Theinterview results and relevant information from external sourcesmake up the foundation for the discussion. How familiarity affectsthe choice of technique is discussed, in addition to the consequencesthat come as a result of increased usage of virtual DOM.

5.1 Rating

A rating system will be used in discussion of RQ1 and RQ2 to easierkeep an overview of topics discussed and how the different techniques are

53

Table 5.1: Rating of central properties of the techniques

Dirty checking KVO Virtual DOMPerformance 1 3 2Simplicity 1 2 3Abstraction level 2 1 3Scalability 1 2 3Total 5 8 11

evaluated in each of them. Table 5.1 shows the main topics to be discussed.Each of the topics will contain smaller areas for discussion, and the ratingspresented here are result of the ratings contained in each of the sections.

5.1.1 The rating system

Each of the techniques is rated in each category. The rating is done byawarding points from 1 to 3, where 3 is the best. If two of the techniquesare evaluated to be equally good, or if no significant difference is foundbetween them, they are awarded the same amount of points. Whether thethird one is given 1 or 2 points less or more than the others, is based onhow significant the difference is.

The results presented in Table 5.1 will be justified throughout thechapter. The rating system will not be used in the discussion regardingRQ3, as this mainly concerns the virtual DOM and not so much the othertechniques.

5.2 The performance

It is important that applications perform well enough to avoid loweringthe user experience. Several factors can affect the performance and thesewill be explored and evaluated in this section to answer RQ1. Is there onetechnique that generally yields the best results, or does it vary dependingon the type of application? The test cases performed will be used toevaluate how the different rendering techniques perform, and if any ofthem stands out from the others in either direction.

The people behind the virtual DOM framework, React, states that it isnot performance that is the most important feature of the technique, but thesimplicity it brings.[26] Even though performance is not the main goal ofusing virtual DOM, it is still important that the performance is good enough.The other popular techniques perform well in most cases, and it is notimportant for the virtual DOM to beat these when it comes to performance,but it should be on the same level, or at least not notably slower.

Table 5.2 presents the different properties to be evaluated in this section.This rating puts the virtual DOM’s performance to be in the middle ofthe three. Important factors that affect the techniques’ performance are

54

Table 5.2: Rating of performance properties

Dirty checking KVO Virtual DOMExperienced issues 1 2 3Initial load time 2 1 3Render time 1 3 2Memory usage 1 3 1Data volume 1 3 2Interaction 1 2 3Size 2 3 1Total 9 17 15

presented and the properties in the table will be discussed.

5.2.1 Important factors

The use of virtual DOM seems to be slightly slower in cases wherealternative methods already are very fast, but it performs better in caseswhere problems often are found. There are several factors that explainthese results. The amount of DOM elements and the amount of underlyingdata both play important roles here, but the shape of the DOM and the dataalso matters.

Performance in O()-notation

The theoretical performance is presented in Table 5.3 using O-notation.If a data element part of the UI is changed, it should be re-rendered inthe DOM. The amount of work that needs to be done by the differenttechniques can be given in O-notation. The amount of data in the viewis denoted by v, while the amount of watched data in the application isdenoted by m.

The KVO approach knows exactly where the change happened andwhat elements that should be updated on this change, and can thereforeperform the DOM update in constant time, O(1).

The dirty checking approach does not have information about wherethe change happened, and needs to perform the dirty check on all watcheddata in the application, before being able to do the update. As the amountof data is m, the update time will be O(m).

The virtual DOM needs to generate a new virtual DOM representationand perform the diff algorithm. As the diffing is done in linear time, andthe virtual DOM representation contains the data that is part of the view,the update is done in O(v) time.

The memory usage can also be given in O-notation. With KVO, thedependencies between observed elements need to be kept in memory,which results in a memory consumption of O(m). The same is the casefor dirty checking, as copies of all watched expressions need to be kept

55

Table 5.3: Performance in O-notation

Dirty checking KVO Virtual DOMUpdate O(m) O(1) O(v)Memory O(m) O(m) O(v)

in memory. The virtual DOM keeps the previous view representation inmemory, resulting in a memory usage of O(v).

By looking at these theoretical numbers, it looks like KVO will be thewinner and virtual DOM the second best at render times, while virtualDOM is the best at memory usage. The performance tests will be discussedlater on to see how the real performance is.

View and data size

The performance numbers presented above shows that the size of the viewand the underlying data is important. As mentioned in Section 2.3, a highamount of underlying data is not unusual in today’s applications. Thesize of the view is usually smaller than the amount of data, as it is limitedby human capacities. Human beings are not capable of absorbing infiniteamounts of data at the same time, and there is therefore no need for theview to contain large amounts of data simultaneously.

The size of the underlying data has potential to be much larger than thesize of the view. It is not limited by human capabilities in the same way,and the view can be used to show only parts of the underlying data at atime.

View and data structure

As the virtual DOM takes use of short-circuit optimizations meant for treestructures, it will generally perform well where the DOM is deep with alow branching factor, which is the case for most applications today. Figure5.1 illustrates the difference between a shallow and a deep DOM structure.The applications often consist of components containing subcomponentsand lists of components, as described in Section 2.3. The use of virtualDOM is therefore appropriate and useful for many applications developedtoday.

The reason why the virtual DOM performs well for applicationswith this DOM structure is the selective rendering described in 2.8.4.Even though a component is marked as dirty, it doesn’t mean that allsubcomponents need to be re-rendered, and this optimization leads tobetter performance. However, if the DOM is flat and contains a lot ofelements, the virtual DOM approach is generally a bit slower as it cannotexploit its optimizations here, and a bigger amount of comparisons mustbe carried out.

Dirty checking is done on the data in the application, but the

56

Figure 5.1: Illustration of shallow (left) and deep (right) tree structures.

performance varies depending on how deep the comparisons need to bedone. If the element’s reference has been changed, there is no need fora deeper comparison, as it is known that the element has changed. Ifthe element is deep, which means containing sub-elements which againcontains sub-elements, and so on, this shallow comparison can lead tobetter performance, as less time is spent in doing comparisons. If the datastructure is flat and contains shallow elements, the optimizations cannot beexploited.

The biggest difference here is the amount of data that needs to becompared. The virtual DOM representation only contains the data that isgoing to be rendered to the DOM, while the dirty checking is performedon all data in the scope of the application. This difference turns out tobe of great importance when it comes to render times, and the test casesperformed confirms this.

No data comparison is needed in KVO. Events are used to notify listen-ers that changes have happened, and it is therefore known what changeshave happened at which objects, without having to make comparisons.KVO is therefore not affected by the structure in the same way as the othertechniques.

5.2.2 Experienced issues

The developers interviewed were asked about their experience withperformance issues, and clear tendencies were found. Among thedevelopers with experience from Angular projects, nearly all of them hadexperienced performance issues during the development phase. The mostcommon issue is problems with large amounts of data, which leads to slowupdates and lowers the user experience. The developers usually detect theperformance issue and locate the source, and in most cases they work theirway around it.

57

You may experience performance problems if you arenot conscious of the dirty checking that is going on.

—INTERVIEW D.1.1

The dirty checking requires the developer to be aware of its problemareas to be able to avoid performance issues. The developers mentionedworkarounds as decreasing the amount of data to render or inserting theelements into the DOM differently.

Performance issues were also mentioned by the developers withexperience in using KVO, but not to the same extent. These problemswere related to memory consumption. Applications with a large numberof views and a lot of interaction resulted in a large amount of listeners andgarbage collecting. The solution was a decrease in the number of views,and replacing smaller sub-views with one larger view.

No performance issues were experienced on the projects using virtualDOM. Several of the developers interviewed mentioned the performanceto be a great advantage of the virtual DOM.

The virtual DOM gives better performance out of the box

—INTERVIEW D.1.2

The performance problems experienced by use of KVO, and especiallydirty checking, have not been detected in use of virtual DOM. No newperformance issues have been detected either. The performance issues indirty checking are more common and serious than the issues experiencedwith KVO.

5.2.3 Initial load

The initial page load speed is of high importance. If the initial load is slow,it will result in fewer visitors. As the mobile traffic increases, the initialload speed becomes more important. Visitors tend to abandon the page ifit takes several seconds to load. A few seconds delay in a speedy networkwill be substantially slower at lower-end networks, which are still used togreat extent. Google even uses the site speed in its web search ranking.[45]

The TodoMVC application has been used to make a comparison of theinitial load using different frameworks. The time it took for the applicationUI to appear was measured.

The tests were executed using WebPageTest.org.[7] The results forReact, Angular and Backbone are available at [53] and show that React isgiving the best result among them. The visual progress is presented inFigure 5.2 and show that the virtual DOM approach is better than bothKVO and dirty checking.

In a test where dirty checking was replaced by the use of virtual DOM,it was also found that the virtual DOM improved the initial render timesignificantly.[28] Test case F showed that the initial load time of React andthe virtual DOM was the shortest both when the DOM contained few andmany elements. Backbone and its KVO approach was giving the worst

58

Figure 5.2: Visual progress on initial load. Figure from [53]

initial load time, both with and without event delegation. The virtual DOMapproach is found to give a significant improvement compared to dirtychecking, while KVO is the slowest among the three.

5.2.4 Render time

Tests with various sizes of the view and various amounts of underlyingdata were executed to find potential differences between the techniques.The results confirm that the size of the DOM and the underlying data affectthe performance significantly.

Data equal to data in UI

In test case B where all underlying data is reflected in the UI, the virtualDOM approach was beaten by dirty checking. KVO, on the other hand,gave the worst results. When all data is reflected in the view, the sameamount of data needs to be compared by the virtual DOM and the dirtychecking, so why is dirty checking faster? One reason why virtual DOMis slower than dirty checking could be found by looking at the way data ishandled.

Dirty checking compares data directly, while virtual DOM requires anew virtual DOM representation to be created before the comparisons aredone. The creation of a new virtual DOM representation is time consumingwhen the amount of data to display is large, and few optimizations arepossible because of the flat DOM structure. This is the worst case scenariofor the virtual DOM technique, as all time spent in generating the virtual

59

DOM representation essentially is time wasted.

No data comparisons are done using KVO. When a random elementgets changed, a change event is fired, and the list is resorted. Next,the elements are inserted into the UI one by one, causing multiple DOMinteractions. DOM interactions are time consuming, and accessing theDOM 1000 times is a large part of the reason why KVO gives bad rendertime results in this test. In addition, the amount of event listeners is high,as it is necessary to listen for change events for each of the list items.

Virtual DOM’s worst case scenario is not terribly bad compared tothe other techniques, and it is even better than KVO. It would have beenpossible to optimize the KVO implementation, but this test case takes useof the common way to implement it.

The differences in performance are smaller if all elements are changed.In this case, all items must be reinserted into the DOM. Dirty checking andKVO are on the same level, while virtual DOM is a bit slower. Also here,the time spent creating the virtual DOM representation is wasted, as alldata elements are compared, without the possibility to exploit any of itsoptimizations, and all of the elements need to be re-rendered.

Amount of data larger than data in UI

If the UI only displays a small part of the underlying data in the application,the performance results are different. In this case, virtual DOM gives thebest performance results. As the amount of data in the DOM is smallerthan the underlying data, the virtual DOM technique will have to makefewer comparisons than dirty checking, which still needs to compare alldata elements in the scope. Virtual DOM compares only the elements to berendered in the UI, and therefore saves a lot of work. Test case C confirmsthis.

Dirty checking has to compare all the data, and the performance is onlya little better than the results from B. The same amount of comparisonsthat were done in B has to be done, and this can be seen as a drawbackwith the dirty checking. The decrease in render time is a consequence offewer elements in the DOM as fewer elements lead to faster DOM treeconstruction.

The virtual DOM shows a significant improvement in render times andgives the best results both when one single element is changed and whenall elements get changed. Its diffing algorithm only has to compare theelements part of the view, and this is a great advantage compared to dirtychecking.

Both the results from virtual DOM and dirty checking were withina frame, and it doesn’t really matter that dirty checking is a bit slower,because everything within a frame is good enough. Differences within aframe are not visible for the users, and most screens do not update anyfaster than 60 fps.

60

Filtering data

The feature of filtering elements is used in many applications today, andit is important that the filtering results are delivered quickly to the user.In test case D, the results show that there are some differences betweenthe techniques, but they are not too big. Dirty checking beats KVO by10 ms, while virtual DOM is in between. Also here, all data is displayedin the UI, making room for no optimizations using virtual DOM. All threeapproaches detect the user input, filter the list based on this input and makeupdates to the DOM to reflect the changes.

In test case A.3, where half of the elements are being filtered away,virtual DOM is significantly better than the others.

A lot of events are fired using KVO, and there is need for manyevent listeners. A DOM interaction request is generated for each of thetodo items. As explained in Section 2.4 about the rendering path, DOMinteractions are slow and should be minimized. The large amount of DOMinteractions results in bad performance if the todo list contains many items.

Dirty checking is giving the worst results among the three techniques.When the filtering button is clicked, a dirty check is performed on all datain the application, including all todo items. A change in the filter status isdetected, and the DOM is re-rendered to reflect the updates that should bemade according to this change.

The reason why the virtual DOM performs so much better, might be acombination of how the comparisons are carried out and the way DOMoperations are handled. Each element in the virtual DOM is assigneda unique key, and this is used to minimize the amount of comparisonsand amount of DOM operations needed. With dirty checking the wholelist of todos must be compared, and a larger part of the DOM is affectedand needs to be reconstructed. As DOM operations are time consuming,this might contribute to the performance gap between dirty checking andvirtual DOM. Another important factor is the structure of the elements tobe compared, and this will be discussed next.

Contradictory results

The two filtering test cases discussed here are giving different results. Intest case A.3 , virtual DOM is giving the best result and dirty checking theworst, while the results are the other way around in test case D. Why dothey give different results? The answer to this question can be found bytaking a look at the DOM structure of the two cases.

As mentioned, the DOM structure affects the performance gained bythe virtual DOM approach. The first test case is a list where each element isa single div tag containing three data values. The structure of an elementis shown in Figure 5.3. Extra time is spent creating the virtual DOMrepresentation, without being able to take us of its optimizations, and dirtychecking therefore turns out to be better.

If the data elements were deeper, and the virtual DOM could exploitits optimizations to a higher degree, the results would have been in the

61

Figure 5.3: Structure of datatable element

Figure 5.4: Structure of TodoMVC item

virtual DOM’s favor. Test case A.3 contains elements where it is possiblefor the diff algorithm to do some shortcuts, and the virtual DOM approachtherefore performs better here. The structure of a todo item is shown inFigure 5.4.

React’s virtual DOM takes use of the function shouldComponentUpdate()

to reduce unnecessary comparisons. As can be seen from the element struc-ture, the elements in the TodoMVC case are more complex than the ele-ments in the other filtering test case. The use of shouldComponentUpdate()doesn’t give any performance improvement to test case D, as the elementsare too simple. The function would have to do about the same amount ofwork as generating a new virtual DOM representation of the element andwould therefore not bring any noticeable improvement in performance.

In the TodoMVC case it is possible to make huge improvements. Bycomparing the values contained in the todo item, unchanged items arenot reconstructed, and render time is reduced. When React is usedwithout this optimization function in test case A.3, the performance isdecreased. This confirms that the optimizations that are made possible withthe virtual DOM technique can give an order of magnitude performanceimprovement.

Rating

The KVO approach is generally giving the best render times results, andvirtual DOM is better than dirty checking when looking at all the test cases.The KVO approach is therefore awarded 3 points while 2 and 1 is given

62

virtual DOM and dirty checking, respectively.

5.2.5 The significance of data volume

The results from test case A show that the amount of data in the applicationis highly affecting how each of the tested techniques perform. In a realapplication scenario, 1000 elements will rarely be inserted one by one, andthe insertion of the same element 1000 times will not occur either. It is notthe results themselves that are important in this case, but how the amountof data in the application affect the performance of the technique used. It isthe underlying techniques that are investigated, and the results from thesetests reveal important properties of the techniques.

In test case A.1 dirty checking is significantly slower than the other two.When the application only contains one item at a time in test case A.2, dirtychecking is giving the best performance results and virtual DOM the worst,but the differences are smaller. This indicates that dirty checking performsbetter when the data volume is small, and might lead to performanceproblems in applications with large data volume. The results also showthat dirty checking is a time consuming process.

Virtual DOM gives the worst performance in A.2, when one elementis reinserted 1000 times. The one and only todo item changes on everyinteraction and needs to be re-rendered, and no optimizations are possible.As discussed earlier, virtual DOM does unnecessary work in this case.When the application contains 1000 data items at once, it is possible for thevirtual DOM approach to exploit its optimizations, and it performs betterthan dirty checking in test case A.1.

KVO is giving the best results if looking at the average of A.1 and A.2.It is not affected by the amount of data in the same way, as it knows wherethe change takes place and can update the DOM in constant time, withouthaving to make comparisons of the data. The drawback with this approachis the amount of event listeners that is needed. Every event listener needs tobe kept in memory, and this might be problematic, especially with mobiledevices in mind.

Test case A.1 executed with 50 todo items gives the same order ofthe results as the test case with 1000 elements. KVO is still giving thebest performance, almost unaffected by the amount of data, while dirtychecking and virtual DOM are closer to each other and almost similar inthis case. This emphasizes that higher data volume makes dirty checkingstruggle, while virtual DOM is making an improvement relative to theothers when its optimizations can be used efficiently.

KVO is better than dirty checking at small changes, but is significantlyslower at bigger changes. At the same time it is easier to makeimprovements to the performance using KVO, because everything is donemanually by the developer. As a result of this, KVO is given 3 points,virtual DOM 2 points and dirty checking 1 point.

63

Table 5.4: List rendering with dirty checking vs virtual DOM. Results from[28]

Listeners/watchers Render time Initial render timeDirty checking 14 009 160 ms 1750 msVirtual DOM 9 2 ms 230 ms

5.2.6 Interaction

Long lists constitute a performance issue when using dirty checking andthe render times are getting slower. If the long lists contain elements thatare changing over time, it requires a large amount of watchers to watch thetwo-way bindings. If the amount of watchers is getting large, the result isa less responsive page that lowers the user experience. This is somewhatsimilar to the issue with a large amount of event listeners required in KVOwhen a large amount of elements needs to be observed.

A test performed in [28] explores the use of virtual DOM to improvethe performance of Angular’s dirty checking in list rendering. The test1

contains a list with 2000 elements, and each element contains sub-elementsthat can be toggled visible or hidden through user interaction.

The test results from using virtual DOM to render the list showedsignificant improvements. The results are presented in Table 5.4.

There were drastic reductions in the number of watchers, render timeand initial rendering. The big decrease comes as a result of the virtual eventsystem that is used together with React’s virtual DOM approach. Insteadof having to attach watchers to every watched element, event delegationis used to minimize the amount of watchers needed. This shows thatdirty checking gets problematic in applications with a lot of interaction,and hence a lot of watchers, and that the virtual DOM approach gives asignificant improvement.

Test case E and F confirm this. Virtual DOM is better than both KVOand dirty checking when it comes to render times and initial load in caseswith a lot of interaction. Dirty checking is giving the worst render times.

5.2.7 Memory usage

The importance of memory usage is increasing with the use of mobiledevices. The three rendering techniques are different in what they need tostore in memory and therefore also occupy different amounts of memory.

The test cases showed in most cases no significant difference in memoryusage between the techniques. The difference in memory consumption isonly a few MB. As the test cases performed contain 1000 items, which ismore than usually will be displayed in the UI at once, these differences arenot remarkably high. Even though the amount of data displayed in the

1A fully functional demo can be found at https://github.com/pootzko/reactify

64

UI usually is much smaller, it often occurs that the amount of data in theapplication is higher.

Storing previous versions

The virtual DOM approach needs to keep a copy of the previous virtualDOM representation in memory to be able to do the diffing. A largeamount of underlying data is therefore not a problem, as the memory usagedepends on the size of the DOM representation. With dirty checking, onthe other hand, the memory consumption is highly affected by the totalamount of data in the application. As dirty checking is performed on thewatched data in the application, it is necessary to keep a copy of the data inmemory to be able to detect changes. How much memory this consumesdepends on how deep the dirty checking is done, as described in 2.7.3. Ifit is performed on the deepest level, it is necessary to keep a full copy ofall data. With a large amount of data in the application, this can causeproblems - especially on mobile devices with limited capacity.

Event listeners

The use of events can also be memory consuming. Each event listenerconsumes memory, and when the application contains a lot of elementswith event listeners attached, this occupies large amounts of memory. Bythe use of event delegation, it is possible to reduce the memory requiredby the event listeners, but it is still necessary to keep track of observedelements and which computed properties depend on other computedproperties.

Virtual DOM contains its own virtual event system. By having onesingle listener at the top of the hierarchy instead of multiple listeners, thememory consumed by event listeners becomes insignificant. Because thevirtual DOM re-renders on every change, it is not necessary to keep trackof dependencies between observed elements.

Test case E contains 10 000 elements counting the number of clicks.The virtual DOM only requires 8 listeners, while KVO and dirty checkingrequire more than 10 000. Even though the amount of listeners is muchsmaller in the virtual DOM approach, the memory consumption by thevirtual DOM is higher than the memory usage of KVO, and only slightlysmaller than the memory used by dirty checking.

The effect of event delegation

When only 10 of the 10 000 elements are displayed in memory, the amountof listeners required is drastically reduced by dirty checking and KVO, asis the memory usage. What is worth noticing here is the fact that the largeamount of event listeners doesn’t outweigh the memory required by thevirtual DOM representation. When only 10 of the 10 000 elements are inthe UI, KVO is slightly more memory consuming than the virtual DOM.

65

Table 5.5: Memory usage in test case E

Memory usageDirty checking 42,3 MBVirtual DOM 39,6 MBKVO 34,9 MBKVO w/event delegation 22,6 MB

To get a better impression of the impact the event listeners are havingon the memory usage, an application using KVO together with eventdelegation was implemented. The memory usage is presented in Table 5.5.

The best choice

To conclude, dirty checking is memory consuming if a large amount ofdata needs to be watched, while KVO needs to keep dependencies betweenobserved elements in memory, and is therefore memory consuming inapplications with a lot of observed properties. The virtual DOM approachis memory consuming if the DOM contains a lot of elements, because itneeds to keep a copy of the virtual DOM representation in memory.

The results from Table 5.5 are showing that big memory improvementscan be made by use of event delegation. It is also found that thevirtual DOM and dirty checking needs a lot of memory to store theirrepresentations, and this can be more memory consuming than having alot of event listeners in memory. If memory is a limitation, the results showthat KVO with event delegation is the best choice. Virtual DOM and dirtychecking are not significantly different and are therefore both awarded 1point, while KVO is given 3 points.

5.2.8 Size

The approaches are different in complexity, and as a result the frameworksare different in size. Table 5.6 presents the size of the frameworks Angular,Backbone and React. The production version is used to measure thesize, and the source files are found at the frameworks’ official web pages.Backbone takes use of KVO, which is the least complex approach, and thisis reflected in its size.

The size of the framework is not critical in large applications, asit constitutes a small portion of the total application size. In smallerapplications, however, it might be more important. When buildinglightweight applications where the total size matters, it is important tominimize the storage used.

5.2.9 The highlights

The developers interviewed had experienced performance issues usingboth dirty checking and KVO, and the most serious problems were

66

Table 5.6: Framework size, production version

Angular Backbone React50kb 6.5kb 121.5kb

experienced using dirty checking. No problems had been detected usingvirtual DOM at the time of the interviews, which might indicate thatproblems are easier to avoid using this technique.

The dirty checking approach is giving issues when the amount of datain the application is large, and the virtual DOM approach gives significantimprovements here. The virtual DOM is found to perform well enougheven in its worst cases, but KVO is generally a bit better than the virtualDOM approach when it comes to performance.

KVO is giving a higher degree of control to the developer and has thepotential to give better performance results than the other two. It is worthnoticing that it requires a lot from the developer compared to using virtualDOM.

To conclude, the virtual DOM performs better than dirty checking andavoids the problems related to large amounts of data. Even though thevirtual DOM approach is beaten by KVO, the amount of work required bythe developer is much smaller, and the performance is good enough in themajority of today’s applications. The differences are in most cases too smallto base a decision on whether the approach is suitable for the applicationor not, and other factors, like simplicity and efficient development, shouldbe taken into account.

5.2.10 Limitations

Most of the performance tests are implemented by the author of this thesis,and it is possible that experts on the frameworks would have implementedbetter solutions than the ones used in this thesis. It is important to keep inmind that the results could have been different if implemented by an experton each of the frameworks, and the results from the performance analysiscould have been different. However, a lot of research has been done tooptimize the implementations used in the thesis to make them as efficientas possible. Some of the test results are based on implementations madeby experienced developers, and it is therefore reasonable to assume thatthese are efficiently implemented. The results from the test cases created inthis thesis agree with the results from the tests performed on the TodoMVCapplication. Due to this, it is reasonable to believe that the tests are givinga genuine impression of the techniques.

Another source of uncertainty is inaccuracies in the test results, as aresult of environmental factors that might have impact on the executiontime of the tests. The results used in the discussion are differentiating tosuch degree that inaccuracies at millisecond level is negligible. Resultswhere the differences are small have not been emphasized in the discussion

67

due to the uncertainty of whether the differences come from measurementerror, environmental factors or if they actual are differences. Even if thedifferences originate from real performance differences, they are too smallto have any real world impacts and can therefore be ignored.

5.3 Simplicity

One of the most important features of a structuring framework is contribut-ing in making application development as simple as possible. If the frame-work leads to complex code, it will be harder to maintain and more diffi-cult to add new features to the applications. Complex code makes it is hardfor the developers to maintain overview of how the code works and howdifferent parts are connected. The simplicity explored in this section willcontribute in answering RQ2.

Table 5.7 gives an overview of the properties to be discussed, and therating shows how each technique is evaluated. The virtual DOM approachis given the highest score, and the discussion leading to these results ispresented in the rest of this section.

5.3.1 Startup and Understandability

The difficulty in getting started with a framework might affect whichframework is chosen. Through the student survey and the interviewsperformed, noteworthy information was obtained.

Angular - easy and hard

According to the student survey, students and beginners seem to preferAngular. They describe it as simple and easy to get started with. Moreexperienced developers seem to answer this question differently. They tendto think of Angular as one of the more challenging frameworks to learn, asit is complex and introduces a lot of new concepts. One of the developersinterviewed said the following about how long it took him to understandAngular.

Table 5.7: Rating the simplicity

Dirty checking KVO Virtual DOMGetting started 3 1 2Understanding the framework 1 2 3Onboarding 2 2 3Customization 1 3 2Uniform usage 1 2 3Mental model 2 1 3Total 10 11 16

68

It felt like I knew Angular after a week, but now, in retrospect, it feels likeI’ve taken several steps back. I don’t completely understand Angularanymore. It gives you a lot of confidence in the beginning, because youget to develop quite much in short time. But you don’t realize what theproblems are until after a period.

—INTERVIEW D.2.1

The reason for this division between the students and the moreexperienced developers, might be lack of experience among the former.The quotation above supports this theory. Students usually work on smalland relatively simple applications, and the common problems that occurwith Angular and its dirty checking doesn’t show up in such applications.

In general, few problems are encountered in small and less complexapplications - they most often occur at larger scale. The students mighttherefore get the illusion of knowing the framework Angular well, becausethey have only used it where it is easily applied and therefore have theimpression that it is easy to learn and understand.

The results showed that most of the students rated their knowledgeabout Angular as good, and that it was easy to learn and get started with.In addition, it was also found that several of the students rating theirknowledge as good, were not familiar with the concept dirty checking.This indicates that they lack knowledge about central parts of how theframework functions. This knowledge is not important when workingon small and less complex applications, but at once the applicationsgrow in size and complexity, it is necessary to have knowledge about theunderlying concepts both to avoid and fix bugs and performance issues.

The lack of knowledge about the underlying techniques used by theframework is also giving support to the theory about students havingshallow knowledge about the framework. They have not experiencedthe problems yet, and therefore think it solves everything in a good way.Several of the developers interviewed confirm to this, and one of them saidthe following:

There are a portion of details that you don’t know of until you’ve beenworking on it for some months. Tutorials only show were the frameworkreally shines.

—INTERVIEW D.2.2

Tutorials and small projects are not sufficient to get a deep understand-ing of the framework. The inexperienced developers are not aware of thedetails they are missing, and they might therefore think that they managethe framework well. The results from the interview show that this is notunusual. Several of the developers found Angular to be easy to start with,but experienced that it gradually got problematic.

The dirty checking approach makes it easy to get started on basicapplications, as the developer gets to use pure JavaScript objects tostore data, and the data-binding is taken care of automatically. Theunderlying details are hidden from the developer, giving an impression

69

that the DOM is updated “magically”. This might also be the reasonwhy inexperienced developers think they have good knowledge about theframework Angular, even if they don’t know what is happening at a lowerlevel.

Backbone

The developer needs to perform tasks at a lower lever in Backbone, asmentioned earlier. KVO is often used together with the MVC pattern, and itis therefore necessary with knowledge about MVC to understand Backboneand KVO.

Backbone is trivial enough when one has understood the MVC pattern.

—INTERVIEW D.2.3

The results from the interview showed that developers already familiarwith the MVC pattern found Backbone to be easier to learn than developersnot familiar with MVC. Some of the developers also learned Backbonetogether with JavaScript. Because of this, it is difficult to know if it is theKVO approach or other aspects that complicates the startup.

The KVO approach takes use of events and listeners, which are familiarto JavaScript developers. From the interviews it was found that the KVOapproach itself is not a major issue, it is the MVC structure that can be hardto get a grip on at first.

The students rated Backbone as harder to learn than Angular. Thismight be explained by the amount of work that has to be done by thedeveloper. More work has to be done by the developer in Backbone, as databindings need to be set explicitly. The more experienced developers foundthe understandability of Backbone to be better than the one of Angular, asit is easier to understand what is going on “under the hood”.

React

The virtual DOM approach in React opens for a new way of thinking. Moststudents rated their knowledge about React from little to the middle of thescale, and very few respondents had good knowledge about it.

When it comes to how easy it is to learn the framework, most studentsrated it from the middle of the scale to easy. One reason why the knowledgelevel of React is smaller than the one for Angular might be the fact thatReact and the use of virtual DOM in front-end development is quite new.

The results from the student survey also show that it is common tochoose the framework first learned, and the framework one already isfamiliar with. As Angular was popular at the time before React’s release,it is reasonable that more developers are familiar with it. Through theinterviews it was found that the way of thinking in React was tricky atfirst, but quite simple once understood.

70

It was really simple to understand how React works. It took me about 3days until I had the feeling of having the framework under control,unlike with Angular, which I didn’t fully understand after a year ofworking on it.

—INTERVIEW D.2.4

The results from the student survey rated Angular to be easier tolearn than React. The results from the interviews show that experienceddevelopers have the opposite opinion. The reason might be the student’slack of experience with complex applications, in addition to relatively littleexperience with front-end development in general. The reasons why thedevelopers find React to be easier, is its simplicity. While React onlyrequires knowledge about HTML and JavaScript, Angular introduces a lotof new concepts that the developer needs to have knowledge about for thedirty checking to work properly. React was also rated as relatively easy tolearn by the students, compared to Backbone and its KVO.

Getting started

Angular and its dirty checking is rated to be the easiest to get started with.It is a good choice if an application needs to be built fast, because it iseasy to get an application up and running quickly using this technique.The virtual DOM approach is the second best, because lower level detailsare taken care of by the virtual DOM, and the amount of manual work issmaller than with KVO.

Understandability

The students and the experienced developers seem to disagree on howhard it is to understand each of the frameworks. The students finddirty checking to be simple, as the underlying details are abstracted awayand there are fewer tasks to take care of manually. The developershave experienced problems with the hidden details of Angular, and haverealized that it is more complicated than it looks like at first glance andharder to understand. Dirty checking is easy to get started with, but notnecessarily in the correct way.

The experiences with React and Backbone are more similar among thestudents and developers, and this indicates that the frameworks give amore correct impression at first. Both Backbone and React contain fewercomponents than Angular. The lower level details in Backbone are notpresent in React, and both students and developers rated React to besimpler to get started with than Backbone.

As a result of this, virtual DOM is rated to be the easiest to understand,while dirty checking is the hardest.

5.3.2 Onboarding

Many projects span over years, and different developers are assigned tothe projects. Information about onboarding new developers was obtained

71

through the interviews. Not surprisingly, the results show that it ismore difficult to onboard people to complex applications than to simplerapplications. In addition, differences between the frameworks were found.

The interviews revealed that the component structure in React simpli-fies the onboarding, because it makes it possible to explain the applicationin smaller pieces. One of the developers said the following about explain-ing the application to new developers on the project:

It is convenient to explain the components. It is possible to explain it inpieces, and work on one single component and what is happening insideof it. By focusing on one component and how it communicates withanother component, in detail, it might be easier to understand theapplication in whole.

—INTERVIEW D.2.5

This is an advantage with the virtual DOM approach. The componentsmake it possible to understand the dataflow and the different parts of thecode by only looking at a small portion of the application. The reason isthat the whole application is following the same component structure, andthe data flows in the same direction throughout the whole application.

The developers find it easy to explain the application structure tonew developers not familiar with the framework. The new developersunderstand both the framework and get an overview of the applicationin short time.

Another project, which rewrote the code from Angular to React,has experiences in onboarding new developers to both frameworks.The developer representing this project told about a developer with noJavaScript experience at all. She became productive in both frameworks,and found it to be easy to work on React - even though she found theamount of code to be larger. He also said the following about React incomparison to Angular:

It is not difficult to get into React. I think Angular is worse, because thereare so many ways to use the API, and it will therefore vary to a greatextent from project to project.

—INTERVIEW D.2.6

Angular’s API is complex, and the quote below confirms that this canresult in problems. Even though a developer has experience from earlierAngular projects, the framework might be used quite differently.

Angular is big, and you have freedom with responsibility. There aremany tools that can be used, but they are not necessarily the right ones.Things are done differently in different projects, and it gets hard toonboard new developers.

—INTERVIEW D.2.7

72

The advantage with React is the simplicity of its API. Because it is muchsmaller than Angular’s API, it is easier to reason about it. At the same time,it is difficult to know whether it is the complexity of the application or theframework that makes things complicated, as stated by another Angular-developer:

When building large applications, one also gets complex applications. Itcan be difficult to distinguish between what is the framework’s fault andwhat is a result of the application’s complexity.

—INTERVIEW D.2.8

There is no doubt in that the complexity grows with the size of theapplication. Several projects stated that the complexity of the applicationbecame the bottleneck, and not the framework itself. One of the developerswith experience from Angular stated that a good code review at startupwas of high importance, while another developer using React experiencedthat new developers could start developing, and even reuse components,without the need for any introduction.

We see a big difference between those who get a good code review andthose who don’t.

—INTERVIEW D.2.9

Even though the application’s complexity seems to be the bottleneck,the complexity of the framework is also important. From the interviews, itwas found that it is simpler to onboard people to Backbone projects than toAngular projects, because of the frameworks’ complexity.

Angular introduces a lot of new concepts related to dirty checking,which are not used elsewhere in JavaScript. Through the interviews it wasfound that it is difficult to understand the semantics of the different parts.With Backbone there are fewer concepts to deal with, and therefore fewerthings to learn. The conclusion is 1 point to dirty checking, 2 points to KVOand 3 points to virtual DOM.

5.3.3 Customization

Some frameworks can be used in several ways and give the developer largefreedom and the possibility to adjust the solution to the specific application.Other frameworks have more strict guidelines and need to be used in aparticular way. The amount of tasks the framework aims to solve is alsoimportant here. While some frameworks want to provide a full solutionand remove the need for any additional frameworks or libraries, others arefocusing on smaller tasks.

KVO allows the developer to make choices and doesn’t decide whichdesign patterns to follow. Dirty checking and the virtual DOM approachare giving more strict guidelines. The dirty checking approach is thestrictest choice among the three. The concepts introduced by Angular needto be used for the dirty checking to work properly. If changes are made

73

outside of the framework’s control, they won’t be detected. Dirty checkingtherefore offers little flexibility, and it is not easily combined with otherframeworks and libraries due to its extensiveness.

The virtual DOM approach is somewhere in-between. This approachfocuses on the rendering part of the application, and therefore allowsthe developer to make choices and customize the solution. It is easilycombined with other frameworks and libraries, as the input is JSON orpure JavaScript objects.

Backbone is not good at dictating, and that was one of the strengthswhen the framework was taken for consideration. You can do things inyour way and still get a lot for free.

—INTERVIEW D.2.10

Flexibility has both advantages and disadvantages. KVO is flexible andtherefore makes it easier to customize the solutions. The developers alsoget more freedom to do things in their own way. The drawback is moredifferences between individual projects using the same framework. If astrict framework is used, it is easier to jump from one project to another,without spending a lot of time to get an overview.

The virtual DOM gives a clear structure to the rendering part, but offersflexibility at how the rest is solved. The advantage with this is a clear wayto update the view, at the same time as it is possible to customize the restof the structure.

The more important and specific the application is for your sector ordomain, the more difficult it will be to push it into such large frameworksas Angular, which seek control from A to Z.

—INTERVIEW D.2.11

With dirty checking and the building blocks that need to be used, itis easy to build applications that fit well with the framework’s structure.The research shows that developers find it hard to make applicationsthat go beyond the framework’s limits, which can cause problems as theapplications grow in size and complexity. It is difficult to customize theapplication structure, as it is encompassing and not easily integrated withother frameworks or libraries. The framework needs full control for thedirty checking to work properly, and it is therefore difficult to combine itwith other libraries and frameworks and make customizations. As a resultof this 1 point is given to dirty checking while 2 and 3 points are givenvirtual DOM and KVO respectively, because KVO is giving the highestlevel of control to the developer.

5.3.4 Uniform usage

Even though the flexibility is low, it doesn’t mean that it is clear how to usethe technique. As the quotes below confirm, the new concepts introduced

74

with dirty checking are used in multiple ways, and the developers havedifferent opinions on what is the correct way to do it.

There is no correct way to do things in Angular. It’s a big API with many,many ways to connect things.

—INTERVIEW D.2.12

This causes conflicts between developers, and leads to applicationswithout a consistent structure. This might again increase the difficulty fornew developers to get started on the project.

There are disagreements on how to use the framework. Even though twoways can be correct, it results in divergence of the code styles. Onetechnique is used here and another one there, and that is unfortunate.

—INTERVIEW D.2.13

The same is also found in KVO, where developers find their own waysto do things. KVO offers fine-grained control to the developer, openingfor individual code styles. The virtual DOM approach makes it more clearas all functionality is placed within the component it belongs to, and itis therefore given the highest score. The problems are found to be morewidespread in Angular than in KVO, and KVO is given the second highestscore.

5.3.5 The mental model

A lot of state is what makes building UIs hard. An application containsa lot of UI elements, mutates the DOM, responds to user interaction andcontains data that is changing over time. This contributes in makingapplication development hard. There is a lot of state that needs to betaken care of in the application, and this turns out to be a challenge forthe developers.

The power of humans to visualize processes that are changing overtime is limited, and we are better at dealing with static relations. Wecan easily understand how a function works at a single point in time, bylooking at the input and output. The problem is when the function getscalled over time, and variables are changed. It is difficult to keep theprogram state in mind and foresee how the function works as the stateevolves and changes. It is important to be aware of the human capabilitiesand limitations, and the meaning of the following quote is important inovercoming these limitations.[13]

We should do our utmost to shorten the conceptual gap between thestatic program and the dynamic process, to make the correspondencebetween the program and the process as trivial as possible.

—DIJKSTRA [13]

75

The meaning of this quote is to make programs that evolve over timelook like they execute at a single point in time. This points towardsfunctional reactive programming, or declarative programming, where thefocus is on what the program should look like, and not how to get there. Thisprogramming style is encouraged by the use of virtual DOM. It is specifiedhow the DOM should look like at any point in time, and not what changesthat should be made to make it look like that. The virtual DOM makes itpossible to think that the whole application is re-rendered at data change,making the mental model considerably simpler.

In KVO, the developer performs the changes manually and thereforeneeds to keep track of the state to a higher degree. This results in a morecomplex mental model.

Dirty checking also takes use of declarative programming, whichcontributes in making its mental model simpler. The fact that dirtychecking introduces a lot of new concepts to keep in mind, makes its mentalmodel more complex than when using virtual DOM, but not as complex aswhen using KVO.

The dataflow is also important here, and this is confirmed by theinterview results.

One-way dataflow is much clearer, and it is simpler to understand wherethe state is getting updated and sent to. The state represents the view100%. It is much simpler to relate to, and it simplifies how everythingworks together in the application.

—INTERVIEW D.2.14

With virtual DOM, one gets one-way dataflow out of the box. Dirtychecking gives a two-way binding which works well as long as there are noproblems and you don’t need to think about it. The two-way binding getsproblematic when bugs occur. It is difficult to keep track of what happensand locate the mistake. In KVO it is the developer’s task to set up thedataflow. This increases the risk of getting a complex dataflow which againcomplicates the mental state. The KVO approach is therefore given a scoreof 1, dirty checking 2 and virtual DOM 3.

5.4 Abstraction level

The rendering techniques have different approaches to keep the DOM up-to-date, and they are different in how much of the process the developerneeds to be aware of and participate in. The more involvement requiredfrom the developer, the more visible the DOM interaction will be to thedeveloper. If the developer needs to perform a lot of low-level DOMoperations to render, the abstraction level is low. If the rendering techniquetakes care of the low-level operations and lets the developer specify thechanges or the view without touching the DOM directly, the abstractionlevel is higher.

How much the developer is involved in the DOM interaction decidesthe abstraction level. The abstraction level provided by the different

76

Table 5.8: Rating the abstraction level

Dirty checking KVO Virtual DOMInvolvement 2 1 2Reliability 1 2 2Boilerplate code 3 1 2State 2 1 2Productivity 2 1 2Underlying details 2 1 3Coupling & cohesion 2 1 2Total 14 8 15

techniques will be explored, and advantages and disadvantages by havinga high abstraction level will be discussed. Table 5.8 presents the subjectsfor discussion and shows how the techniques score in each category, andthe following discussion is related to RQ2.

5.4.1 Degree of involvement

Dirty checking, virtual DOM and KVO take use of different methods torender the view to the DOM. As a consequence, the amount of workthat needs to be performed by the developer varies between the differentmethods. The degree of involvement in each of the techniques will beexplored.

Angular takes use of two-way bindings between the view and the datamodel, and the view and model is kept up-to-date automatically oncethey are defined by the developer. The abstraction level provided is high,and the developer doesn’t have to think about how the view and data isupdated, it happens automatically.

The virtual DOM also abstracts away the real DOM from the developer.The developer only writes code that describes how the UI should look, andthe virtual DOM takes care of the rest.

Developers using KVO are much more involved in the DOM interac-tion. Whenever a change happens, the developer manually has to performthe steps to get from the previous state to the new one. KVO requires themost from the developer, using an imperative programming style, and itis given 1 point here. Both dirty checking and virtual DOM take use of amore declarative programming style and are awarded 2 points each.

5.4.2 Reliability

Dirty checking aims to abstract away the DOM interaction, but theinterview results showed that it still is necessary with knowledge aboutthe underlying DOM operations. To circumvent the performance issuesintroduced by dirty checking, developers must have knowledge about whythe problems occur and find alternative ways to update the DOM. It is

77

necessary to be aware of the fact that dirty checking is done. Otherwise,if a lot of tasks are performed, it will result in a lot of DOM operations andbad performance.

One needs to be aware of low level details about the dirty checking toavoid performance issues. The developer notices that the application isslowing down and needs to perform optimizations and changes to avoidproblems.

The abstraction provided by dirty checking gives a false sense ofconfidence to the developer. Everything seems to be well taken care ofby the framework, until the application suddenly is getting slow and thedeveloper realizes that the dirty checking isn’t as good as it seems.

It was also found that the abstraction level provided by dirty checkingworks fine until problems occur, but then it starts to get problematic. Thedirty checking ensures that all updates are performed automatically, butwhen an update is omitted or not done as expected, it is difficult to knowwhere the source of the mistake is.

Several of the developers interviewed have experienced that they needto dig into the details of dirty checking to figure out why the updates arenot performed correctly, and often they end up trying things randomly tomake it work. As every update is supposed to be performed magically bythe framework, the dataflow is abstracted away from the developer. Asa result, it is hard for the developer to follow the steps performed by theframework and detect the mistake. The following statement confirms this.

In Angular we often ended up pushing the whole model into the HTMLto look at it, and guess where the mistake is. In React one can almost puta breakpoint in a rendering component and see what you get.Developmentally React is several steps better than Angular at this point.

—INTERVIEW D.3.1

The interview results showed that the abstraction provided by virtualDOM doesn’t cause the same problems. The application state is changed inone single place, and it is therefore easy to know where all state transitionswill happen. The state is isolated as much as possible. If bugs happen,the bug is almost always found by looking at the places where the stateis transitioned. With dirty checking it is not clear where the state istransitioned, and it gets more complicated to follow the dataflow and findthe fault sources.

KVO doesn’t hide details beneath any abstraction layer. The codeis written at a lower level, and it is clear to see from the code what ishappening. The result is 1 point to dirty checking and 2 points to KVOand virtual DOM.

5.4.3 Declarative vs Imperative Programming

Both dirty checking and virtual DOM take use of a declarative code style.As described in Section 2.9 about declarative and imperative programming,there are important differences between the two programming styles.

78

Students are mainly learning imperative programming at school, andthis is also the most used programming style among developers. Theinterviews revealed that the developers were most comfortable with theimperative programming style and found the declarative programmingused by the virtual DOM approach to be difficult and unfamiliar at first.

The level of control given by KVO was pointed out as an advantage.The developer is in control of what is happening all the time, and there isno “magic”. Programmers are used to the imperative way of writing codeand are comfortable with specifying how every task should be carried out.The developers interviewed mentioned that it took a while before gettingcomfortable with the declarative programming, as it requires a differentway of thinking. Once they got used to it, the advantages got clear.

Boilerplate code

The reduction in boilerplate code was mentioned as an improvement byseveral of the developers interviewed. A large amount of boilerplatecode was experienced using KVO in applications with a lot of interaction.The declarative programming style showed to decrease the need for thisboilerplate code.

Applications built using dirty checking and virtual DOM required asmaller amount of code to be written. By removing the need to specifyhow things should happen and focus on what should happen instead, thedevelopers can write code at a higher level. In applications with forms,and in other cases where two-way bindings are preferable, dirty checkinggives the smallest amount of boilerplate code. In other cases, dirty checkingand virtual DOM are more similar. The result is 1 point to KVO, 2 points tovirtual DOM and 3 points to dirty checking.

State

The possibility to ignore low-level details was specified as a big advantage.The developers found the amount of state to handle to be smaller usingdirty checking and virtual DOM, than what they had experienced with theKVO approach. This findings are supported by the research performedon declarative programming. The imperative approach is seen as stateful,while the declarative approach is seen as stateless.

With KVO it is necessary to keep track of dependencies to correctlyupdate the application on change. This is not needed with dirty checkingand the virtual DOM, and they are evaluated to be better than KVO at thispoint.

Circumstantial and sequential information

Research on declarative- and imperative programming has shown thatit is more difficult to keep track of sequential information when usingthe declarative approach. This is confirmed by the interview results.Several of the developers have experienced problems in following the stepsperformed in the application. The loss of sequential information is not a

79

problem as long as the application is working correctly, but it has shown tobe a problem when a bug has occurred and the source needs to be found,especially with dirty checking.

Programmer productivity

The possibility to program at a higher level, and decrease the amount ofstate and boilerplate code in the application, also brings other advantages.The developers get to focus more on the functionality of the application,and care less about low-level details.

The interview results show that the developers find a higher abstractionlevel to increase productivity and reduce the amount of bugs in theapplication. These results are supported by the research done ondeclarative programming. The declarative approach has shown to give asimpler semantic and make it possible for the developer to focus more ondeveloping correct functionality. Declarative code has also been found tobe easier to reason about and transform. These are important propertiesof an application, as the applications are evolving, and the code might berevisited and changed multiple times in the future.

The performance test results show that the performance is good enougheven if the low-level operations are taken care of by the framework. Itmight be possible to get better performance manually, but the possibleimprovements do not outweigh the amount of work it requires. In addition,it is difficult for the developer to make perfect choices every time. Thedeclarative approach doesn’t necessarily give the best performance, but itis good enough and makes it possible for the developer to focus on the bigpicture and not on low-level details.

5.4.4 Underlying details

Both dirty checking and virtual DOM abstracts away the low-level DOMoperations from the user, but they approach the DOM in different ways.The virtual DOM lets the user specify how the view should look like usingJavaScript and a component structure, removing the need to specify theview in the way it is represented in the DOM, namely using HTML. Asmentioned, the web was not created with applications in mind, and thevirtual DOM approach solves this by abstracting away the real DOM fromthe user.

From the interviews it became clear that developers don’t want to careabout the underlying method used to perform DOM updates. They wantto specify how the view should look like, without thinking of how theunderlying DOM operations are performed. With this in mind, it lookslike the virtual DOM technique is on the right track by abstracting awaythe real DOM. Dirty checking is also abstracting away the low-level DOM-operations.

The amount of JavaScript knowledge required is also affected by theabstraction level. The low-level operations in KVO makes it necessarywith a deeper understanding of JavaScript, as databinding is handled

80

manually and explicitly using JavaScript events. Both dirty checking andvirtual DOM takes care of these low-level operations and less JavaScriptknowledge is necessary.

At the same time, the virtual DOM approach adds an additional layerof abstraction between the DOM and the developer. This doesn’t seem tobe an issue for the developers, as they can forget about the real DOM andonly focus on the abstraction layer. The mental model is not complicated,as the real DOM is of no concern.

With dirty checking, the real DOM is still a concern for the developer.The performance issues make it necessary for the developer to haveknowledge about the underlying DOM operations, and the abstractionlevel provided cracks as a result of this.

KVO gives no abstraction at all, making it necessary for the developerto adapt to the real DOM. KVO breaks with the developers’ desire to avoidhandling the DOM operations, as these need to be taken care of manually.No abstraction is given, and the developers manually update the DOM andminimize the amount of DOM operations to make sure that performanceproblems are avoided. The result is therefore 1 point to KVO, 2 points todirty checking and 3 points to virtual DOM.

5.4.5 Coupling and cohesion

The use of components gathers and groups related code, and this resultsin increased cohesion. At the same time each of the components isindependent of each other, and the coupling is therefore reduced. Theindependence of the components makes it easy to reuse them. This hasbeen experienced by developers interviewed. They could easily reuse acomponent without having to make any changes to it, and without havingto spend time reading up on how it should be done.

The simplicity of component reuse opens for a new way of buildingapplications, by taking use of finished components to a higher degree thanwhat normally has been done in JavaScript development up until now.Usually, most of the application is built from scratch every time, but withreusable components, this could be changed. There already exists an open-source project2 containing a searchable database of React components,where people can make contributions by adding their components. Theincreasing use of reusable components will make it possible to write lesscode to build UIs, which again leads to a faster development process andlower costs. The amount of bugs in the code will also get smaller, as thereusable components are tested and contain few bugs, and the developerhas less new code to focus on.

When an application is planned and designed, it is common to thinkof the different parts of the application as elements, or components,containing subcomponents. By being able to take use of the same structurein the development, as is used in the design of the application, it is easierto reason about it. The code constituting one feature is gathered at one

2The open-source project is available at www.react-components.com

81

place, in one component, and the developer therefore knows exactly whereto make changes in the code, depending on which component the changeis related to. Both dirty checking and virtual DOM facilitate components.

The mental operations theory described in Section 2.9.2 is of importancehere. By having an application structure that corresponds well with thenatural way of thinking about the application, fewer mental operations arerequired to develop new functionality. Fewer mental operations are shownto lead to better performance, which means more efficient development.

5.5 Scalability

Facebook is operating at very large scale, and they therefore often findlimitations when using software, as the software was not made with alarge-scale application in mind. The Facebook application is at extremelylarge scale, but the interview results revealed that the same type ofproblems was found in smaller applications too. The problems aretherefore of high relevance for a large amount of web developers and theirapplications, and it is interesting to take a look at what the problems are,why they occur and whether it is possible to omit or solve them.

The topics to be discussed are given in Table 5.9. The virtual DOMapproach is given the highest score and is therefore rated to provide betterscalability than the other techniques. The discussion leading up to theseresults are presented in the rest of this section.

5.5.1 Problems at scale

Facebook consists of a large amount of application code, and they haveshared some of their experiences in building large applications. It isimportant for them to build high quality code by default. Facebookhas experimented with different methods to achieve this, and one of thetechniques they have tried is MVC. As Facebook is the company behindReact, it is not difficult to see that they were not satisfied with the use oftraditional MVC frameworks when developing at their scale.[10]

Facebook realized that the use of MVC got complicated quickly. Itdidn’t scale well for them. Every time they added a new feature, the wholesystem got more complex. The problem they had was that the code wasresponsible for doing more than one thing, and the data was used in several

Table 5.9: Rating the scalability

Dirty checking KVO Virtual DOMDataflow 1 2 3Cascading effect 1 1 3Testability 1 1 2Total 3 4 8

82

places, resulting in unpredictable code. The complexity made it hard fornew engineers to understand how the code worked. It was difficult toknow whether small additions or changes had unforeseen consequencesor not, as they didn’t have a full overview and didn’t trust what was goingon in the system.[10]

Facebook realized that new engineers needed to consult the ones whohad written the code to ask whether or not their code change would breaksomething, and that was a sign that the application structure was not goodenough. This unpredictability made it hard and time-consuming to addnew features. Facebook realized they needed a new solution that increasedthe predictability.[10]

The developers interviewed experienced the same type of problems. Asthe systems got larger, it became difficult to keep an overview of the code.Code changes led to unforeseen side-effects, and developers didn’t want totouch parts of the application that were complex. The originator of the codewas the only developer that knew how it worked, but this was not alwaysthe case either. The result was code that nobody wanted to make changesto, and it got hard to maintain the application and add new features.[10]

The interview results showed that these problems most often occur inprojects taking use of the KVO approach, but they were also found inprojects using dirty checking. The developers working on projects thatuse the virtual DOM approach did not report this to be a problem. Thereason for these results can be found by taking a closer look at the dataflowprovided by the different approaches.

5.5.2 Dataflow

With the KVO approach, the developer is in control of the dataflow. Data-bindings are set manually by the developer, and data flows in either onedirection or in both directions between the view and the data model.For simpler applications with few data-bindings, this works fine. Theinterview results showed that the developers found KVO to be a goodchoice in applications with few interactions. When the application containsfew data-bindings, it is simple to keep track of the dataflow.

In applications with more heavy interaction, the developers found KVOto be less useful. With several points of interaction and a large amountof data-bindings, they found it difficult to keep track of the dataflow andget everything to work correctly. The same problems were also found byFacebook.[10]

The dirty checking approach gives a similar dataflow. At first sight,it seems to be simpler, because it is abstracted away and hidden. Thedeveloper doesn’t have to think of the dataflow as long as everythingworks fine. Underneath the abstraction layer, there are two-way data-bindings making the data flow in both directions, like with the KVOapproach. As the DOM operations need to be taken care of manually incase of performance problems and bugs, it is not possible to fully ignorethis dataflow. The developers experienced the same problems with dirtychecking as with KVO - it was difficult to keep track of how the data flows

83

in the application and find the bugs.The virtual DOM approach makes data flow in one direction. Instead

of having multiple data-bindings where the state gets updated, the stateis updated from one place. In this way, it is easier to get an overview ofthe dataflow and find the bug. Virtual DOM is rated to give the simplestdataflow, and dirty checking the most complex. The reason why dirtychecking is rated last is the hidden dataflow that is harder to follow thanKVO’s dataflow, which is more explicit.

5.5.3 Cascading updates

When there is a lot of interaction, the amount of data-bindings will be high.Some elements in the view are connected to several elements in the datamodel, and this is also the case the other way around. It is not difficult torealize that this leads to a complicated dataflow, where data flows in alldirections. One change can cause another element to change, which againcauses an element to change, and so on. These cascading updates werementioned as a big problem when using KVO. The developers experienceddifficulties in tracking what was going to happen on an element change,and they also experienced problems with infinite loops. When events arefired by events which again are fired by events, it easily causes problems atscale. Bugs might be visible in the application, but it is hard to locate thecode that causes the bug to happen, as there is no clear structure in how thedata flows.

Also with dirty checking the cascading effects were listed as a problemby the developers interviewed. A digest cycle is executed, making updateswhich again can cause a new digest cycle to be performed, and so on. Thiscan lead to endless loop of digest cycles being executed, and it is hard tofind the reason for the infinite loops, like with the KVO approach.

With the virtual DOM approach, these cascading effects are avoided.The other approaches perform updates, which again causes new updatesto happen. Virtual DOM creates a whole new representation of the DOMon change, causing all updates to be performed at once. By having all dataflow in one direction, it is easier to reason about the application.

Virtual DOM gives a significant improvement from the other two andis given 3 points, while the others get 1 point each.

5.5.4 Bug fixing & Testability

The uniform dataflow makes it easier to see how the data flows in theapplication, and gives a simpler mental model and a better overview.Another advantage is that it makes it easier to find the root of a bug.With dirty checking and KVO, it is necessary to follow several steps andevents to find the cause, but this is not necessary when all data flows in onedirection. The application state is updated in one place, and the mistake ismost likely found by looking at the state transitions.

Testing the application code is crucial in developing reliable and well-functioning applications. The virtual DOM approach gathers all logic

84

and state at the same place and makes it possible to test components likefunctions. The component is given an input and is expected to result in acertain consistent state.

The developers interviewed mentioned problems with componentsgetting too large in the beginning. They found it to be no big issue aftersome time, as they got used to thinking of building as small components aspossible.

When all data flows in the same direction, it is possible to follow thesteps of one action throughout the application and obtain knowledge abouthow the rest of the system works. With dirty checking and KVO this is notpossible, as the data flows in both directions and varies throughout theapplication. The result is 1 point to KVO and dirty checking and 2 pointsto virtual DOM.

5.5.5 Adding new functionality

New functionality gets added over time, and keeping it easy is important.Through the interviews it was found that adding new functionality inAngular can be hard. It depends on the complexity of the functionality,and to what degree it affects existing code. It is simple to make additionsif no changes must be made to existing code, but otherwise it quickly leadsto unpredicted incidents. Changing complex functionality can be hard,especially if it lives across multiple files and digest loops.

The difficulty depends on the complexity of the application and the newcode to be added. It is difficult to reveal the impact of the techniques used,and there are not enough grounds to base the rating of the techniques on.

5.6 Familiarity

There are a lot of frameworks to choose among when a new project isstarted, or when an existing project realizes that it might be beneficialto replace the existing framework with something new. It turns out thatintroducing or replacing a framework is not as simple as it might seem. Thenew framework is unfamiliar, the benefits are unclear and nobody knowswhat problems it might lead to. Replacing a framework is not done in a day,it is both costly and time consuming. Because of this, it might be easier tostick with the familiar solution. At the same time, developers want to takeuse of new and promising solutions. For the frameworks to evolve and getbetter, it is necessary to take use of new solutions as they are released.

The discussion in this section is related to RQ3. Even though newsolutions are promising and seemingly better than the solutions used today,there are several reasons why it is not possible for everyone to take use ofthem immediately.

5.6.1 Preferences

The student survey showed that students prefer to use the frameworkthey first learned and have experiences with. Once they have obtained

85

knowledge about a framework and know how to use it, they want to keepusing it instead of spending time learning alternative solutions. The samereasoning was also done by the developers interviewed. The developerssaw the benefit in keeping the familiar framework, but they also consideredthe drawbacks with the familiar solution to a greater extent.

Even if new solutions sound promising, they are unknown. Thedevelopers don’t know what kind of problems they will meet if they adoptthe new solutions, but they are familiar with the consequences of stickingwith the old solution. Because the advantages with the new solution aredifficult to picture, and the advantages of keeping the old solution aremuch clearer, it is easy to prefer the familiar one. The following quote isan example of this.

The advantage of keeping the old framework is much easier to see whenstarting a new project without problems. Problems are found everywhereelse, so let’s just choose the framework we know well.

—INTERVIEW

Through working with the framework in projects, the developer hasobtained knowledge about how to avoid the common problems, and howto structure the application to make the development go as simple aspossible. After years of experience, the developers have learned from theirmistakes. Several of the developers mentioned a large improvement in howthey structure the code, compared to a few years ago. When looking at codewritten a short while ago, they realize that the same choices would not havebeen made today.

Valuable knowledge

The knowledge obtained through years of experience is of high value. Alarge amount of this knowledge is not utilized when the familiar solutionis being replaced. Some parts of the knowledge might be transferable toother solutions, but most of the lessons learned are specific to the solutionused. When starting over with a new solution, it will again take years ofexperience until the same level of confidence is obtained.

5.6.2 Long-term solutions

When starting a new project, it is easy to stick with a framework thatis familiar. It is not necessary to spend time learning how to use theframework, and the startup time is short. From the developer’s point ofview, it might seem simpler to keep the old framework, but this is notnecessarily the case.

Don’t trade simplicity for familiarity—PETE HUNT [27]

Even though a solution is familiar and you know how to avoid thebiggest pitfalls, it is not necessarily simple. The same problems are still

86

present, but the developers have gotten better at avoiding them. If thedevelopers have enough experience to manage to avoid pitfalls easily, it isnot a problem itself to take use of the old solution. One cannot assume thatthe project will be maintained by the same set of developers throughoutits lifetime. This is where the lack of simplicity gets problematic. Newdevelopers are expected to be included in the future, and it is thereforeimportant to ensure that the solution used makes it easy to onboard newdevelopers, without requiring years of experience with the project andframework used.

5.6.3 Standardization

It is not always the developers that get to choose what framework to use.The interviews revealed that some customers want to standardize theirapplications, and therefore require a specific framework to be used. Thereason for this is to have a similar structure on the different applicationswithin the company, to make maintenance simpler and more cost efficient.Cost reduction is important for the customers, and the cost is thereforeweighed against the benefits in the choice of framework to use.

5.6.4 Benefit vs cost

The introduction of a new framework needs to be beneficial compared tothe cost of replacing a known framework with something unfamiliar thatrequires the developers to start from scratch. Several of the developersinterviewed mentioned savings as a result of using the same framework inseveral applications. By using the same framework, it is possible to reusecomponents in several applications.

We got a lot of common components in Angular. The incentives by usingAngular are big, because we get so much free from the ecosystem we’vebuilt around it.

—INTERVIEW D.4.1

The cost of replacing the framework is therefore high. The benefits ofkeeping the old solution are easier to see than the benefits of starting overwith a new solution. In addition, it is impossible to know which problemsthat might occur. What if the problems are big and costly? By keeping theold framework, the developers have experience with it and know how toavoid problems.

5.7 The influence of virtual DOM

The impact of virtual DOM in frontend development will be discussed inthis section. The following topics are tightly related to answering RQ3.

The use of KVO and the MVC pattern has for a long time been seenas the more correct way to build applications. With the introduction ofthe virtual DOM, these established best practices are reassessed. Several of

87

the developers have experienced problems with KVO and clearly see theadvantages of using a virtual DOM and have the ability to develop UIs ata higher abstraction level.

Pros and cons by the different approaches are frequently discussed, andthis has contributed to more awareness about how the dataflow should beand how the application should be structured.

Other frameworks are starting to use virtual DOM, and it is gettingcommon to use structuring frameworks like Backbone and replacing theview part of the framework with React. In this way, the structure of thedata in the application is the same, but the performance improvements,and the simplicity of the virtual DOM approach is achieved.

5.7.1 One-way dataflow and declarative programming

With the other approaches mainly used today, the data flows in alldirections. The introduction of the virtual DOM has made the developersmore aware of the advantages with a simple one-directional dataflow.

The transition from an imperative to a declarative way of specifyingthe UI is also one of the biggest impacts of the virtual DOM. The virtualDOM approach has shown that it is possible to let the framework handlelow-level details and still get a well-performing and well-functioningapplication.

Other large frameworks are seeing the benefits of a one-directionaldataflow, and Angular have announced that they are going from two-waybindings to a one-directional dataflow in Angular 2.[43]

5.7.2 Towards component-based structure

The MVC pattern has become well established in application development.The introduction of the virtual DOM has softened the impression that thestructure following from the MVC pattern is the best solution. Developersseem to have been convinced that this structure should be used, but nowa large part of them seems to have changed their mind. The developersinterviewed found a lot of advantages with the component structure, andmany of them are convinced that this is a better way to build applications.

I think that is how the web should be. The issue is that the web was notcreated for components, if thinking about the DOM. We are on our wayto get there with the shadow DOM that is on its way. I envision small,completely independent components that can be put anywhere.

—INTERVIEW D.5.1

Until Web Components and the shadow DOM is fully available to use,virtual DOM is a good option to take use of the component structure. Ithas taken application development a step in the right direction towardscomponent-based web-development.

88

Figure 5.5: The frameworks’ popularity: questions asked on StackOverflowper month

5.7.3 Increased usage

The use of virtual DOM has become popular, and several companies thatare starting to use the technique have been mentioned. By looking atthe number of questions posted at StackOverflow, it is found that thepopularity of React and the virtual DOM is increasing, at the same timeas a decreasing amount of questions are asked about Backbone. Angular isstill a popular alternative, and it will be interesting to see whether it willkeep its position when the virtual DOM approach is getting more settled.Figure 5.5 shows the situation today.[47]

5.7.4 Expanding JavaScript’s usage areas

The introduction of the virtual DOM approach in JavaScript developmentalso opens for the use of JavaScript in new areas. Because the DOM isabstracted away, and the virtual DOM is the connection link between theapplication and the DOM, it is possible to replace the DOM with othertargets. The developer can use JavaScript to create all sorts of applications,and the virtual DOM will take care of the conversion to the target format.Netflix is an example of this. They use the virtual DOM approach withother target nodes than the DOM.[31]

Native application development is another usage area made possiblethrough the use of virtual DOM. Facebook released React Native in thestart of 2015, and this is a framework utilizing virtual DOM to build nativeapplications in JavaScript.[15]

5.7.5 The goal behind React

Facebook would not have released React if they didn’t make moneyand improve their market position, but they have also mentioned theimportance of spreading the use of the virtual DOM and the declarative

89

way of building UIs. Facebook has succeeded in creating publicity aboutthe use of virtual DOM in front-end development.

The student survey showed that more than 80% of the respondents hadheard about virtual DOM, and 50% rated their knowledge to be good.Several of the students also commented on that they wanted to try outReact and take use of the virtual DOM. The developers interviewed alsomentioned React to be a framework they wanted to take a closer look at,and several of them would like to start using the framework in the future.

The virtual DOM approach was mentioned as a killer feature and wasmainly the reason why they wanted to take use of React, in addition to itssimplicity.

5.8 The future

In this section, the future of web applications and the virtual DOM will bediscussed. This discussion is relevant in answering RQ3.

The introduction of the virtual DOM approach has shown to changethe way web-applications are built. Several of the developers emphasizedthe importance of freedom and control as reasons to why they choseframeworks using KVO. During usage, they found the freedom to bringproblems, as too much responsibility was given to the developer. Theseproblems are to a large extent avoided with the virtual DOM approach,and this is probably one of the reasons why virtual DOM has become sopopular.

The developers have seen the advantages that come from developingUIs at a higher abstraction level, and the usage is increasing rapidly today.Simple development is of increasing importance as the applications aregrowing in complexity. The use of methods to simplify the developmentwill therefore be central in the future application development.

5.8.1 Browser Virtual DOM

It is agreed upon that the virtual DOM is beneficial in applicationdevelopment, but opinions vary on where the virtual DOM should reside.The dirty checking framework Angular was asked about where they standin the choice of taking the virtual DOM approach into use, and they gavean answer that conform well with the interview results.

It is not difficult to understand that Angular needs another renderingapproach, as the dirty checking is giving performance issues, but they don’tseem to think a virtual DOM is the solution. The team stated that they seethe advantages of the virtual DOM, but in their opinion it is something thatshould be taken care of by the browser.[1]

The use of virtual DOM is increasing, and there exist a lot of virtualDOM implementations out there. Instead of each framework having itsown virtual DOM implementation, it would be beneficial to let the browserdo the task. The developers would still benefit from the virtual DOM, andthe frameworks would become simpler.

90

There are also problems linked to a browser virtual DOM. One problemis the additional abstraction layer that will be added in the browser. Insteadof being able to interact with the DOM directly, there will be a level ofabstraction in-between. It is interesting to take a closer look at this topic,but it is too comprehensive to cover in this thesis.

5.8.2 Angular is following

Angular 2.0 is under development, and it is said to be quite different fromthe previous versions. Developers are reluctant to start new, large projectsin Angular, as they don’t know how easy or difficult it is to upgradeto Angular 2.0. They have announced significant improvements to theirchange detection system. They are moving away from the dirty checkingwe know today, and this confirms that dirty checking is a bad choice, asfound in this thesis. The performance results are supposed to be 3 to 10times faster than the one of dirty checking.[43]

At the end of the work with this thesis, Angular announced moredetails about their change detection mechanism to be part of the futureAngular 2. Even though Angular doesn’t want to take use of virtual DOM,their future change detection mechanism have a lot of similarities. Theuse of two-way bindings are supposed to be replaced by a one-directionaldataflow, resulting in a tree-structure similar to the one of virtual DOM.This change also removes the issues with cascading updates that werepresent in dirty checking. These changes confirm that the web applicationdevelopment is going in direction of a component-based structure withone-directional dataflow.[43]

The details about Angular’s new change detection have recently beengiven, and it will take some time until Angular 2 is released. As a resultof this, it is not possible to make any closer comparisons with the virtualDOM at the time of this master thesis, but it is an interesting topic for futurework.

5.8.3 The future web

Virtual DOM has contributed in changing the way web-applications arebuilt. Facebook’s goal is not that everyone should use their frameworkReact, but that the ideas behind the framework are adopted into othersystems and projects.[26] The use of virtual DOM has been found to bebeneficial in today’s applications, and works great as a polyfill for thefuture web, until the web browsers and the web is made more suitableand optimized for web applications.[26]

Web components and its custom elements described in Section 2.5 arebelieved to be of great importance in the future. Whether the virtual DOMwill become redundant or even more important in the future is difficultto say. It has been shown that it is possible to combine virtual DOMwith custom elements, and it will be interesting to see how front-enddevelopment evolves.[41]

It is clear that virtual DOM has become popular in short time, and it will

91

be of great importance until the browsers have gotten common support forweb components in the future. Until then, virtual DOM has contributed inchanging the way web applications are developed and has accelerated thechanges happening in the front-end world.

5.9 Limitations

The topic discussed in this thesis is relatively new on the market and hasonly been subject for discussion the last few years. Consequently, not muchhas been written about the topic yet, and it is therefore difficult to takeuse of research based sources in the thesis. As the amount of researchbased material is small, it has been necessary to take use of other sourcesof information. The developers behind popular frameworks and otherexperienced developers have contributed a lot during the last years. Usefulinformation has been shared through blog posts, articles, speeches andinterviews. The developers want the road towards better solutions to be asshort as possible, and they therefore share benevolent of their knowledgeand experiences gained.

The developers interviewed all belong to the same company, and itmight be possible that the interviewees have been affected by each other’sopinions and hold the same attitude towards the different techniquesand frameworks discussed. However, they are all working on distinctapplications with different characteristics, and therefore experience theframeworks in different contexts.

React is a young framework compared to Backbone and Angular, andit is important to keep in mind that the developers potentially have lessexperience with this framework. Relevant problems that arrive at largescale might not have been detected yet at the time of the interviews, andthe results could have been different if the framework had been used for alonger period of time.

Angular is a large and complex framework, and it is difficult to knowwhether some of the properties are made by choice or if they are a naturalresult of dirty checking. It could affect the simplicity scores to a smalldegree, but the overall conclusion would have been the same.

92

Chapter 6

Conclusion

The virtual DOM has shown to bring improvements in several areas. Table6.1 presents the total amount of points given to each of the techniques.The rating presented in Section 5.1 placed virtual DOM on top and dirty

Table 6.1: Total amount of points given

Dirty checking KVO Virtual DOMPerformance 9 17 15Simplicity 10 11 16Abstraction level 14 8 15Scalability 3 4 8Total 36 40 54

checking last. The same results are found when all points given throughoutthe discussion are summed up. The following sections will be used toconclude the discussion and answer the research questions.

6.1 Research question 1: Performance

Virtual DOM was expected to give good performance results, and theseexpectations were confirmed by the research done. Virtual DOM is a muchbetter alternative than dirty checking. Dirty checking showed to bringserious performance issues when the application data got large, and thetechnique should be avoided in complex applications.

KVO was found to give better performance results, but it requiresmuch more manual work to be done. Virtual DOM provides goodperformance out of the box, while KVO requires the developer to dothe right optimizations manually to obtain the best performance. Goodperformance results almost come for free with virtual DOM, and it istherefore a great choice in most applications.

93

6.2 Research question 2: Problem Areas

Virtual DOM was found to give the overall best results at simplicity,abstraction level and scalability. Both dirty checking and KVO gaveproblems regarding how to use the techniques correctly and uniformly, andthis was not found to be a problem using virtual DOM. The mental modelwas simplified, and the application structure was easier to understand andkeep an overview of.

Virtual DOM allows for the developer to program at a higher level,causing the low-level details of KVO to be of no concern. The abstractionlevel was also found to be more reliable than the one of dirty checking.

The one-directional dataflow is a big improvement over the other twotechniques, as it gets easier to keep track of the data flowing in theapplication. It was found to remove problems regarding cascading updatesand improved testability and bug fixing.

6.3 Research question 3: Impacts

The introduction of the virtual DOM approach has contributed in raisingawareness around the techniques used. The importance of this isincreasing, as the size and complexity of the applications are growing.Virtual DOM has shown that it is not necessary to do everything manuallyto achieve good performance and it has contributed to UI development ata higher abstraction level.

The advantages of one-way dataflow and declarative programminghave been spread in the JavaScript community, and virtual DOM has beentaken into use by several big companies. The introduction of virtual DOMin front-end development has contributed in expanding JavaScript’s usageareas. The approach has been taken into use in new areas, such as nativeapplication development.

Facebook’s position has contributed in making the virtual DOMpopular, but the technique has also shown to bring improvements into UIdevelopment. The virtual DOM has contributed in changing the way front-end development is done. Front-end development is heading in directionof a component based structure at a higher abstraction level. After React’sarrival, several virtual DOM implementations have been created and areunder development. It is possible to combine the virtual DOM with theup-and-coming Web Components, and it will be interesting to see how thiswill evolve and if virtual DOM will be implemented in the browsers in thefuture.

Angular is replacing their dirty checking mechanism with an approachhaving a lot of similarities with virtual DOM. This confirms that dirtychecking should be avoided, and that virtual DOM is a giant leap in theright direction.

94

Chapter 7

Future work

During the work with the thesis, a lot has happened in the area. The usageof virtual DOM has increased and it is now also used for other targets thanthe DOM. Netflix uses it, and it is also possible to create native applicationsusing the technique.

Several topics for further discussion were mentioned throughout thethesis, and the list below presents relevant topics for future work.

• Should the browser have its own virtual DOM implementation?

• In what other areas than web applications would it be beneficial totake use of the virtual DOM technique?

• How does the virtual DOM technique work in developing nativeapplications compared to ordinary native application development?

• Will virtual DOM be redundant and replaced by Web Components inthe future, or will they enrich each other?

• How does the virtual DOM compare to the new change detectionmechanism announced to be part of Angular 2?

95

96

Bibliography

[1] AngularJS. Angular Team Panel. Jan. 2014. URL: https://www.youtube.com/watch?v=srt3OBP2kGc&feature=youtu.be&t=121 (visited on11/05/2015).

[2] AngularJS. Data Binding in Angular Templates. URL: https : / / docs .angularjs.org/guide/databinding (visited on 06/05/2015).

[3] AngularJS. $rootScope.Scope. Mar. 2015. URL: https ://docs.angularjs .org/api/ng/type/$rootScope.Scope (visited on 03/03/2015).

[4] AngularJS. What are Scopes? Jan. 2015. URL: https://docs.angularjs.org/guide/scope (visited on 10/02/2015).

[5] Backbone.js. Backbone.js - Introduction. Feb. 2014. URL: http : / /backbonejs.org/#introduction (visited on 20/01/2015).

[6] Jeff Barczewski. CW 004 : Pete Hunt, Software Engineer for Facebook,discussing Facebook’s open source js UI framework, React. Mar. 2014. URL:http://codewinds.com/podcast/004.html (visited on 28/01/2015).

[7] John Bender, Todd Parker and Scott Jehl. Research: Performance Impactof Popular JavaScript MVC Frameworks. Dec. 2014. URL: http://www.�lamentgroup . com / lab / mv - initial - load - times . html (visited on23/04/2015).

[8] Peter Bright. JavaScript has problems. Do we need Dart to solve them?Oct. 2011. URL: http://arstechnica.com/business/2011/10/javascript-has-problems-can-googles-dart-solve-them/ (visited on 02/05/2015).

[9] Christopher Chedeau. React’s diff algorithm. Dec. 2013. URL: http://calendar.perfplanet.com/2013/di�/ (visited on 19/01/2015).

[10] Jing Chen. Rethinking Web App Development at Facebook. F8 DeveloperConference. May 2014. URL: https ://www.youtube . com/watch?v=nYkdrAPrdcw (visited on 11/05/2015).

[11] Chromium Dashboard. Web Platform Features - Object.observe(). Aug.2014. URL: https://www.chromestatus.com/feature/6147094632988672(visited on 08/01/2015).

[12] Tom Dale. The Road to Ember 2.0. Nov. 2014. URL: https://github.com/emberjs/rfcs/pull/15 (visited on 28/01/2015).

[13] Edsger W Dijkstra. ‘Letters to the editor: go to statement consideredharmful’. In: Communications of the ACM 11.3 (1968), pp. 147–148.

97

[14] ECMA International. Standard ECMA-262 - ECMAScript LanguageSpecification. 5.1. June 2011, pp. 102–152. URL: http : / /www . ecma -international . org / publications / standards /Ecma - 262 . htm (visited on20/05/2015).

[15] Facebook. React Native - A framework for building native apps usingReact. 2015. URL: https : / / facebook . github . io / react - native/ (visitedon 17/05/2015).

[16] Facebook. Sites Using React. Nov. 2014. URL: https : / / github . com/facebook/react/wiki/Sites-Using-React (visited on 28/01/2015).

[17] Facebook. Two-Way Binding Helpers. Oct. 2014. URL: http://facebook.github . io / react / docs / two - way - binding - helpers . html (visited on28/01/2015).

[18] Facebook. Why React? URL: http://facebook.github.io/react/docs/why-react.html (visited on 10/05/2015).

[19] Dirk Fahland et al. ‘Declarative versus imperative process modelinglanguages: The issue of understandability’. In: Enterprise, Business-Process and Information Systems Modeling. Springer, 2009, pp. 353–366.

[20] Finn.no. Ledige stillinger - JavaScript. May 2015. URL: http://www.�nn.no/�nn/job/fulltime/result?sort=0%5C&keyword=JavaScript (visitedon 19/05/2015).

[21] GitHub. Most popular GitHub repositories. Apr. 2015. URL: https : / /github . com/search? l=JavaScript&p=1&q=stars :%3E1&s=stars&type=Repositories (visited on 01/05/2015).

[22] GitHub. Search for JavaScript repositories. May 2015. URL: https : / /github . com / search ? l= JavaScript% 5C&q=JavaScript% 5C& type=Repositories % 5C& utf8 =%C3%A2%C2% 9C%C2% 93 (visited on19/05/2015).

[23] Ilya Grigorik. Critical Rendering Path - Constructing the Object Model.Sept. 2014. URL: https ://developers .google .com/web/fundamentals/performance / critical - rendering - path / constructing - the - object - model(visited on 06/01/2015).

[24] Michael R Harwell. ‘Research design in qualitative/quantita-tive/mixed methods’. In: The Sage handbook for research in education.2nd ed. Los Angeles, CA: Sage (2011), p. 147.

[25] KeeKim Heng. Speeding up JavaScript: Working with the DOM. Aug.2014. URL: https://developers.google.com/speed/articles/javascript-dom(visited on 05/01/2015).

[26] Pete Hunt. Be predictable, not correct - functional DOM programming.Mar. 2014. URL: https://www.youtube.com/watch?v=e7A6EUe3XGM(visited on 11/05/2015).

[27] Pete Hunt. Secrets of the Virtual DOM. JSConf 2014. Feb. 2015. URL:https : / / www . youtube . com /watch ? v= a21b - KDHG - Q (visited on17/05/2015).

98

[28] Tihomir Kit. Improving AngularJS long list rendering performance usingReactJS. June 2014. URL: http : / / mono . software / posts / Improving -AngularJS- long- list- rendering-performance-using-ReactJS/ (visited on06/03/2015).

[29] Eiji Kitamura. Introduction to Custom Elements. Nov. 2014. URL: http://webcomponents.org/articles/introduction-to-custom-elements/ (visitedon 06/05/2015).

[30] Eiji Kitamura. Introduction to Shadow DOM. Oct. 2014. URL: http://webcomponents.org/articles/introduction-to-shadow-dom/ (visited on06/05/2015).

[31] Jordanna Kwok. Netflix likes React. Jan. 2015. URL: http ://techblog .net�ix.com/2015/01/net�ix-likes-react.html (visited on 10/02/2015).

[32] John W Lloyd. ‘Practical advantages of declarative programming’. In:Joint Conference on Declarative Programming, GULP-PRODE. Vol. 94.1994.

[33] Michael S Mikowski and Josh C Powell. Single Page Web Applications.Vol. 1. Manning Publications Co, 2013.

[34] Mozilla Developer Network. Document Object Model (DOM) - Intro-duction. Oct. 2014. URL: https : / / developer . mozilla . org / en - US /docs/Web/API/Document_Object_Model/ Introduction (visited on21/11/2014).

[35] Mozilla Developer Network. Window.requestAnimationFrame(). Aug.2010. URL: https : / / developer .mozilla . org / en - US/docs /Web/API /window/requestAnimationFrame (visited on 03/05/2015).

[36] Mozilla Foundation. Bug 1033841 - land Reactified Loop panel. July2014. URL: https://bugzilla.mozilla.org/show_bug.cgi?id=1033841#c2(visited on 28/01/2015).

[37] Addy Osmani. Data-binding Revolutions with Object.observe(). May2014. URL: http : //www.html5rocks . com/en/ tutorials / es7/observe/(visited on 08/01/2015).

[38] Addy Osmani. Learning JavaScript Design Patterns. O’Reilly Media,2012.

[39] Paul Pichler et al. ‘Imperative versus declarative process modelinglanguages: An empirical investigation’. In: Business Process Manage-ment Workshops. Springer. 2012, pp. 383–394.

[40] Zeno Rocha and Addy Osmani. Why Web Components? Apr. 2013.URL: http : / / webcomponents . org / articles / why - web - components/(visited on 06/05/2015).

[41] Andrew Rota. The complementarity of React and Web Components.React.js Conf 2015. Feb. 2015. URL: https://www.youtube.com/watch?v=g0TD0efcwVg&feature=youtu.be&t=461 (visited on 11/05/2015).

99

[42] Joakim Runeberg et al. To-Do with JavaScript MV*: A study intothe differences between Backbone. js and AngularJS. Arcada-Nylandssvenska yrkeshogskola, 2013. URL: http://www.theseus.�/bitstream/handle/10024/57918/Runeberg_Joakim.pdf (visited on 03/12/2014).

[43] Victor Savkin. Change Detection Reinvented. Mar. 2015. URL: https://www.youtube.com/watch?v=jvKGQSFQf10 (visited on 11/05/2015).

[44] Sam Selvanathan. Isomorphic React Apps with React-Engine. Apr. 2015.URL: https://www.paypal- engineering.com/2015/04/27/isomorphic-react-apps-with-react-engine/ (visited on 01/05/2015).

[45] Amit Singhal and Matt Cutts. Using site speed in web search ranking.Apr. 2010. URL: http://googlewebmastercentral.blogspot.no/2010/04/using-site-speed-in-web-search-ranking.html (visited on 20/05/2015).

[46] StackExchange - Data Explorer. Query: Number of posts about JavaScriptper month. Apr. 2015. URL: http : / / data . stackexchange . com /stackover�ow/query/309163/query-number-of-posts-about- javascript-per-month (visited on 01/05/2015).

[47] StackExchange - Data Explorer. Query: Number of posts about specificframework per month. Apr. 2015. URL: http://data.stackexchange.com/stackover�ow/query/309178/query - number - of - posts - about - speci�c-framework-per-month (visited on 01/05/2015).

[48] StackOverflow. Newest ’javascript’ Questions. May 2015. URL: http :/ / stackover�ow . com / questions / tagged / javascript (visited on19/05/2015).

[49] StackOverflow Careers. “JavaScript” Job Listings. May 2015. URL: http://careers.stackover�ow.com/jobs?searchTerm=JavaScript%5C&type=any%5C&location=%5C&range=20%5C&distanceUnits=Miles (visitedon 19/05/2015).

[50] Jeff Terrace, Stephen R Beard and Naga Praveen Kumar Katta.‘JavaScript in JavaScript (js. js): Sandboxing third-party scripts’. In:USENIX WebApps (2012). URL: https://www.usenix.org/system/�les/conference/webapps12/webapps12-�nal6.pdf (visited on 20/05/2015).

[51] W3C. A Short History of JavaScript. June 2012. URL: https://www.w3.org/community/webed/wiki/A_Short_History_of_JavaScript (visitedon 02/05/2015).

[52] Web Essentials. Bundling. URL: http://vswebessentials.com/features/bundling# (visited on 03/05/2015).

[53] WebPageTest.com. Test results: WebPageTest - Visual Comparison. Nov.2014. URL: http://www.webpagetest .org/video/compare.php?tests=141120_RG_14H8,141120_A7_14H9,141120_NF_14HF (visited on23/04/2015).

100

Appendix A

Source code

The implementations of all test cases are available at GitHub, in thefollowing repository: https://github.com/mgr91/Test-cases

The PhantomJS script used in test case A.2 and the source code oftest case B is given below. There are many similarities between the testcases, and the following implementations provide an insight into how theimplementations are made.

A.1 PhantomJS script

1 var page = require('webpage ').create (),

2 system = require('system '),

3 url = system.args [1];

45 page.onInitialized = function () {

6 page.evaluate(function(domContentLoadedMsg) {

7 document.addEventListener('DOMContentLoaded ', function () {

8 window.callPhantom ();

9 });

10 });

11 };

1213 page.onCallback = function () {

14 // Fetch jQuery for easier selectors

15 page.includeJs('http :// ajax.googleapis.com/ajax/libs/jquery

/1.8.2/ jquery.min.js', function () {

16 // jQuery is loaded , now manipulate the DOM

17 var time = Date.now(),

18 numItems = 1000;

19 // Print out the title of the page

20 var title = page.evaluate(function () {

21 return document.title

22 });

2324 console.log("--- " + title + " ---");

25 //Add elements

26 for (var i=0; i<numItems; i++) {

27 // Adding todo item

28 page.evaluate(function(num) {

29 var input = $('#new -todo');

101

30 input.focus();

31 return true;

32 }, i+1);

33 page.sendEvent("keypress", "todo " + (i+1));

34 page.sendEvent('keypress ', page.event.key.Enter);

3536 // checking todo item

37 page.evaluate(function () {

38 $('#todo -list li').each(function (){

39 $(this).find('input ').click();

40 });

41 return true;

42 });

4344 // delete todo item

45 page.evaluate(function () {

46 $('#todo -list li').each(function (){

47 $(this).find('.destroy ').click();

48 });

49 return true;

50 });

5152 if(i%100 === 0) {

53 console.log((i*100)/numItems , "% done");

54 }

55 };

5657 // Print out total time

58 time = Date.now() - time;

59 console.log('Loading time ' + time + ' msec');

60 console.log('----------------------------------');

61 phantom.exit();

62 });

63 };

6465 page.open(url , function(status) {

6667 });

Listing A.1: PhantomJS script - 1 todo 1000 times

A.2 B: Sortable datatable

A.2.1 React implementation

HTML

1 <!DOCTYPE html >

2 <html >

3 <head >

4 <title >React - sortable datatable </title >

5 </head >

6 <body >

7 <h1>React - sortable datatable </h1 >

8 <div id="app -content" ></div >

910 <script src="http ://fb.me/react -0.12.2. js"></script >

102

11 <script src="http :// code.jquery.com/jquery -1.10.0. min.js"

></script >

12 <script src="sortabledatatable.js"></script >

13 </body >

14 </html >

Listing A.2: Sortable datatable: React - HTML

JavaScript

1 var Element = React.createClass ({ displayName: "Element",

2 render: function () {

3 return React.createElement("div", null , this.props.id , " |

", this.props.value , " | ", this.props.name)

4 }

5 });

67 var ElementList = React.createClass ({ displayName: "ElementList"

,

8 render: function () {

9 this.props.elementsData.sort(function(a, b) {

10 if((b.value) - (a.value) === 0)

11 return a.id - b.id;

12 else

13 return (a.value) - (b.value);

14 });

1516 var elements = [];

17 this.props.elementsData.forEach(function(element) {

18 elements.push(React.createElement("div", {key: "object"+

element.id}, React.createElement(Element , {value:

element.value , id: element.id, name: element.name})))

;

19 });

2021 return React.createElement("div", null , elements);

22 }

23 });

2425 var NUM_ELEMENTS = 1000;

2627 function makeid () {

28 var text = "";

29 var possible = "abcdefghijklmnopqrstuvwxyz";

3031 for( var i=0; i < 5; i++ )

32 text += possible.charAt(Math.floor(Math.random () *

possible.length));

3334 return text;

35 }

3637 elementsDataTable =[];

38 for (var i = 1; i <= NUM_ELEMENTS; i++) {

39 (function(id) {

40 var randomText = makeid ();

41 elementsDataTable[i-1] = {id: id , value: 0, name:

randomText };

42 })(i);

103

43 };

4445 var App = React.createClass ({ displayName: "App",

46 getInitialState: function () {

47 return {elementsData: elementsDataTable };

48 },

49 render: function () {

50 return (

51 React.createElement("div", null ,

52 React.createElement("button", {onClick: this.

changeDataItems}, "Change all items"),

53 React.createElement("button", {onClick: this.

changeRandomDataItem}, "Change one random item"),

54 React.createElement(ElementList , {elementsData: this.

state.elementsData })

55 )

56 );

57 },

58 changeDataItems: function () {

59 dataitems =[];

60 for (var i = 1; i <= NUM_ELEMENTS; i++) {

61 (function(id) {

62 var randomText = makeid ();

63 var randomValue = -Math.floor(Math.random () *1000);

6465 dataitems[i-1] = {id: id , value: randomValue , name:

randomText };

66 })(i);

67 };

68 this.setState ({ elementsData: dataitems });

69 },

70 changeRandomDataItem: function () {

71 var data = this.state.elementsData;

72 var randomIndex = Math.floor(Math.random ()*NUM_ELEMENTS)

% NUM_ELEMENTS;

73 var randomValue = -Math.floor(Math.random () *1000);

7475 data[randomIndex ]. value = randomValue;

76 data[randomIndex ].name = makeid ();

77 this.setState ({ elementsData: data});

78 }

79 });

8081 React.render(React.createElement(App , null), document.

getElementById("app -content"));

Listing A.3: Sortable datatable: React - JavaScript

A.2.2 Angular implementation

HTML

1 <!DOCTYPE html >

2 <html lang="en">

3 <head >

4 <meta charset="utf -8">

5 <title >Angular - sortable datatable </title >

6 <script src="// cdnjs.cloudflare.com/ajax/libs/angular.js

/1.3.15/ angular.min.js" ></script >

104

7 <script type="text/javascript" src="sortabledatatable.js"

></script >

8 </head >

9 <body >

10 <h1>Angular - sortable datatable </h1 >

11 <div id="app -content" ng-app="listElementsApp" ng-

controller="ListElementsCtrl" on-finish -render >

12 <button ng-click="changeDataItems ()">Change all items </button

>

13 <button ng-click="changeRandomDataItem ()">Change one random

item </button >

14 <hr>

15 <div ng-repeat="element in elements| orderBy:['value ','id ']">

16 {{ element.id}} | {{ element.value}} | {{ element.name}}

17 </div >

18 </div >

19 </body >

20 </html >

Listing A.4: Sortable datatable: Angular - HTML

JavaScript

1 var listElementsApp = angular.module('listElementsApp ', []);

2 var NUM_ELEMENTS = 1000;

34 var makeid = function () {

5 var text = "";

6 var possible = "abcdefghijklmnopqrstuvwxyz";

78 for( var i=0; i < 4; i++ )

9 text += possible.charAt(Math.floor(Math.random () * possible

.length));

1011 return text;

12 };

1314 var elementsData =[];

15 for (var i = 1; i <= NUM_ELEMENTS; i++) {

16 (function(id) {

17 var randomText = makeid ();

18 elementsData[i-1] = {id: id, value: 0, name: randomText };

19 })(i);

20 };

2122 listElementsApp.controller('ListElementsCtrl ', function($scope)

{

23 $scope.elements = elementsData;

2425 $scope.changeDataItems = function () {

26 var itemdata =[];

27 for (var i = 1; i <= NUM_ELEMENTS; i++) {

28 (function(id) {

29 var randomValue = Math.floor(Math.random () *1000);

30 var randomText = makeid ();

31 itemdata[i-1] = {id: id , value: -randomValue , name:

randomText };

32 })(i);

33 };

105

34 $scope.elements = itemdata;

35 };

3637 $scope.changeRandomDataItem = function () {

38 var randomIndex = Math.floor(Math.random ()*NUM_ELEMENTS) %

NUM_ELEMENTS;

39 var randomValue = Math.floor(Math.random () *1000);

40 $scope.elements[randomIndex ].value = -randomValue;

41 $scope.elements[randomIndex ].name = makeid ();

42 };

43 });

Listing A.5: Sortable datatable: Angular - JavaScript

A.2.3 Backbone implementation

HTML

1 <!DOCTYPE html >

2 <html >

3 <head >

4 <script src="// cdnjs.cloudflare.com/ajax/libs/jquery /2.1.1/

jquery.min.js"></script >

5 <script src="// cdnjs.cloudflare.com/ajax/libs/underscore.js

/1.7.0/ underscore -min.js"></script >

6 <script src="// cdnjs.cloudflare.com/ajax/libs/backbone.js

/1.1.2/ backbone -min.js"></script >

7 <title >Backbone - sortable datatable </title >

8 </head >

9 <body >

10 <div id="app -content">

11 <h1>Backbone - sortable datatable </h1 >

12 <button class="btnChangeDataItems">Change all items </

button >

13 <button class="btnChangeRandomDataItem">Change one random

item </button >

14 <hr>

15 <div id="item -table"></div >

16 </div >

1718 <script type="text/template" id="item -template">

19 <%= id%> | <%= value %> | <%= name %>

20 </script >

2122 <script type="text/javascript" src="sortabledatatable.js"

></script >

23 </body >

24 </html >

Listing A.6: Sortable datatable: Backbone - HTML

JavaScript

1 (function($) {

2 var Item = Backbone.Model.extend ({

3 });

45 var ItemCollection = Backbone.Collection.extend ({

6 model: Item ,

106

7 comparator: "value",

8 initialize: function () {

9 this.on('change:value', function () { this.sort() }, this)

;

10 this.on('reset', function () { this.sort() }, this);

1112 },

13 changeData: function () {

14 var dataitems = [];

15 for (var i = 0; i <= NUM_ELEMENTS; i++) {

16 var randomValue = -Math.floor(Math.random () *1000);

17 dataitems[i] = {id: i+1, name: makeid (), value:

randomValue };

18 };

19 this.reset(dataitems);

20 },

21 changeRandomData: function () {

22 var randomIndex = Math.floor(Math.random ()*this.size());

23 var randomIndex = Math.floor(Math.random ()*NUM_ELEMENTS)

% NUM_ELEMENTS;

24 var randomValue = -Math.floor(Math.random () *1000);

25 this.at(randomIndex).set({value: randomValue , name:

makeid ()});

26 }

27 });

2829 var ItemView = Backbone.View.extend ({

30 tagName: "div",

31 template: _.template($('#item -template ').html()),

3233 initialize: function () {

34 },

35 render: function () {

36 var data = this.model.toJSON ();

37 $(this.el).html(this.template(data));

38 return this;

39 }

40 })

4142 var AppView = Backbone.View.extend ({

43 el: $("#app -content"),

4445 events: {

46 "click .btnChangeDataItems": "changeData",

47 "click .btnChangeRandomDataItem": "changeRandomData"

48 },

49 initialize: function () {

50 this.collection.bind('sort', this.render , this);

51 this.collection.sort();

5253 },

54 render: function () {

55 $("#item -table").html('');

56 this.collection.each(this.addItem);

57 },

5859 changeData: function(e) {

60 e.preventDefault ();

61 this.collection.changeData ();

107

62 },

63 changeRandomData: function(e) {

64 e.preventDefault ();

65 this.collection.changeRandomData ();

66 },

67 addItem: function(item) {

68 var view = new ItemView ({model: item});

69 $("#item -table").append(view.render ().el);

70 }

71 });

7273 function makeid () {

74 var text = "";

75 var possible = "abcdefghijklmnopqrstuvwxyz";

7677 for( var i=0; i < 5; i++ )

78 text += possible.charAt(Math.floor(Math.random () *

possible.length));

7980 return text;

81 };

8283 var NUM_ELEMENTS = 1000;

84 var itemCollection = new ItemCollection;

85 for (var i = 1; i <= NUM_ELEMENTS; i++) {

86 itemCollection.add({id: i, name: makeid (), value: 0});

87 };

88 var app = new AppView ({ collection: itemCollection });

89 }( jQuery));

Listing A.7: Sortable datatable: Backbone - JavaScript

108

Appendix B

Survey Scheme

109

110

Appendix C

Interview questions

Intervjuobjektet

• Kan du fortelle litt om din erfaring med frontendutvikling og hvilkerammeverk du kjenner til?

Prosjektet

• Hvordan er prosjektet du jobber på nå?

– Varighet, størrelse

– Kompleksiteten til brukergrensesnittet

– Mengde underliggende data, endringer i data

Rammeverk

• Har det blitt brukt andre struktureringsrammeverk på dette prosjek-tet tidligere, hvordan fungerte de?

– Fordeler og ulemper

– Hvorfor ble det byttet ut?

• Hvorfor ble rammeverket valgt?

• Hvilke erfaringer har dere gjort med rammeverket?

– Fordeler og ulemper

– Hvor lett var det å sette seg inn i rammeverket, og er det lett åbruke?

– Oversiktlig kode?

– Hvor lett er det å finne og rette feil?

• Hvilke forskjeller er det fra andre rammeverk du har kjennskap til,og hva er konsekvensene?

– Løser det problemer som oppstod i andre rammeverk?

111

– Oppstår det nye problemer?

• Hva gjør at dette rammeverket vil bli benyttet videre på detteprosjektet, eller på senere prosjekter?

112

Appendix D

Quotations in Norwegian

D.1 Performance

1. “Du kan få et problem hvis du ikke er bevisst på at det dirty checking somskjer.” Page 58

2. “Med virtell DOM får bedre ytelse ut av boksen..” Page 58

D.2 Simplicity

1. “Jeg følte jeg hadde kontroll etter en uke, men nå i ettertid føler jeg at jeg hartatt flere skritt tilbake, og jeg forstår meg ikke helt på Angular. Det gir degveldig mye confidence i starten, for du kan få produsert ganske mye, fort.Men du innser kanskje ikke problemene før etter en periode.” Page 69

2. “Det er endel detaljer du ikke vet om før du har sittet i noen måneder mednoe. Tutorials viser bare hvor det virkelig skinner. ” Page 69

3. “..Backbone er i grunnen trivielt nok når man har forstått MVC-patternet.”Page 70

4. “Det var veldig enkelt å skjønne hvordan React fungerer. Det tok kanskje 3dager, så hadde jeg følelsen av at dette hadde jeg kontroll over. I motsetningtil Angular hvor jeg ikke helt hadde skjønt alle sidene ved etter et helt år vedå jobbe med det.” Page 71

5. “Det er veldig greit å forklare komponentene. Du kan stykke det opp veldignår du skal forklare det til noen. Nå jobber vi bare på den komponenten,og det som skjer inni den. Bare forklare en komponent veldig i detalj, somkanskje jobber mot en annen komponent, og fokusere på de to. Da er detkanskje lettere å forstå helheten i det.” Page 72

6. “Det er ikke noe vanskelig å sette seg inn i React-rammeverket, det er detabsolutt ikke. Der vil jeg nok tro at det er vanskeligere på en måte medAngular-kodebasen, fordi du har så mange forskjellige måter å bruke APIetpå, at det vil skille seg fra prosjekt til prosjekt i stor grad. Page 72

113

7. “Angular er så stort, og man har frihet med ansvar. Det er så mangeforskjellige tools som man kan bruke til å løse problemene, men somnødvendigvis ikke er rette. Så er det at man bruker forskjellige ting iforskjellige prosjekter, bruker enten forskjellige måter - åh, er det sånn duhar gjort det. Så er det vanskelig å onboarde folk” Page 72

8. “Når man da bygger større applikasjoner, får man mer komplekse app-likasjoner, så det kan være litt vanskelig å skille på hva som er rammeverketsin skyld og hva som er kompleksiteten i applikasjonen sin skyld.” Page 73

9. “Vi ser veldig stor forskjell på de som får en god kodegjennomgang og de somikke gjør det.” Page 73

10. “Backbone er ikke flink på å diktere, og det var en av styrkene når det bletatt til vurdering. Du kan gjøre ting på din måte, og fortsatt få mye gratis.”Page 74

11. “Jo viktigere det er for det, og jo mer spesifikt det du lager er for din bransjeeller ditt domene, jo vanskeligere tror jeg det blir å presse det ned i så storerammeverk som Angular, som skal ha kontroll fra A til Å.” Page 74

12. “Det er nok ingen rett måte å gjøre ting på i Angular. Det er et stort API ogdet er mange, mange måter å skru ting sammen på.” Page 75

13. “Uenigheter om hvilke måte man skal bruke rammeverket på. Selv om tomåter kan være riktig, så kan det bli divergering mellom kodestilen, fordiman bruker en teknikk her og en teknikk der. Det er uheldig.” Page 75

14. “[Enveis] dataflyten mye klarere, og det er lettere å skjønne hvor staten bliroppdatert, og hvor det blir sendt videre. At staten representerer viewet100%. Enveisflyt er ganske deilig å forholde seg til. Enveisflyten gjørdet absolutt lettere å holde oversikt over hvordan ting henger sammen iapplikasjonen.” Page 76

D.3 Abstraction level

1. “I Angular måtte man ofte ende opp med at man prøver å putte scopet ellermodellen sin og dytte det ut i HTMLen og se hva som står der, og gjette segtil hvor det ligger. Mens i React kan man nesten sette en breakpoint inne ien rendering component og se akkurat hva du får. Utviklingsmessig er nokReact ganske mange hakk foran Angular der.” Page 78

D.4 Familiarity

1. “[Vi] endte opp med veldig mange felleskomponenter i Angular. Det erveldig store insentiver for å bruke det rammeverket, for du får så mye gratisi økosystemet som vi har bygd opp rundt det.” Page 87

114

D.5 Influence

1. “Jeg syns det er sånn weben burde være. Det er en liten problemstilling,for weben er ikke laget for komponenter sånn egentlig, om man tenker påDOMen. Men det er på vei dit, med shadow DOM som kommer. Jeg ser formeg at man kan lage små widgets som man kan putte inn hvor som helst, ogsom kan være helt uavhengige av hverandre.” Page 88

115