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. 2
Chapter 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 3
with 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. 4
Figure 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 6
2.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." 8
Chapter 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. 9
3.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. 10
3.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. 11
Chapter 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]. 13
Figure 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 14
New 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. 16
Chapter 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 17
size 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) 18
Chrome 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 19
that 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) 20
Chrome 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 21
time 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) 22
Chrome 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 23
browsers 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) 24
Chrome 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 25
browsers 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) 26
Chrome 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 27
browsers 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. 28
HTML/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. 29
JavaScript 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. 30
Chapter 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 31
addition 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 32
and 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- 33
tween 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. 34
You can also read