JAVASCRIPT DOM MANIPULATION PERFORMANCE - COMPARING VANILLA JAVASCRIPT AND LEADING JAVASCRIPT FRONT-END FRAMEWORKS MORGAN PERSSON - DIVA PORTAL
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
JavaScript DOM Manipulation
Performance
Comparing Vanilla JavaScript and Leading JavaScript
Front-end Frameworks
Morgan Persson
28/05/2020
Faculty of Computing, Blekinge Institute of Technology, 371 79 Karlskrona, Sweden
This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the bachelor’s degree in software engineering. The thesis is equivalent to 10 weeks of full-time studies. Contact Information: Author(s): Morgan Persson E-mail: mope18@student.bth.se University advisor: Emil Folino Department of Computer Science Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE–371 79 Karlskrona, Sweden Fax : +46 455 38 50 57
Abstract Background. Websites of 2020 are often feature rich and highly interactive ap- plications. JavaScript is a popular programming language for the web, with many frameworks available. A common denominator for highly interactive web applica- tions is the need for efficient methods of manipulating the Document Object Model to enable a solid user experience. Objectives. This study compares Vanilla JavaScript and the JavaScript frameworks Angular, React and Vue.js in regards to DOM performance, DOM manipulation methodology and application size. Methods. A literature study was conducted to compare the DOM manipulation methodologies of Vanilla JavaScript and the selected frameworks. An experiment was conducted where test applications was created using Vanilla JavaScript and the selected frameworks. These applications were used as base for comparing applica- tion size and for comparison tests of DOM performance related metrics using Google Chrome and Firefox. Results. In regards to DOM manipulation methodology, there is a distinct difference between Vanilla JavaScript and the selected frameworks. In Vanilla JavaScript DOM manipulation is handled by direct interaction with the DOM interface. When using the selected frameworks the actual interaction with the DOM interface is abstracted away from the developer and handled by the framework. While React and Vue.js both have implemented a Virtual DOM to optimize DOM interactions, Angular has implemented Incremental DOM. Vanilla JavaScript had the best DOM performance in all tests and the smallest application size. Amongst the frameworks React had the best DOM performance, Angular performed close to React in nearly all test, and Vue.js was slightly slower in most tests. In nearly all tests the applications performed better in Google Chrome. Conclusions. Vanilla JavaScript and the selected frameworks, and thereby their DOM manipulation methodologies, are all feasible alternatives for creating inter- active web applications with high DOM performance. Tests indicate that Vanilla JavaScript and the selected frameworks achieves better DOM performance in Google Chrome compared to Firefox. Keywords: JavaScript, Framework, DOM performance
Contents
Abstract i
1 Introduction 1
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 3
2.1 Document Object Model . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 CSS Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Rendering the HTML document in the Browser . . . . . . . . . . . . 5
2.3.1 First render . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Repaint and reflow . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Vanilla JavaScript and the selected frameworks . . . . . . . . . . . . 7
2.4.1 Vanilla JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.2 Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.3 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4.4 Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Research Questions 9
3.1 RQ 1: How does the DOM manipulation methodology of Vanilla
JavaScript and the selected frameworks compare? . . . . . . . . . . . 9
3.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 RQ 2: How does initial page rendering time of Vanilla JavaScript and
the frameworks compare using Google Chrome and Firefox? . . . . . 9
3.2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 RQ 3: How does Vanilla JavaScript and the frameworks compare when
it comes to DOM manipulation performance using Google Chrome and
Firefox? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 RQ 4: How does Vanilla JavaScript and the frameworks compare when
it comes to application size? . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 11
ii
4 Method 12
4.1 Literature Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Empirical Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Experiment design . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3 Test script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Test applications . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.5 Deployment of test script and test applications . . . . . . . . . 16
5 Results 17
5.1 DOM manipulation methodology comparison . . . . . . . . . . . . . . 17
5.1.1 Virtual DOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.2 Incremental DOM . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Performance comparison . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1 Initial page render . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.2 Create 10000 elements . . . . . . . . . . . . . . . . . . . . . . 20
5.2.3 Update all elements . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2.4 Update every other element . . . . . . . . . . . . . . . . . . . 24
5.2.5 Delete all elements . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 Application size comparison . . . . . . . . . . . . . . . . . . . . . . . 28
6 Analysis and Discussion 31
6.1 RQ 1: How does the DOM manipulation methodology of Vanilla
JavaScript and the selected frameworks compare? . . . . . . . . . . . 31
6.2 RQ 2: How does initial page rendering time of Vanilla JavaScript and
the frameworks compare using Google Chrome and Firefox? . . . . . 32
6.3 RQ 3: How does Vanilla JavaScript and the frameworks compare when
it comes to DOM manipulation performance using Google Chrome and
Firefox? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4 RQ 4: How does Vanilla JavaScript and the frameworks compare when
it comes to application size? . . . . . . . . . . . . . . . . . . . . . . . 36
6.5 Results seen from a sustainability and societal perspective . . . . . . 37
7 Validity Threats 38
8 Conclusion 39
9 Future Work 40
References 41
A Empirical study links 47
iii
Chapter 1
Introduction
Since its inception in 1995 JavaScript has evolved into one of the fundamental pro-
gramming languages for the Web [68, 18]. With the rise in JavaScript usage and
popularity the language has gained traction in open-source communities, leading to
an abundance of open-source libraries and frameworks being developed over the years
[18]. The pace of evolution is high in the current JavaScript framework landscape,
where existing frameworks are rapidly evolving and at the same time new frameworks
see the light of day each year [2].
For many years the average web page size has increased from year to year [9]. Size
increases as websites get more feature rich and interactive. At the same time, per-
formance is key to deliver a satisfactory user experience, both in regards of a fast
initial page load time as well as timely responding to user interactions with as low
perceived waiting time as possible [70]. For a website the Page Load Time metric is
critical for several reasons. It has a direct impact on user experience [39] and Google
statistics shows that 53% of users accessing a website from a mobile device leaves a
page that takes longer than three seconds to load [3]. Google has acknowledged that
site speed is a parameter in their search ranking algorithms [37, 71]. A significant
part of the Page Load Time is the Page Render Time, measuring the amount of time
a page render took in the Internet browser [16].
Internet usage has rapidly increased ever since the early 1990s [7], and now more
than half of the world population is online [11, 61]. At the same time the Inter-
nets environmental impact has increased, and the Internet now is on par with the
aviation industry when it comes to CO2 footprint [44, 59]. The share of global elec-
tricity usage that can be ascribed to communication technology is expected to reach
21% by year 2030 [1]. As web page sizes increase the metrics Page Load Time and
Page Render Time has a larger impact on energy usage on the client side. It also
contributes to the digital divide as users with poor internet connection speed might
experience problems using the web site and using low-performing or outdated hard-
ware can amplify this effect.
With the rapid evolution taking place in the JavaScript front-end framework land-
scape comparisons tend to get outdated quickly, and although several JavaScript
front-end framework comparisons exists [19] [55], many of them are outdated and
does not compare the combination of frameworks and areas for comparison as this
study.
1
1.1 Scope
This study compares DOM performance in Vanilla JavaScript and a selection of
front-end frameworks using the browsers Google Chrome and Firefox.
IEEE Standard 610[24] defines performance as “The degree to which a system or
component accomplishes its designated functions within given constraints, such as
speed, accuracy, or memory usage.”. The performance metrics compared in this the-
sis are all directly related to speed.
This study compares Vanilla JavaScript and the following front-end frameworks:
• vue.js
• React
• Angular
Comparing other aspects is out of scope of this study, but comparing several other
aspects such as functionality, learnability, maintainability and more are important
when selecting a JavaScript front-end framework.
The frameworks selected are the three most loved and wanted JavaScript front-end
frameworks on the market according to Stack Overflow Developer survey 2019 [56].
The selection of Google Chrome and Firefox was based on their positions as the 2
most popular desktop web browsers[38].
1.2 Purpose
The purpose of this study is to contribute with insights regarding DOM manipula-
tion methodology and performance for Vanilla JavaScript and the selected frame-
works. Comparing DOM performance in vanilla JavaScript and a selection of front-
end frameworks using different Internet browsers will contribute with insights that
are especially valuable to organisations operating content-heavy websites where the
content is dynamically rendered and updated. It will also contribute to end-users as
the comparison extends to using different Internet browsers.
2Chapter 2
Background
2.1 Document Object Model
A key enabler of interactive websites is the Document Object Model (DOM). The
DOM is an API for HTML and XML documents [14, 48]. Conceptually the DOM
can be represented as a tree. The DOM tree consists of nodes and objects, origi-
nating from the root node (the document itself) child nodes branch out to form the
structure of the document. The nodes have properties and methods which allows
for manipulation of the nodes themselves. Using the DOM programmers can create
documents, navigate the documents hierarchy, and modify the content of the docu-
ment by adding, removing or updating nodes and content. These modifications can
be done using a scripting language such as JavaScript.
(a) HTML document (b) DOM tree
Figure 2.1: Example HTML document represented as a Document Object Model
tree
Figure 2.1 depicts how a HTML document can be represented as a Document Object
Model tree. The root element of a HTML document is the HTML element. In the
example in figure 2.1 the HTML element has 2 children, head and body which in
their turns have child elements. For client-side rendered JavaScript applications the
common approach is to provide the browser with a bare-bones HTML document
3with linked JavaScript file/s which handles the rendering of the complete application
using the DOM API.
2.2 CSS Object Model
The CSS Object Model is a programming interface for CSS [13] allowing programmers
to read and modify CSS styles using JavaScript. The CSS Object Model is created
when the browser has finished constructing the Document Object Model. It then
parses CSS from all the sources related to the document and creates the CSS Object
Model. The CSSOM and DOM are separate data models and are parsed separately,
but they share a similar tree-like structures and the purpose of both models is to
enable the browser to compute the layout of the document. A document can have
multiple CSS sources, and there are multiple types of sources. Examples of different
types of sources include CSS embedded in the document using the tag,
CSS specified inline on the HTML element, or external sources linked to the HTML
document. If a document does not have any CSS sources it will be rendered using
only the browsers default styles, called user-agent styles. Any CSS styles defined in
a documents CSS sources will override the browsers default styles.
(a) HTML document (b) CSS document
Figure 2.2: Example HTML document linked to a CSS style document
In figure 2.2a a stylesheet link to an external CSS file is added to the example HTML
document. Figure 2.2b shows the content of the linked CSS file, which apply styles
to body, h1 and p elements.
4Figure 2.3: Documents in figure 2.2 represented as a CSSOM tree
Figure 2.3 depicts how the CSS rules defined in the example in figure 2.2 are modeled
into a CSSOM tree. The figure shows how children elements inherit some CSS
properties from its parents. Inherited styles are marked with blue text in the figure.
2.3 Rendering the HTML document in the Browser
2.3.1 First render
In order to render a HTML document the browser goes through a multi-step process
[22, 23, 53]:
1. The HTML document is downloaded from the server and parsed into the DOM.
2. External CSS sources referenced in the HTML document are downloaded and
are together with styles defined in the HTML document parsed into the CS-
SOM.
3. The DOM and CSSOM are combined into a rendering tree, containing only the
nodes required to render the page.
4. Layout (also referred to as reflow) stage computes the size and position for each
of the visible elements in the HTML document.
5. The browser paints the HTML page and the result is displayed in the browser.
5(a) Page rendered without de- (b) Page rendered with the
fined styles example CSS file
Figure 2.4: Documents in figure 2.1 and 2.2 rendered in Chrome web browser
Figure 2.4 shows the example HTML document rendered in Chrome both without
defined CSS styles (a), and with the example CSS file (b).
2.3.2 Repaint and reflow
After the initial page render has completed the rendering process, or parts of it, will
be redone upon a user or script interactions with the page Depending on the type
of interaction, i.e. depending on what has changed on the page, one of the two sub
rendering processes referred to as repaint and reflow will happen.
A repaint happens when an interaction leads to element style changes where the
elements position is unaffected. As the name suggests, a repaint paints the element
in the browser window according to the updated style changes. Examples of changes
resulting in repaint of an element is changes to an elements visibility, background
and color.
A reflow is triggered when changes affects the layout of the page, i.e when one or
more elements has changed position on the page. The reflow process recalculates the
position and size of all elements. As reflow is a user-blocking operation developers
aim to minimize reflow processing time and occurrences [54].
Example of changes that triggers a reflow:
• DOM manipulation such as adding, updating and deleting elements
• Updating elements CSS class attribute
• Browser window resizing and scrolling
62.4 Vanilla JavaScript and the selected frameworks
In this study Vanilla JavaScript is compared to a selection of JavaScript frame-
works in regards to DOM manipulation performance and application size. There are
a multitude of JavaScript frameworks available on the market, and for this study
the selected frameworks are the three most loved and wanted JavaScript front-end
frameworks according to Stack Overflow Developer survey 2019 [56].
2.4.1 Vanilla JavaScript
JavaScript is a programming language that was first released in 1995. It was originally
used in front-end development to bring interactivity to web sites, and while that is
still the most common use of JavaScript it has in recent years also been possible to use
JavaScript on the back-end. This thesis focus exclusively on client-side JavaScript,
that is executed in the browser on the client. JavaScript conforms to ECMA Inter-
nationals standard ECMA-262[35] commonly referred to as ECMAScript. In thesis
Vanilla JavaScript is defined as standard JavaScript without any external libraries
or frameworks.
2.4.2 Angular
Angular as a framework has been around the longest of the compared frameworks,
with the initial release of AngularJS taking place in 2010. Since then the framework
has evolved significantly, and a complete re-write of the framework was launched 2016
referred to as Angular2 or just Angular. The framework is developed and maintained
by Google who themselves uses Angular in web applications like Google Cloud Plat-
form and AdWords.
On the Angular page on Googles Open Source website the framework is described
with the following words [20]:
"Angular is a development platform that aims to make web development feel ef-
fortless, focused on developer productivity, speed and testability. Applications built
with Angular can be deployed to mobile devices and desktops as websites and native
applications."
2.4.3 React
React was initially released as an open-source project in 2013 by Facebook, who
originally developed it and continues to maintain it with the support of the React
community. Out of the three selected frameworks React is considered the most loved
by stackoverflow.com users [56]. React has a strong footprint among tech enterprises
with companies such as Uber, Netflix, Reddit and Paypal all using the framework.
On the React GitHub page the frameworks is described with the following words
[46]:
7"React is a JavaScript library for building user interfaces.
Declarative: React makes it painless to create interactive UIs. Design simple views
for each state in your application, and React will efficiently update and render just
the right components when your data changes. Declarative views make your code
more predictable, simpler to understand, and easier to debug.
Component-Based: Build encapsulated components that manage their own state,
then compose them to make complex UIs. Since component logic is written in
JavaScript instead of templates, you can easily pass rich data through your app
and keep state out of the DOM.
Learn Once, Write Anywhere: We don’t make assumptions about the rest of your
technology stack, so you can develop new features in React without rewriting existing
code. React can also render on the server using Node and power mobile apps using
React Native."
2.4.4 Vue.js
Vue.js is an open-source project that was initially released in February 2014. It was
created by Evan You, who is still active in the team maintaining the framework.
Unlike React and Angular, Vue.js is not backed by a large company and instead re-
lies on crowdfunding via Patreon. According to 2019 JavaScript Rising Stars report,
which tracks the number of stars added on GitHub for amongst other the selected
frameworks, Vue.js got more than 31400 stars added during 2019 which is more than
any other front-end framework [52].
On the Vue.js GitHub page the frameworks is described with the following words
[62]: "Vue (pronounced /vju:/, like view) is a progressive framework for building
user interfaces. It is designed from the ground up to be incrementally adoptable,
and can easily scale between a library and a framework depending on different use
cases. It consists of an approachable core library that focuses on the view layer only,
and an ecosystem of supporting libraries that helps you tackle complexity in large
Single-Page Applications."
8Chapter 3
Research Questions
3.1 RQ 1: How does the DOM manipulation method-
ology of Vanilla JavaScript and the selected frame-
works compare?
3.1.1 Motivation
For client-side JavaScript applications DOM manipulation is a key ability that en-
ables dynamic manipulation of HTML and CSS resources. However, DOM manipu-
lation is expensive and the performance cost can potentially have a negative impact
on the user experience. DOM manipulation is central to all the selected frameworks,
but the frameworks have taken different approaches to implementing DOM manipu-
lation. Providing an answer to this questions can give insights to better understand
any differences in DOM manipulation performance.
3.1.2 Expected Outcome
The author expects that Vanilla JavaScript and the frameworks all offer efficient
methods of manipulating the DOM. Furthermore Vanilla JavaScript and the frame-
works are expected to have taken different approaches when it comes to DOM ma-
nipulation methodology.
3.2 RQ 2: How does initial page rendering time of
Vanilla JavaScript and the frameworks compare
using Google Chrome and Firefox?
3.2.1 Motivation
The initial Page Load Time [16] has a significant impact on the users likeliness to
abandon the site in search of faster alternatives [3]. Page Rendering Time is a part
of the Page Load Time metric and measures the time taken to render the page in
the browser. Answering this question will provide insights regarding how Vanilla
JavaScript and the selected frameworks compares when it comes to Page Render
Time, and potential differences in results using Google Chrome and Firefox.
93.2.2 Expected Outcome
The author’s expectation is that Vanilla JavaScript will achieve lower initial page ren-
dering times mainly because of its expected smaller application size. Regarding the
frameworks the expectation is that they all will achieve low initial page render times
at similar levels. The browsers are expected to show a similar level of performance.
3.3 RQ 3: How does Vanilla JavaScript and the
frameworks compare when it comes to DOM
manipulation performance using Google Chrome
and Firefox?
3.3.1 Motivation
Modern client-side web applications are often content-rich and highly interactive with
a common dependency to efficient DOM manipulation. DOM manipulations include
creating, updating and deleting DOM elements and by answering this question in-
sights into how Vanilla JavaScript and the selected frameworks compares in this area
is provided.
3.3.2 Expected Outcome
The author’s expectation is that Vanilla JavaScript will have better DOM perfor-
mance than the frameworks. Regarding the frameworks the expectation is that all
will exhibit a high level of DOM performance, and the frameworks DOM perfor-
mance levels will be similar with no framework performing better than the others in
all tests. The browsers are expected to show a similar level of performance.
3.4 RQ 4: How does Vanilla JavaScript and the
frameworks compare when it comes to applica-
tion size?
3.4.1 Motivation
Application size is one parameter impacting performance. As application size in-
creases so does the time needed for network transfer and processing on the client
side, especially for users with poor internet connection speeds. A framework adds
payload size to the application, and by answering this question insights into how
the minimum additional payload size compares between the selected frameworks and
Vanilla JavaScript is gained.
103.4.2 Expected Outcome
The author’s expectation is that Vanilla JavaScript will have a significantly smaller
application size than the frameworks. Amongst the frameworks the expectation is
that they will achieve similar applications sizes.
11Chapter 4
Method
4.1 Literature Study
To answer RQ1 a literature study is conducted focusing on how DOM management is
handled by Vanilla JavaScript and the selected frameworks. Furthermore information
on how to create applications using the technologies are collected. The literature
study collects information mainly from official websites [47, 65, 6, 15, 22, 66, 14],
well-known and trusted websites and web developer communities on the Internet
[58, 57, 36] and from results found searching BTH Summon using combinations of
the following search terms:
• JavaScript
• Document Object Model
• JavaScript Framework Comparison
• JavaScript Framework DOM
• JavaScript Framework Performance
• JavaScript Framework Rendering
4.2 Empirical Study
RQ2, RQ3 and RQ4 is answered by conducting an experiment.
4.2.1 Experiment design
In the experiment an identical web application is created using Vanilla JavaScript
[15], vue.js [65], React [47] and Angular [6]. These applications are used as basis for
performing a number of comparative test cases in pursuit of answers to the research
questions. The test suite is run by a test script written in Python and uses Selenium
[51] and webdrivers for Chrome [8] and Gecko [12] to emulate Google Chrome and
Firefox browsers. Each test case is performed 100 times per browser.
The experiment has been designed with reproducibility in focus. To ensure a high
degree of reproducibility the following steps is taken:
12• Test process is fully automated, which increases reproducibility and allows for
significant number of test iterations to be performed and it reduces the risk of
manual errors.
• Build versions of the test applications is containerized using Docker [28], and
the images is published on Docker Hub available for anyone to use.
• Test applications are deployed as Docker containers to a standard Amazon Web
Services EC2 [25] instance that is used as Docker host.
• Test script is deployed to and run from a standard Amazon Web Services EC2
[25] instance that has network access to the EC2 instance running the test
applications.
• All application repositories and the test script is made publicly available on
GitHub [32].
4.2.2 Test cases
In order to provide answers to RQ2 and RQ3 a number of test cases is performed.
1. Initial page render time
2. Create 10000 elements
3. Update all elements
4. Update every other element
5. Delete all elements
To answer RQ4 "How does Vanilla JavaScript and the frameworks compare when it
comes to application size?", a size comparison of the test applications will be done
by comparing test applications sizes using Google Chrome network tab.
Test case 1
This test is designed to provide answer to RQ2, "How does initial page rendering
time of Vanilla JavaScript and the frameworks compare using Google Chome and
Firefox?". In this test the initial page render time is measured for each application
using both Google Chrome and Firefox.
The necessary metrics to calculate Page Render Time [16] are available in the Nav-
igation timing API [67]. Figure 4.1 show the timing attributes defined in Perfor-
manceTiming and PerformanceNavigation interface [67]. Using this interface it is
possible to measure the different stages involved in loading a web page in a browser.
This test measures Page Render Time, which is visualized in the figure as the box
named "Processing". The Page Render Time metric is calculated as domComplete -
domLoading [16].
13Figure 4.1: Illustration from W3.org showing the timing attributes defined in Per-
formanceTiming and PerformanceNavigation interface [67]
Test cases 2-5
These test cases are designed to provide an answer to RQ3, "How does Vanilla
JavaScript and the frameworks compare when it comes to DOM manipulation per-
formance using Google Chrome and Firefox?".
Test methodology for test case 2-5 Test case 2-5 are orchestrated using meth-
ods in the Performance interface [17], that is implemented in both Google Chrome
and Firefox, to measure the time duration of the test cases. Just before a test case is
initiated a timestamp is created using the performance.mark() method which serves
as the starting mark of the test case. Right after the test case is finished another
timestamp is created using the same method, serving as end mark of the test case.
By using the performance.measure() method the distance between the start and end
mark is measured, providing the time duration for the test case.
Test case 2 - Create 10000 elements. In this test the applications creates 10
000 paragraph elements in a containing div element on the page, and the performance
is measured by time duration to perform the operation.
Test case 3 - Update all elements. In this test the applications updates all
10 000 elements in the containing div element on the page, and the performance is
14New element
Figure 4.2: HTML code for elements created in test case 2.
measured by time duration to perform the operation.
Updated all
Figure 4.3: HTML code of the updated elements in test case 3.
Test case 4 - Update every other element. In this test the applications updates
every other element in the containing div element on the page, and the performance
is measured by time duration to perform the operation.
Updated half
Figure 4.4: HTML code of the updated elements in test case 4.
Test case 5 - Delete all elements. In this test the applications deletes all 10000
elements in the containing div element, and the performance is measured by time
duration to perform the operation.
4.2.3 Test script
A test script is developed to enable an automated test process. The script performs
the test cases detailed above. The script is written in Python [45] script and utilises
Selenium [51] and webdrivers for Chrome [8] and Gecko [12] in a headless setup. The
script emulates a user clicking on the buttons in the test application to perform the
different test cases. Each test case is iterated 100 times per application and browser,
and the results for each iteration is written to file.
4.2.4 Test applications
The applications are developed in adherence to these common guidelines:
• Development of applications done using methodologies in accordance with the
official documentation and best practice
• Application is prepared for deployment according to the official documentation
• No external libraries/modules is used
The reference application is a single page application having only the bare-bones
GUI and functionality needed to be able to perform the DOM test cases (create/up-
date/delete elements):
15• Button that when pressed creates and adds 10 000 elements to the DOM
• Button that when pressed updates all elements
• Button that when pressed updates every other element
• Button that when pressed deletes all elements
Framework versions and tools
All framework applications uses the latest version available at the time of creation
and are all initiated using their respective command line interface tool, Angular CLI
[4], create-react-app [29] and vue-cli [64].
Framework: Version:
Angular 9.1.1
React 16.13.1
Vue 2.6.11
Table 4.1: Framework versions used
4.2.5 Deployment of test script and test applications
The test applications are prepared for deployment according to the guidelines in the
respective frameworks official documentation [6, 47, 65]. All applications are con-
tainerized using Docker [28]. NGINX [33] is used as web server for all applications,
and all Docker images is based on nginx:1.18.0-alpine [34] Docker image. A t3.micro
[26] Elastic Compute instance on Amazon Web Services is used as Docker host. On
this instance a container for each test application is started and used for the tests.
The test script is deployed on a t3.large [26] Elastic Compute instance on Ama-
zon Web Services in the same Virtual Private Cloud [27] as the test web server,
allowing for HTTP access between the servers.
16Chapter 5
Results
5.1 DOM manipulation methodology comparison
DOM manipulation refers to actions that change the structure of the document [14].
Examples of DOM manipulation actions are for example creating, updating and
deleting elements on the page. DOM manipulation in Vanilla JavaScript is handled
directly by using appropriate methods in the DOM interface [14]. This is a funda-
mental difference compared to the selected frameworks where DOM manipulation
is handled indirectly via the framework. Whilst this gives a high degree of flexibil-
ity on how DOM manipulation is implemented in a Vanilla JavaScript application,
great care needs to be taken as there are several potential pitfalls to avoid not least
from a DOM manipulation performance perspective. As a developer using Vanilla
JavaScript an understanding of how to efficiently use the DOM interface is necessary
to avoid introducing DOM performance issues into the application.
The selected frameworks uses the same DOM interface for executing DOM manipu-
lations behind the scenes, but DOM manipulation is handled by the frameworks and
not by the developer directly. All frameworks strives to optimise DOM interaction,
and has taken different approaches to realize this.
5.1.1 Virtual DOM
React and Vue.js both have implemented a DOM manipulation methodology referred
to as Virtual DOM [31, 63]. The main purpose of the Virtual DOM is to keep the
real DOM updated with as little performance impact as possible.
The Virtual DOM is a virtual representation of the DOM. Whenever the frame-
work detects a change a new Virtual DOM is created. The newly created Virtual
DOM is then compared to the current Virtual DOM, to identify differences. This
process is commonly referred to as "DOM-diffing", but React calls it "Reconcilia-
tion" [30]. In this process a diffing algorithm is executed to calculate the optimal way
to update the real DOM with the identified differences. By using this methodology
the frameworks can update the real DOM with what has changed only, instead of
having to update the full DOM at every change.
The benefit of this method is the reduced DOM manipulation cost. However, creating
a new Virtual DOM at every change impacts memory usage [49, 43] and application
17size as the Virtual DOM is not tree-shakable and has to be fully included in appli-
cation builds. [49].
5.1.2 Incremental DOM
With the release of Angular version 9 (released February 6 2020 [10]) a new compiler
and runtime named Angular Ivy was introduced as the default option, replacing the
previous View Engine [5]. Angular Ivy has implemented a methodology called In-
cremental DOM, which is quite different to Virtual DOM. The main drivers for this
implementation is to optimize memory usage and application size.
Incremental DOM does not use a virtual representation of the DOM, but instead in-
teracts directly with the DOM. When the application detects and processes changes
affecting the DOM, this method updates only the parts of the DOM that are af-
fected by the change [60]. Viktor Savik, a previous member of the Angular team,
describes the main concept of Incremental DOM as "Every component gets compiled
into a series of instructions. These instructions create DOM trees and update them
in-place when the data changes" [49]. The instructions generated at compilation
includes both instructions to be executed when the component is first rendered, and
instructions regarding DOM updates when the component changes [49]. As these
instructions is generated at compile time, it is possible for Angular to apply tree-
shaking [69] to remove dead code related to rendering from the application build
[10, 49].
5.2 Performance comparison
5.2.1 Initial page render
80
Rendering Time (ms)
60
40
20
0
Vanilla JS Angular React Vue
Chrome FireFox
Figure 5.1: Initial Page Render, average (ms)
18Chrome Firefox
Average Std. dev Min Max Average Std. dev Min Max
Vanilla JavaScript 3 2.1 2 23 19 5.0 15 60
Angular 30 4.4 28 72 85 67.2 72 744
React 7 3.0 5 36 42 9.8 36 132
Vue 9 2.9 8 37 43 16.2 34 144
Table 5.1: Initial page render (ms)
As shown in figure 5.1 and table 5.1 Vanilla JavaScript has the lowest average ren-
dering times in both Google Chrome (3 ms) and Firefox (19 ms). The corresponding
results for React is the lowest among the compared frameworks in both Google
Chrome (7 ms) and Firefox (42 ms), closely followed by Vue in both Google Chrome
(9 ms) and Firefox (43 ms). Angular is behind in both Google Chrome (30 ms) and
Firefox (85 ms). The results show that all test applications achieve a lower average
page rendering time in Google Chrome. The standard deviation in the test results
is consistently higher in Firefox compared to Chrome, especially for Angular.
60
50
Rendering Time (ms)
40
30
20
10
0
Vanilla JS Angular React Vue
Figure 5.2: Initial Page Render, average results using both browsers (ms)
Average Std. dev
Vanilla JavaScript 11 8.7
Angular 58 55.0
React 24 18.7
Vue 26 20.3
Table 5.2: Initial page render, average and std. dev based on results using both
browsers (ms)
Figure 5.2 and table 5.2 shows the average render time for each application based
on test results from both browsers. Vanilla JavaScript clearly has the lowest average
rendering time (11 ms), followed by React (24 ms) and Vue (26 ms) and lastly Angular
(58 ms). The standard deviation when comparing the results for both browsers show
19that Vanilla JavaScript has the lowest standard deviation. Amongst the frameworks
React has the lowest standard deviation results, followed by Vue and Angular has
the highest standard deviation.
50
40
Rendering Time (ms)
30
20
10
0
Chrome Firefox
Figure 5.3: Average first page render time, all applications (ms)
As shown in table 5.3 Google Chrome achieves a lower average page render time (13
ms) than Firefox (47 ms) when comparing the test results for all applications in each
browser.
5.2.2 Create 10000 elements
1,200
1,000
800
Time (ms)
600
400
200
0
Vanilla JS Angular React Vue
Chrome FireFox
Figure 5.4: Create 10000 elements (ms)
20Chrome Firefox
Average Std. dev Min Max Average Std. dev Min Max
Vanilla JavaScript 221 8.1 207 251 329 8.4 323 375
Angular 865 21.4 825 935 732 65.1 690 1315
React 570 15.3 548 648 1012 89.4 878 1338
Vue 903 25.1 861 1020 1164 60.0 1055 1627
Table 5.3: Create 10000 elements (ms)
As shown in figure 5.4 and table 5.3 Vanilla JavaScript has the lowest average time
for creating 10 000 elements in both Google Chrome (221 ms) and Firefox (329 ms).
Amongst the compared frameworks the results differ between the browsers. React
achieve the second lowest result in Google Chrome (570 ms), and third lowest in
Firefox (1012 ms). Angular on the other hand achieves the second lowest result
in Firefox (732 ms) and third lowest result in Google Chrome (865 ms). Vue has
the highest average times for creating 10 000 elements in both Google Chrome (903
ms) and Firefox (1164 ms). The standard deviation in the test results for Vanilla
JavaScript is similar in both browsers, but for the frameworks it is consistently higher
in Firefox compared to Chrome.
1,000
800
Time (ms)
600
400
200
0
Vanilla JS Angular React Vue
Figure 5.5: Create 10000 elements, average (ms)
Average Std. dev
Vanilla JavaScript 275 54.9
Angular 798 82.4
React 791 230.0
Vue 1033 138.4
Table 5.4: Create 10000 elements, average and std. dev based on results using both
browsers (ms)
When comparing the results for each application based on test results from both
browsers as shown in figure 5.5 and table 5.4 Vanilla JavaScript has the lowest average
21time for creating 10 000 elements (275 ms). The results for React (791 ms) are close
to those of Angular (798 ms), and Vue (1033 ms) achieves the highest average time in
the test. The standard deviation when comparing the results for both browsers show
that Vanilla JavaScript has the lowest standard deviation. Amongst the frameworks
Angular has the lowest standard deviation results, followed by Vue and React has
the highest standard deviation.
800
600
Time (ms)
400
200
0
Chrome Firefox
Figure 5.6: Average create 10000 elements, all applications (ms)
As shown in figure 5.6 Google Chrome achieves a lower average time to create 10
000 elements (640 ms) than Firefox (809 ms) when comparing the test results for all
applications in each browser.
5.2.3 Update all elements
800
600
Time (ms)
400
200
0
Vanilla JS Angular React Vue
Chrome FireFox
Figure 5.7: Update all elements, average (ms)
22Chrome Firefox
Average Std. dev Min Max Average Std. dev Min Max
Vanilla JavaScript 246 9.2 232 268 346 7.1 339 377
Angular 355 14.9 333 389 431 32.2 407 653
React 347 14.4 309 373 384 24.6 363 461
Vue 596 16.2 564 668 850 84.1 738 1124
Table 5.5: Update all elements (ms)
Figure 5.7 and table 5.5 shows that Vanilla JavaScript has the lowest average time
for updating all 10 000 elements in both Google Chrome (246 ms) and Firefox (346
ms). React achieves the second lowest result in Google Chrome (347 ms) and Firefox
(384 ms). Angular has the third lowest results in both Google Chrome (355 ms) and
Firefox (431 ms), while Vue has the highest average time in both Google Chrome (596
ms) and Firefox (850 ms). The standard deviation in the test results is consistently
lower in Google Chrome for all application, with the exception of Vanilla JavaScript
that has a slightly lower standard deviation in Firefox.
600
Time (ms)
400
200
0
Vanilla JS Angular React Vue
Figure 5.8: Update all elements, average results using both browsers (ms)
Average Std. dev
Vanilla JavaScript 296 50.5
Angular 393 45.5
React 366 27.3
Vue 723 140.4
Table 5.6: Update all elements, average and std. dev based on results using both
browsers (ms)
When comparing the results for each application based on test results from both
browsers as shown in figure 5.8 and table 5.6 Vanilla JavaScript has the lowest average
time for creating 10 000 elements (275 ms), followed by React (366 ms), Angular (393
ms) and Vue (723 ms). The standard deviation when comparing the results for both
23browsers show that React has the lowest standard deviation, followed by Angular,
Vanilla JavaScript and Vue.
500
400
Time (ms)
300
200
100
0
Chrome Firefox
Figure 5.9: Update all elements, all applications (ms)
Figure 5.9 shows that Google Chrome achieves a lower average time to update all 10
000 elements (386 ms) than Firefox (503 ms) when comparing the test results for all
applications in each browser.
5.2.4 Update every other element
600
500
400
Time (ms)
300
200
100
0
Vanilla JS Angular React Vue
Chrome FireFox
Figure 5.10: Update every other element, average (ms)
24Chrome Firefox
Average Std. dev Min Max Average Std. dev Min Max
Vanilla JavaScript 159 6.3 148 183 278 5.9 275 321
Angular 219 6.4 210 243 352 42.1 324 471
React 188 6.6 177 208 315 51.3 290 715
Vue 326 8.6 313 367 583 62.4 545 842
Table 5.7: Update every other element (ms)
As shown in figure 5.10 and table 5.7 Vanilla JavaScript archives the lowest average
time to update every other element in Google Chrome (159 ms) and Firefox (278
ms). React achieves the second lowest result in Google Chrome (188 ms) and Firefox
(315 ms), followed by Angular (219 ms in Google Chrome, 352 ms in Firefox), and
Vue (325 ms in Google Chrome, 583 ms in Firefox). The standard deviation of the
results shows that all applications achive a similar result in Google Chrome. The
standard deviation of the results in Firefox is all higher except for Vanilla JavaScript.
Amongst the frameworks the results ranges from 42.1 (Angular) to 62.4 (Vue).
500
400
Time (ms)
300
200
100
0
Vanilla JS Angular React Vue
Figure 5.11: Update every other element, average results using both browsers (ms)
Average Std. dev
Vanilla JavaScript 219 60.0
Angular 285 73.2
React 252 73.4
Vue 455 135.8
Table 5.8: Update every other element, average and std. dev based on results using
both browsers (ms)
Figure 5.11 and table 5.8 shows the results for each application based on the test
results from both browsers. Vanilla JavaScript achieves the lowest average time to
update every other element (219 ms), followed by React (252 ms), Angular (285 ms)
and Vue (455 ms). The standard deviation when comparing the results for both
25browsers show that Vanilla JavaScript has the lowest standard deviation, followed
by Angular, React and Vue.
400
300
Time (ms)
200
100
0
Chrome Firefox
Figure 5.12: Update every other element, all applications (ms)
Figure 5.12 shows that Google Chrome achieves a lower average time to update every
other element (223 ms) compared to Firefox (382 ms) when comparing the test results
for all applications in each browser.
5.2.5 Delete all elements
400
300
Time (ms)
200
100
0
Vanilla JS Angular React Vue
Chrome FireFox
Figure 5.13: Delete all elements, average (ms)
26Chrome Firefox
Average Std. dev Min Max Average Std. dev Min Max
Vanilla JavaScript 84 6.2 73 104 235 3.0 232 251
Angular 426 14.4 405 523 365 110.8 336 1182
React 114 4.8 105 135 262 18.7 251 330
Vue 268 7.0 257 303 381 71.1 344 597
Table 5.9: Delete all elements (ms)
As shown in figure 5.13 and table 5.9 Vanilla JavaScript has the lowest average time
for deleting the 10 000 elements in both Google Chrome (84 ms) and Firefox (235
ms). React achieves the second lowest result in Google Chrome (114 ms) and Firefox
(262 ms). The results for Vue in Google Chrome (268 ms) is lower than Angular
(426 ms), and in Firefox (Angular 365 ms, Vue 381 ms) their positions are reversed.
The standard deviation in the test results is consistently higher in Firefox compared
to Chrome, except for Vanilla JavaScript that achieves a slightly lower standard
deviation in Firefox.
400
300
Time (ms)
200
100
0
Vanilla JS Angular React Vue
Figure 5.14: Delete all elements, average results using both browsers (ms)
Average Std. dev
Vanilla JavaScript 160 75.9
Angular 396 84.6
React 188 75.4
Vue 325 75.8
Table 5.10: Delete all elements, average and std. dev based on results using both
browsers (ms)
As shown in figure 5.14 and table 5.10 Vanilla JavaScript archives the lowest average
time to delete all 10000 elements followed by React (188 ms), Vue (325 ms) and
Angular (396 ms). The standard deviation when combining the results in both
27browsers show that Vanilla JavaScript, React and Vue all achieve similar results,
while Angular has a slightly higher standard deviation.
300
250
Time (ms)
200
150
100
50
0
Chrome Firefox
Figure 5.15: Average delete all elements, all applications (ms)
Figure 5.15 shows that Google Chrome achieves a lower average time to delete all
10 000 elements (223 ms) compared to Firefox (311 ms) when comparing the test
results for all applications in each browser.
5.3 Application size comparison
150
157.1
100
Size (kB)
135.3
108.9
50
3.2
0
Vanilla JS Angular React Vue
Figure 5.16: Application size comparison
As shown in figure 5.16 the Vanilla JavaScript test application has a total size of 3.2
kB. The size of the Vue.js application is 108.9 kb, the React application is 135.3 kB
and the Angular application is 157.1 kB.
28HTML/CSS
38.3
61.7
JavaScript
Figure 5.17: Vanilla JavaScript application size distribution in percent
As shown in figure 5.17 the Vanilla JavaScript test application consists of 61,7%
JavaScript and 38.3% HTML/CSS.
JavaScript 99.2 0.8 HTML/CSS
Figure 5.18: Angular application size distribution in percent
As shown in figure 5.18 the Angular test application consists of 99,2% JavaScript
and 0.8% HTML/CSS.
JavaScript 98.1 1.9 HTML/CSS
Figure 5.19: React application size distribution in percent
As shown in figure 5.19 the React test application consists of 98,1% JavaScript and
1.9% HTML/CSS.
29JavaScript 98.9 1.1 HTML/CSS
Figure 5.20: Vue application size distribution in percent
As shown in figure 5.20 the Vue.js test application consists of 98,9% JavaScript and
1.1% HTML/CSS.
30Chapter 6
Analysis and Discussion
This chapter contains the analysis of the results and is presented per research ques-
tion. The results from the empirical study is compared with results in relevant
similar studies. The chapter ends with a summary where the answers to the research
questions are put into a larger context.
6.1 RQ 1: How does the DOM manipulation method-
ology of Vanilla JavaScript and the selected frame-
works compare?
There is a distinct difference between Vanilla JavaScript on one hand, and the se-
lected frameworks on the other. Using Vanilla JavaScript DOM manipulation is
handled directly by using appropriate methods in the DOM interface [14], where
as when using one of the selected frameworks the actual interaction with the DOM
interface is abstracted away from the developer. Vanilla JavaScript offers full flexi-
bility to the developer regarding how to structure and perform DOM manipulation
in the application. But this flexibility shifts the responsibility for efficient DOM
manipulation to the developer(s), requiring the developer(s) to have a solid knowl-
edge of how to utilize the DOM interface to construct efficient DOM manipulation
methods. The DOM interface often offer several alternative methods to perform a
specific DOM operation, and there might be significant differences in performance
between these methods. For a developer without adequate DOM interface knowledge
there is a risk that inefficient DOM manipulation is introduced into the application.
Furthermore it is reasonable to claim that this risk is amplified in larger developer
teams. As DOM manipulation in the selected frameworks is abstracted away from
the developer, the same level of DOM interface knowledge and focus is not needed
when utilizing a framework. On the other hand, using a framework requires frame-
work specific knowledge instead.
All frameworks use the DOM interface for executing DOM manipulations behind
the scenes, and they all strive to optimize DOM interaction. While React and Vue.js
both has implemented a Virtual DOM [31, 63] to optimize DOM interactions, An-
gular (version 9) has implemented Incremental DOM. Most of the relevant material
found on Virtual DOM points out its high performance DOM manipulation as the
main strength. Furthermore the main downsides suggested is its higher memory
usage related to keeping a virtual representation of the DOM in memory, and the
31addition to application size as the Virtual DOM is not tree-shakable. Material found
on Incremental DOM points out its smaller memory footprint due to not having a
in-memory virtual representation of the DOM, and the positive effect its ability to
utilize tree-shaking [69] to remove dead code related to rendering has on application
size as the main benefits.
The test result from the empiric study and other relevant comparison tests [36, 50]
suggests that all the selected frameworks can be considered as feasible alternatives
for creating interactive web applications with high DOM manipulation performance,
meaning both Virtual DOM and Incremental DOM can deliver adequate DOM per-
formance.
6.2 RQ 2: How does initial page rendering time of
Vanilla JavaScript and the frameworks compare
using Google Chrome and Firefox?
The importance of a fast loading web page has been described earlier in this thesis,
and Page Render Time is a significant part of the total page load time impacting
user experience, SEO and bounce rates. In test case 1, "First page render", in the
empirical study a comparison test for first page render time was performed using the
test application. It is worth noting that the test application is small with light-weight
landing page, and should not be considered equivalent to a real application in terms
of size and complexity. As expected, Vanilla JavaScript achieved the best results,
both for Google Chrome and Firefox. The author’s opinion is to consider the results
for Vanilla JavaScript as a baseline to which the frameworks can be compared to.
Amongst the frameworks React and Vue are very close in terms of results in both
browsers, and Angular achieves the slowest rendering time. The author can conclude
that these results correlate to a large extent with a similar benchmark [36], with the
exception of the results for React which in the benchmark performed noticeably worse
than Vue. When comparing the average results for the applications based on the
test runs performed in both browsers Vanilla JavaScript achieves the lowest average
time, followed by React and Vue archiving similar results with Angular having the
highest average time. When comparing the results in Google Chrome and Firefox,
the author can conclude that all applications performed better in Google Chrome,
achieving both lower and more consistent results.
6.3 RQ 3: How does Vanilla JavaScript and the
frameworks compare when it comes to DOM
manipulation performance using Google Chrome
and Firefox?
To answer this research question four test cases where performed in the empiri-
cal study. The test cases covers DOM manipulation actions for creating, updating
32and deleting elements from the web page using Vanilla JavaScript and the selected
frameworks. The author’s opinion is to consider the results for Vanilla JavaScript as
a baseline to which the frameworks can be compared to.
Create 10 000 elements
The results from the test measuring time to create 10 000 elements points out that
Vanilla JavaScript is significantly faster compared to the selected frameworks in both
Google Chrome and Firefox. Amongst the frameworks the results range from at best
570 ms (React using Google Chrome) to at worst 1164 ms (Angular using Firefox).
The results for React stand out in this test, as the React test application takes almost
twice the time to create the 10 000 elements in Firefox compared to Google Chrome.
Furthermore it is interesting to see the difference in results for React and Vue.js
given that both frameworks use a Virtual DOM. When comparing the results with a
similar benchmark creating 10 000 table rows performed using the same technologies
and Google Chrome [36], Vanilla JavaScript archives the fastest times in both tests
but the gap between Vanilla JavaScript and the frameworks is larger in the test in
this study. When comparing the average results for the applications based on the
test runs performed in both browsers Vanilla JavaScript achieves the lowest average
time, followed by React and Angular archiving similar results, and Vue.js having the
highest average time. Comparing the test results in Google Chrome and Firefox, the
author can conclude that all applications performed better in Google Chrome in this
test case except for Angular. When comparing the results in Google Chrome and
Firefox in table 5.3, the author can conclude that all applications performed better
in Google Chrome, achieving both lower and more consistent results. The standard
deviation for the results in both browsers in table 5.4 shows a higher standard devi-
ation for React(230 ms) and Vue(138.4 ms) than the other applications. This is due
to the significant difference in the results these applications achieve in the browsers
as shown in table 5.3.
Update all elements
From the results of the test to update all 10 000 elements Vanilla JavaScript again
achieves the lowest average result in both Google Chrome and Firefox. Both React
and Angular archives average times that are within 100 ms of Vanilla JavaScript’s
results in both browsers, with React being only slightly faster. Vue.js comes in at the
last position being clearly behind the other frameworks, especially in Firefox where
Vue.js takes almost twice as long to perform the test compared to React and Vue.js.
It is worth noting the difference in results between React and Vue, given that both
use Virtual DOM. When comparing these results with a similar benchmark using
the same technologies and Google Chrome [36] the author can conclude that results
correlate in large with the exception for Vue.js that in the compared benchmark per-
forms in line with the other frameworks. When comparing the average results for the
applications based on the test runs performed in both browsers Vanilla JavaScript
achieves the lowest average time, but React and Angular is following closely and
Vue.js is clearly behind in this test. The standard deviation in the test results for
Vanilla JavaScript is similar in both browsers, but for the frameworks it is consis-
tently higher in Firefox compared to Chrome as shown in table 5.5. The table also
shows that in this test there is only a slight difference in standard deviation be-
33tween the browsers for all applications except for Vue. As a result table 5.6 shows
lower standard deviations for all the applications except Vue when combining the
test results from both browsers. This is due to the larger difference in the results
Vue achieve in the browsers as shown in table 5.5. The author concludes that all
applications performs better and with more consistent results in Chrome compared
to Firefox in this test case.
Update every other element
In the results for the test to update every other element (totaling 5 000 elements)
Vanilla JavaScript once again achieves the lowest average time both using Google
Chrome and Firefox. In this test the spread between the test results per browser is
smaller, especially in Google Chrome. Amongst the frameworks React has the lowest
average time in both browsers, followed by Angular and Vue had the highest average
time. When comparing the results with a similar benchmark using the same tech-
nologies and Google Chrome [36], the order of technologies in the test results is the
same in both tests. When comparing the average results for the applications based
on the test runs performed in both browsers Vanilla JavaScript achieves the lowest
average time (219 ms), followed relatively close by React (252 ms) and Angular (285
ms) archiving similar results with Vue (455 ms) having the highest average time.
The standard deviation of the results in table 5.7 shows that the standard deviation
in Firefox is higher for all applications except for Vanilla JavaScript. The difference
in performance between the browsers for Vue leads to a higher standard deviation
for that application when looking at the results in table 5.8. It should be noted that
all applications achieved lower average times in Google Chrome compared to Firefox,
and all applications except for Vanilla JavaScript achieved more consistent results in
Google Chrome.
Delete all elements
The results from the test measuring average time to delete all 10 000 elements show
that Vanilla JavaScript is significantly faster compared to the selected frameworks in
both Google Chrome and Firefox. Amongst the frameworks the results range from
at best 114 ms (React using Google Chrome) to at worst 426 ms (Angular using
Chrome). The results for Angular stand out in this test, as the Angular test applica-
tion is the only application to achieve a better result in Firefox compared to Google
Chrome. When comparing the results with a similar benchmark using the same tech-
nologies and Google Chrome [36], the test results correlate with exception for Vue.js
which performs at a similar level as React in the compared test. When comparing
the average results for the applications based on the test runs performed in both
browsers Vanilla JavaScript achieves the lowest average time, with React following
closely behind. Vue.js is a bit React, and Angular has the longest average time in
this test. The standard deviation of the results in table 5.9 shows that the standard
deviation in Firefox is higher for all applications except for Vanilla JavaScript. An-
gular stands out in this respect having a significant difference in standard deviation
between the browsers, and also when compared to the other applications in Firefox.
All applications performed better in Google Chrome compared to Firefox in this test
case, except for Angular.
34You can also read
