Building User Interfaces Using Virtual DOM

(1)

Building User Interfaces Using Virtual DOM

A comparison against dirty checking and KVO

Marianne Grov

Master’s Thesis Spring 2015

(2)

(3)

Building User Interfaces Using Virtual DOM

Marianne Grov 20th May 2015

(4)

(5)

Abstract

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

Aim: The aim of the thesis is to explore the use of virtual DOM to render application content to the DOM. The method will be compared against the main rendering alternatives of today, dirty checking and key-value-observation (KVO).

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

Method: Performance tests are executed on test cases with different structures and amounts of data. A survey was conducted among students at the Department of Informatics, University of Oslo, to investigate their degree of familiarity with frameworks and rendering methods. Ten experienced developers were interviewed to obtain information about how the techniques function in large-scale projects.

Results: The results show that virtual DOM performs well compared with the two other techniques focused on in this thesis. Dirty checking revealed serious performance issues that are of no concern using virtual DOM. KVO potentially gives the best performance, but at the cost of much more manual work than is required by virtual DOM.

Virtual DOM also improved several of the problem areas found in use of the other techniques.

Conclusion: Virtual DOM showed to simplify application development.

It provides a higher abstraction level than KVO and a more reliable abstraction level than dirty checking. Less details have to be taken care of manually, leaving more focus to the actual functionality being developed.

The virtual DOM approach has changed the perception of how the code beneath user interfaces should be structured. The technique expands the usage areas of JavaScript, and the advantages of one- way dataflow and declarative programming have been spread in the JavaScript community. A lot of projects are replacing the other techniques with the virtual DOM approach.

(6)

(7)

Acknowledgements

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

Thanks to family and friends for being supportive and tolerable. A spe- cial thank to Simen for proofreading and giving useful feedback. Last, but not 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!

(8)

(9)

List of Figures

1.1 JavaScript’s popularity. . . 3

2.1 The DOM tree structure. . . 16

2.2 Object.observe() used in console . . . 18

2.3 Three depths of dirty checking. . . 24

2.4 How Angular interacts with the browser. . . 25

2.5 Data binding in Angular. . . 26

2.6 Virtual DOM: compare trees level by level. . . 29

2.7 Virtual DOM: effect of keys in list comparisons. . . 29

2.8 Virtual DOM: matching components. . . 30

2.9 Virtual DOM: dirty elements. . . 30

2.10 Virtual DOM: selective re-render. . . 31

3.1 The TodoMVC application . . . 38

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

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

4.3 Test case A-D: memory usage . . . 44

4.4 Test case B: render times presented in charts . . . 45

4.5 Test case C: results presented in charts . . . 45

4.6 Test case E: Memory usage. . . 46

4.7 Test case E: render time results . . . 47

4.8 Test case F: initial load time . . . 47

4.9 Survey: framework familiarity in percentage . . . 48

4.10 Survey: degree of knowledge . . . 49

4.11 Survey: difficulty in getting started . . . 49

4.12 Survey: familiarity with underlying concepts . . . 49

4.13 Survey: preferred framework among the students . . . 50

5.1 Shallow and deep tree structure. . . 57

5.2 Visual progress on initial load. . . 59

5.3 Structure of datatable element . . . 62

5.4 Structure of TodoMVC item . . . 62

5.5 The frameworks’ popularity. . . 89

(14)

(15)

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. . . 46

4.2 Survey results specific to the frameworks . . . 51

4.3 Interview results specific to Angular . . . 52

4.4 Interview results specific to Backbone . . . 52

4.5 Interview results specific to React . . . 52

5.1 Rating of central properties of the techniques . . . 54

5.2 Rating of performance properties . . . 55

5.3 Performance in O-notation . . . 56

5.4 List rendering with dirty checking vs virtual DOM. . . 64

5.5 Memory usage in test caseE . . . 66

5.6 Framework size, production version . . . 67

5.7 Rating the simplicity . . . 68

5.8 Rating the abstraction level . . . 77

5.9 Rating the scalability . . . 82

6.1 Total amount of points given . . . 93

(16)

(17)

Listings

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

2.2 Example of the set()-method . . . 21

2.3 Example of event listening . . . 21

2.4 Watch expression in Angular . . . 23

2.5 An example of the $watch() function . . . 27

2.6 An example of the $apply() function . . . 27

A.1 PhantomJS script - 1 todo 1000 times . . . 101

A.2 Sortable datatable: React - HTML . . . 102

A.3 Sortable datatable: React - JavaScript . . . 103

A.4 Sortable datatable: Angular - HTML . . . 104

A.5 Sortable datatable: Angular - JavaScript . . . 105

A.6 Sortable datatable: Backbone - HTML . . . 106

A.7 Sortable datatable: Backbone - JavaScript . . . 106

(18)

(19)

Chapter 1 Introduction

During the last years, a lot has changed when it comes to the web and how we use it. Earlier, the web consisted of static web pages, where the whole page 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 a change in the way web pages are updated. Earlier, the whole page was re-rendered, but today only relevant parts of the page are touched.

An increasing amount of web traffic comes from mobile devices, and today’s applications need to be designed with this in mind. Mobile devices have smaller screens, lower capacity and in general more limitations than the personal computers that have ruled the market until a few years ago.

The applications are getting larger, with more complex user interfaces and underlying data that is constantly changing.

The programming language JavaScript is used to a great extent in development of web applications. One important point is to avoid tying the application data to the DOM. The web was built for documents, and the DOM is therefore not suitable for the applications that are built today.

However, the need for interactive applications is present, and we need solutions for interactivity today.

The APIs offered by the web browsers are both inconsistent and slow. This has contributed to the development and usage of frameworks.

Another reason for the widespread use of frameworks and libraries is found in the language JavaScript itself. Like all programming languages, JavaScript has its drawbacks, and these have made it necessary to take use of third party frameworks and libraries to structure and organize complex application code. Without such frameworks it gets difficult to keep all parts of the application up-to-date and unnecessary dependencies are often found.

The frameworks use different approaches to structure the code and keep the underlying data and the user interface (UI) in sync, and this thesis will focus on the techniques that can be used for this purpose.

One technique that has been introduced newly is the use ofvirtual DOM.

This technique opens for a new way of thinking and can be used as an alternative to the techniques mainly used in today’s well established

(20)

structuring frameworks, namely the techniques called dirty checking and key-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 the real DOM and attempts to provide a DOM better suited for applications.

This thesis explores the use ofvirtual DOMin front-end development and takes a closer look at what it brings. The problems encountered in the other popular techniques, dirty checking and KVO, are discussed, and we look at how the use of virtual DOM addresses these problems, and if new problems occur.

1.1 Motivation

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

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

• 600 vacant positionsrequiring 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 repositorieswith the JavaScript tag at GitHub.com.[22]

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

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

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

(21)

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

1.2 Research Questions

The impression in advance is that virtual DOM brings some nice features and contributes to more efficient application development. The virtual DOM technique is well promoted by Facebook, and it is interesting to take a closer look at it to see if it is as good as it seems. Will the introduction of virtual 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 compare to the performance of dirty checking and KVO?

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

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

1.3 Clarification

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

(22)

Table 1.1: The framework representing each technique Technique Framework example

Dirty checking Angular

KVO Backbone

Virtual DOM React

1.4 Contributions

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

After reading the thesis, the developer should have a deeper understanding of what the consequences of each of the techniques are, and why.

The work performed in this thesis should give a better understanding of the advantages and disadvantages of the virtual DOM approach and make it easier to decide whether or not it is suitable for a specific application.

1.5 Outline

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

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

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

Chapter 5: Discussion contains a discussion of the results in light of the research 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 the discussion.

Chapter 7: Future Work presents suggestions to future work.

(23)

Chapter 2 Background

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

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

• Facebookis using their virtual DOM framework, React, internally for a lot of features. This includes the chat system, which was rewritten to use React.

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

• New York Timestakes use of it for parts of their page.

• The largest bank in Russiais built upon React.

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

• Firefoxis using React internally.[36]

• Netflixannounced the use of React.[31]

• Emberwill adopt the virtual DOM technique in Ember 2.0 to simplify communication between components.[12]

(24)

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

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

The goal of using virtual DOM in front-end development is to simplify the development of complex applications. To better understand why this is needed, we need some background information. The language JavaScript is used to build the applications, and this language has its weaknesses. These weaknesses, together with the characteristics of today’s applications, make it necessary to take use of frameworks and libraries to develop well-structured applications. The most used structuring frameworks are built upon a pattern called MVC, and the techniques dirty checkingandkey-value binding (KVO)are mainly used to handle data changes in the applications and render them in the UI. The rendering path containing the DOM construction is relevant in understanding why re- renders and DOM operations are expensive, and why the virtual DOM can be helpful. Different popular frameworks implement these techniques, and the frameworks Backbone, Angular and React will be used throughout this thesis to represent the techniques. Backbone uses KVO, Angular takes use of dirty checking, while React implements virtual DOM.

This chapter presents how applications have evolved, the language JavaScript and its weaknesses, followed by characterization of today’s applications. To better understand the value of using a virtual DOM, the rendering path and the DOM construction are explained. Variations of the MVC pattern are presented in addition to the techniques dirty checking and KVO, 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 simple static web pages. As the time has passed, the web browser engines have been significantly improved and are now capable of running complex applications.

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

(25)

2.1.1 Basic Web Communication

The communication is done over the HTTP protocol, between aServerand a Client, which usually is a web browser. The server is responsible for serving the web page, while the client’s task is to request the page from the server, and display it to theUser. The following example shows how the 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 requested

source

4. Client:renders the received source into a human readable website The User can continue interacting with the page, causing subsequent HTTP 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 theServer, while the client- side includes everything that is run on the Client. This thesis focuses on the client-side applications, more specifically therendering techniquesused at the client-side.

As mentioned, more work has been put on the client as the performance of the web browsers has increased significantly through the web’s existence. The work done at the client side includes making dynamic and interactive web pages, taking care of temporary storage and communicating with the server. To perform these tasks, client-side languages are used.

The primary language is JavaScript, which is seen as the language of the browser.

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 in the client. SPAs have been used for a long time, with various degree of success. Java applets and Flash were popular SPA platforms, but both required third-party plugins to function. With the increase in JavaScript’s popularity, and the improved browser engines, JavaScript SPAs have taken over. A JavaScript SPA doesn’t require any plugin to be installed, and is the obvious choice today.[33]

Partial re-rendering

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

(26)

page over again. If the web page is large, the web traffic is high, or if the Internet 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 more logic, the need for a full reload has been minimized. More information is stored at the client side, and updates can be made to the web page without having to interact with the server. A SPA minimizes the time spend re-rendering, as the processing is done in the browser instead of communicating with the server. All necessary data is retrieved with one single page load. The client contains the data and business logic necessary to make decisions locally, and it can therefore perform quickly. Only the parts that changed need to be updated, and a full reload of the page is avoided.[33]

2.2 JavaScript

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

2.2.1 History

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

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

2.2.2 Challenges with JavaScript

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

(27)

without any knowledge about it. They have experience from class-based languages and want to take use of these experiences, but there are some fundamental differences. We will now take a look at how JavaScript is structured, 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 executable code must be generated only once for each class and can be used for all instances. In JavaScript, this is more difficult because of the lack of classes.

The overhead of generating this code is often big enough to outweigh the performance improvements it gives, and it’s better to use the slow dictionary lookup in many cases. The JavaScript engine V8 takes use of synthetic hidden classes to avoid this problem, and this adds an extra level of complexity. The lack of classes in the language has also led to many JavaScript libraries containing their own emulation of class-based objects.

By having classes as a part of the language, it would therefore have been easier to develop JavaScript libraries and engines. They would have been easier to use and more efficient.[8]

The lack of modules

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

The application code is usually distributed over many JavaScript files to make it easier to maintain overview of the different functionality. This results in a large amount of HTML requests if the files are requested one by 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 are minified versions of the source files grouped together.[52]

2.2.3 JavaScript Design Patterns

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

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

(28)

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

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

It is important to have knowledge about the different design patterns and what problems they aim to solve, as this will make it easier to choose the right patterns for the applications, and also make it easier to integrate them 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 big amounts of underlying data that is changing. Examples of such applications 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 size and complexity and are heavily using JavaScript. JavaScript is used by almost 90%¹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 large amount of users, and a large amount of underlying data. The data is usually changing, and these changes need to be reflected in the application view. The view is often formed as a list of information, where changes to the underlying data lead to small changes in the list displayed. The user can also trigger data changes by interacting with the application.

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

1Report at w3techs.org, as of March 2015

(29)

• 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 to change

• Evolving applications - new features gets added

These characteristics raise the need for structured application development. With such complex applications bugs occurring are inevitable, and it is important to have an application structure that makes bug detection and correction as easy as possible. As new features are expected to be added later on, it is important to design the applications with this in mind. It must be possible to add new features without making major changes to existing code to get it to work properly.

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

2.3.2 Time to market

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

All in all, the time to market is really important. The shortest time to market wins the consumers and this is where the money lies. To achieve a short time to market, it is important with efficient development and testing.

The application structure is significant here. By having an application structure that simplifies the implementation phase, minimizes the amount of bugs and makes testing easy, it will be much simpler to make the product available quickly.

(30)

2.3.3 Performance

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

Another limiting property of mobile devices is the battery. If CPU cycles are wasted, it results in high battery usage, which must be avoided. The JavaScript applications have become large and highly complex, with a lot of work being performed at the client, causing client-side performance to become an issue. The JavaScript speed in browsers has increased drastically, but the performance is still a problem. There are several common traps that give performance problems, and one of them is DOM access. DOM interaction is slow, as explained in section 2.4, and it should therefore be minimized.

Frame rate

To get an application that is working smoothly, theframe rateis important.

Frame rate is a measurement of number of frames per second (fps). The higher the frame rate is, the smoother the application will look. At the same time, a high frame rate means more processing, as more work needs to be done.

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

2.3.4 Application structure

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

The MV* patterns consist of

MVC - Model-View-Controller

(31)

MVP - Model-View-Presenter MVVM - Model-View-ViewModel

Nowadays, most JavaScript developers are applying these patterns to their project during use of different frameworks that implement variations of the patterns. There exist a lot of widely used frameworks giving support for variations of MV*. These frameworks simplify the developers’ task to create 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 to give a better understanding of the patterns.

2.3.5 MVC pattern

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

Because of the modularization, it is easy to know where changes have to 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 the changes are visual, it means changes have been made to the views. The modularization also makes it easier to write unit tests for business logic, and duplication of code will be avoided. Since the core logic is separated from the user-interfaces, it is possible for developers to work on these parts simultaneously.[38]

MVC can be seen as a variation of three classical design patterns. These are the Observer, the Strategy and the Composite patterns. Depending on implementation, it may also use the Factory and the Template patterns.

Knowledge about these patterns could be useful when working with MVC.[38]

In MVC, the observer pattern is used in the communication between model and views, as a model notifies its observers, or views, when it has changed. Views and controllers communicate differently and use the strategy pattern. Controllers help deciding what views should respond to different user input.[38]

Model

A model contains the data in an application. It doesn’t contain any information about user-interface or how the data is presented, its task is just to manage the data only. The model has observers that are interested in its data, and these observers get notified when a change in the data occurs.

These observers are views, which will be explained shortly. Multiple

(32)

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

Modern MV* frameworks often give the possibility to group models together. This makes it possible for observers to observe the whole group instead of having to observe each individual model instance manually.

This grouping functionality is given through the use of a Collection in Backbone.[38]

View

Views are responsible for the visual representation of data in the application. The view builds a DOM element and maintains it as the models it observes change. The view observes the model, and it will be notified when the model changes. This makes it possible for the view to update itself when changes occur to the data it represents. The view needs to have some utility that handles the rendering of the user interface when changes occur at the model it observes. By using the observer pattern, the model triggers its observers to update by using this utility defined in the view.[38]

Views are the presentation layer of an application, they are the user interfaces and normally display the data in a user friendly way. The users can 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 and the possibility to make changes to the information. If the user changes the data, it needs to be updated in the model where it came from. The view onlydisplaysthe information, it doesn’t decide what to do when the user interacts with it, for instance clicks on an element within the view or changes a value. The task of deciding what should happen when a user clicks an element, or the task of updating the data in the model, must therefore be performed by another component, and thecontrollerdiscussed next is responsible for this.[38]

Controller

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

2.4 The Rendering Path

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

(33)

2.4.1 The DOM

The DOM, the Document Object Model, provides a structured representation of HTML documents. This representation is structured by organizing the elements in the document into a tree, called the DOM tree. The elements of the tree have properties and methods that can be used to modify it, which makes it possible for programs to dynamically access the DOM and 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 the document. JavaScript can be used to access and modify DOM elements.

Most of today’s browsers implement the DOM following the specifications in the W3C DOM standard². There are still some variations between them, but every browser contains some DOM to make it possible to script web pages.

Browser reflows

DOM interactions can make it necessary for the browser to change how the elements are displayed on the screen, and this process is called browser reflow. Browser reflow can be triggered by direct DOM manipulations, changes in the elements’ CSS styles, resizing the browser or changing layout properties like offsetHeight and offsetWidth. Each browser reflow is time consuming, and it is therefore important to minimize the need 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 with the DOM. The DOM interactions can be done in different ways, and there is no single method that is the correct one. However, it is not indifferent how the interactions are carried out, as it can affect the performance of the application. Some patterns can be followed to reduce the amount of reflows triggered in the browsers, and the key behind them all is minimizing the amount of DOM access. [25]

2.4.2 Browser rendering

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

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

(34)

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

DOM construction

The browser reads raw HTML bytes received, and converts them into objects with properties and given rules.³ HTML markup defines how different tags are related, and this makes it possible to arrange the created objects in a tree-structure that captures the relationships in the original HTML markup, as shown in Figure 2.1. The result of this process is the DOM, which is used in all further processing of the page.[23]

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

CSSOM construction

The HTML markup used to construct the DOM can also contain CSS style sheets that the browser needs to be able to render the page. In the same way as with the DOM construction, the browser creates a tree structure. It provides a set of default styles to be used where no custom CSS styles have been provided and these are also part of the tree. The tree created is the CSSOM.

Render-tree construction

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

For each of the visible nodes, the browser uses the CSSOM to find matching style rules and adds them. The render tree constructed now contains 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.

(35)

Layout and paint

Now that the render tree is created, the browser needs to decide what the layout should look like. The layout step is also referred to asreflow.

The browser needs to calculate the exact size and position of the elements in the render tree. Once again, the browser starts from the root node in the render tree and traverses it to calculate the size and position of each element. When this information is computed, everything is ready to start the painting step. In the painting step, each node in the render tree is transformed to pixels on the screen.

Time consuming

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

2.5 Change detection

Data often changes and it is necessary to keep track of the changes to be able to perform the actions that should be done due to the changes.

When developing JavaScript applications, it is desirable to detect changes instantly after their occurrence. This might be addition, deletion or changes made to raw JavaScript objects, properties or arrays. There are several approaches 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. To keep the DOM up-to-date and reflect the data, information needs to be sent between the data models and user-interfaces. Doing this manually requires a lot of repetitive code which increases the complexity of the application and is time consuming. This is where frameworks that handle data-binding are useful.

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

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

(36)

1 \\ creating empty person object 2 var person = {};

3

4 \\ observing the person object

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

7 \\ 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. Some browsers already support it, like Chrome 36 stable.[11] Object.observe()’s task is to observe changes on JavaScript objects asynchronously. This makes it possible to implement two-way data-binding without the need for any additional framework or library. The example in listing 2.1 shows how the method is used.

In this example, the empty objectpersonis created. Next, the method Object.observe() is used to observe the object. Information will be written to 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 message containing change name, type and old value is printed in the console.

When a nonexistent property is added, the change type is add, while it is update when an existing value is changed. If an observed element is deleted, the change type is delete. To stop observing an object, Object.unobserveis used;Object.unobserve(person, observer;).[37]

(37)

2.5.3 Web Components

Web Components are a set of four W3C specifications, and the standards are developed by Google. The standards are supposed to part of the web browsers, but for now it is under development and only supported by some of the newest browser versions. Web Components promise encapsulation, composability and reusability with HTML elements, and the goal is to bring component-based development into the World Wide Web. These specifications provide new features that don’t already exist in HTML natively, without the need for any additional libraries or frameworks.

Because the API is the web platform itself, the Web Components are portable.[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 dynamic content

HTML Imports makes it possible to import and use HTML documents as part 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 own HTML tags and use them natively in their HTML. These custom elements enables for easier component reuse, as they doesn’t require any specific framework or library to be used. The custom elements are supported natively in the browser.[29]

Shadow DOM

Shadow DOM gives the ability to create a shadow root underneath a DOM element, which can possibly be a custom element. The shadow DOM is a hidden node tree underneath the element and opens for style and DOM scoping. Other DOM nodes and style tags can be put in this tree, and it will not affect parent elements outside the tree. In the same way, styles defined outside 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. The Object.observe() method is not fully available yet, and it is necessary to take use of other techniques to detect changes. Techniques used to achieve this today arekey-value observation,dirty checking, and the newcomervirtual DOM. These techniques will be explored in the following sections.

(38)

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 change events and change listeners to detect changes and do the necessary updates. The observer pattern and the similar Publish/Subscribe pattern are important here.

2.6.1 The Observer Pattern

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

This pattern may lead to unwanted dependencies between the subject and the observers, and there is another similar pattern that can be used to avoid these dependencies. This pattern is the Publish/Subscribe pattern.

A topic/event channel is used between the object firing events and the objects that want to receive notifications. This pattern is used widely in communication between components in different structuring frameworks, like Backbone. These patterns are useful in the case when we need consistency 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 by extending classes provided by a framework. The plain JavaScript objects with the actual data are contained in objects predefined by the framework.

These container objects have methods to access the data in the objects. A get() method is used to get the data, whileset() is used to change the data.

The use of accessors makes it possible to keep track of the changes at the time they happen and inform the view about what has changed. The information about changes is given by use of the observer pattern described above. 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 to know about the change. When the method gets executed, the data changes are performed, and relevant events are triggered. These events are the change event in addition to change:attribute for each of the changed attributes. In Listing 2.2, we assume the model Person is instantiated, and the attributes name, age and address are set. The name and age attributes of the modelpersonis changed. This causes the events"event",

"event:name"and"event:age"to be triggered.

(39)

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

2

3 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 Description

add a model gets added to a collection remove a model gets removed from a collection change an attribute of the model changes sort the collection has been resorted

reset 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 get the required attribute from within the container object. The reason why the attributes are not accessed directly is the need for change detection made possible by these accessors.

Event listening

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

Objects interested in getting notified of changes can listen to the events fired. A callback function is registered to the events of interest. Each event contains an array with the bound callback functions. When an event gets triggered, the callback functions bound to the event gets fired. It is also possible to stop listening for further changes. The callback function will then be removed from the event’s list of bound callbacks.

In Listing 2.3,viewis listening to name changes, whileview2is listening to all changes onperson. This means that the callback functionview.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

(40)

2.6.3 Dataflow

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

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

2.7 Dirty checking

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

The dirty check is done through the execution of a digest or change cycle. The dirty check needs to be done whenever it is possible that a data change might have happened, for instance on user interaction. The check cycle is costly, as it needs to traverse all the watched data and compare it to the previous version of the data, and it is therefore important to only execute 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 look for changes, whenever something might have changed, and ordinary JavaScript objects can therefore be used.

Angular is the most popular framework using dirty checking, and this framework will therefore be used in the explanation of how dirty checking works. All data elements within Angular’s concept of a scope will be watched 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 digest cycle is executed, it loops through all the data elements within the scope, and compare them to their previous values. Angular’s$applymethod is used to signal a possible data change. The execution of the$applymethod starts a digest cycle, where the dirty checking is performed.[4]

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

(41)

1 $scope . name = 'James ';

2

3 $scope . $watch ( function() { 4 return $scope . name ; 5 }, printChange );

6

7 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 is detected. The advantage with this approach is that the delay gathers up several changes into one watch notification.[4]

2.7.1 Listeners

When the dirty check has finished and one or more changes have been detected, the listeners, also called watchers, will be notified. The listeners register a listener callback to the expression that it wants to observe.

Angular uses the$watchfunction, as shown in Listing 2.4. TheprintChange

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

The listener can possibly change the model, which again causes other listeners to be fired. This is solved by rerunning the comparisons of the watched expressions until no changes are detected. Angular has limited the 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 the browser’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 JavaScript context.

Angular adds an Angular context within the JavaScript context. Only functions executed in the Angular context will take use of the framework’s functionality. It is possible to enter this context through use of Angular’s

$applyfunction. The callback most probably changes the application state, and the digest loop is entered. When the digest loop has finished, the execution leaves the Angular and JavaScript context. The callback may result in DOM modifications, and the browser re-renders the DOM to reflect these changes.[4]

(42)

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 the algorithm is efficient. The dirty checking should not interact with or access the DOM, as DOM operations are much slower than accessing properties on plain JavaScript objects. There are three strategies that can be used to perform the dirty checking. They are different in how deep they look for changes and therefore perform differently. The three strategies are described by [4] in the following way:

Watching by reference is the most efficient strategy. A change is only detected if the whole value is replaced by a new value. In other words, the value’s reference must be changed for a change to be detected. If the watched value is an object or array, changes to the values within the object or array will not be detected. Because no deep comparison is performed, this is an efficient strategy. As shown in Figure 2.3 underBy Reference, the change will only be detected if the reference is replaced.

Watching collection contents goes one step deeper and detects changes within an object or array, in addition to reference change. This detection covers addition, deletion or reordering of the elements within the watched object, but not changes inside these objects. An example is shown inBy Collection Items in Figure 2.3 This strategy doesn’t perform as well as the previous method, because copies of the collection content must be maintained.

(43)

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

Watching by value detects any change that happens within the watched element. This strategy is the most powerful, but also the most performance demanding. In every digest cycle, all nested data structures must be fully traversed, and a full copy of the data needs to be kept in memory. An example of how it works is shown in Figure 2.3.

2.7.4 Dataflow

The dirty checking approach gives a two-way data binding. When a watched element is changed in the DOM, it is detected by the dirty checking algorithm and is reflected in the model. The same holds the other way 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 in the 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 figure 2.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.

Building User Interfaces Using Virtual DOM

Building User Interfaces Using Virtual DOM

A comparison against dirty checking and KVO

Marianne Grov

Master’s Thesis Spring 2015

Building User Interfaces Using Virtual DOM

Abstract

Acknowledgements

Contents

List of Figures

List of Tables

Listings

Chapter 1

Introduction

1.1 Motivation

1.2 Research Questions

1.3 Clarification

1.4 Contributions

1.5 Outline

Chapter 2

Background

2.1 From static web pages to dynamic applications

2.2 JavaScript

2.3 JavaScript Applications Today

2.4 The Rendering Path

2.5 Change detection

2.6 Key-Value Observation

2.7 Dirty checking