JavaScript DOM Manipulation Performance - DiVA Portal

1y ago
10 Views
4 Downloads
575.06 KB
54 Pages
Last View : 21d ago
Last Download : 2m ago
Upload by : Ellie Forte
Transcription

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 Blekinge Institute of Technology SE–371 79 Karlskrona, Sweden Internet : www.bth.se Phone : 46 455 38 50 00 Fax : 46 455 38 50 57

Abstract Background. Websites of 2020 are often feature rich and highly interactive applications. JavaScript is a popular programming language for the web, with many frameworks available. A common denominator for highly interactive web applications 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 application 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 interactive 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 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 2 2 Background 2.1 Document Object Model . . . . . . . . . . . . . 2.2 CSS Object Model . . . . . . . . . . . . . . . . 2.3 Rendering the HTML document in the Browser 2.3.1 First render . . . . . . . . . . . . . . . . 2.3.2 Repaint and reflow . . . . . . . . . . . . 2.4 Vanilla JavaScript and the selected frameworks 2.4.1 Vanilla JavaScript . . . . . . . . . . . . . 2.4.2 Angular . . . . . . . . . . . . . . . . . . 2.4.3 React . . . . . . . . . . . . . . . . . . . 2.4.4 Vue.js . . . . . . . . . . . . . . . . . . . 3 3 4 5 5 6 7 7 7 7 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Research Questions 3.1 RQ 1: How does the DOM manipulation methodology of Vanilla JavaScript and the selected frameworks compare? . . . . . . . . . . . 3.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . 3.4 RQ 4: How does Vanilla JavaScript and the frameworks compare when it comes to application size? . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Expected Outcome . . . . . . . . . . . . . . . . . . . . . . . . ii 9 9 9 9 9 9 10 10 10 10 10 10 11

4 Method 4.1 Literature Study . . . . . . . . . . . . . 4.2 Empirical Study . . . . . . . . . . . . . . 4.2.1 Experiment design . . . . . . . . 4.2.2 Test cases . . . . . . . . . . . . . 4.2.3 Test script . . . . . . . . . . . . . 4.2.4 Test applications . . . . . . . . . 4.2.5 Deployment of test script and test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . applications . 5 Results 5.1 DOM manipulation methodology comparison 5.1.1 Virtual DOM . . . . . . . . . . . . . 5.1.2 Incremental DOM . . . . . . . . . . . 5.2 Performance comparison . . . . . . . . . . . 5.2.1 Initial page render . . . . . . . . . . 5.2.2 Create 10000 elements . . . . . . . . 5.2.3 Update all elements . . . . . . . . . . 5.2.4 Update every other element . . . . . 5.2.5 Delete all elements . . . . . . . . . . 5.3 Application size comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 12 12 12 13 15 15 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 17 18 18 18 20 22 24 26 28 6 Analysis and Discussion 6.1 RQ 1: How does the DOM manipulation methodology of Vanilla JavaScript and the selected frameworks compare? . . . . . . . . . . . 6.2 RQ 2: How does initial page rendering time of Vanilla JavaScript and the frameworks compare using Google Chrome and Firefox? . . . . . 6.3 RQ 3: How does Vanilla JavaScript and the frameworks compare when it comes to DOM manipulation performance using Google Chrome and Firefox? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 RQ 4: How does Vanilla JavaScript and the frameworks compare when it comes to application size? . . . . . . . . . . . . . . . . . . . . . . . 6.5 Results seen from a sustainability and societal perspective . . . . . . 31 7 Validity Threats 38 8 Conclusion 39 9 Future Work 40 References 41 A Empirical study links 47 iii 31 32 32 36 37

Chapter 1 Introduction Since its inception in 1995 JavaScript has evolved into one of the fundamental programming 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, performance 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 Internets 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 electricity 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 hardware can amplify this effect. With the rapid evolution taking place in the JavaScript front-end framework landscape 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 thesis 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 manipulation methodology and performance for Vanilla JavaScript and the selected frameworks. Comparing DOM performance in vanilla JavaScript and a selection of frontend 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, originating 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 document 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 style 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 2.3.1 Rendering the HTML document in the Browser 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 CSSOM. 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 defined styles (b) Page rendered with the 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 frameworks 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 Internationals 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 Platform 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 effortless, 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 relies 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 3.1.1 RQ 1: How does the DOM manipulation methodology of Vanilla JavaScript and the selected frameworks compare? Motivation For client-side JavaScript applications DOM manipulation is a key ability that enables dynamic manipulation of HTML and CSS resources. However, DOM manipulation 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 manipulation. 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 frameworks are expected to have taken different approaches when it comes to DOM manipulation methodology. 3.2 3.2.1 RQ 2: How does initial page rendering time of Vanilla JavaScript and the frameworks compare using Google Chrome and Firefox? 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 rendering 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 3.3.1 RQ 3: How does Vanilla JavaScript and the frameworks compare when it comes to DOM manipulation performance using Google Chrome and Firefox? 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 insights 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 performance than the frameworks. Regarding the frameworks the expectation is that all will exhibit a high level of DOM performance, and the frameworks DOM performance 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 3.4.1 RQ 4: How does Vanilla JavaScript and the frameworks compare when it comes to application size? Motivation Application size is one parameter impacting performance. As application size increases 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 Navigation timing API [67]. Figure 4.1 show the timing attributes defined in PerformanceTiming 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 PerformanceTiming 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 performance using Google Chrome and Firefox?". Test methodology for test case 2-5 Test case 2-5 are orchestrated using methods 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

p class "new" New element /p Figure 4.2: HTML code for elements created in test case 2. measured by time duration to perform the operation. p class "updated-all" Updated all /p 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, an

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

Related Documents:

JavaScript Manual for LCCS Teachers 13 Client-side JavaScript vs. server-side JavaScript For many years JavaScript was a client-side scripting language. This was because JavaScript programs could only be run from inside web browsers which were installed on client machines. Because of the fact that JavaScript code can run on client devices it means

- The Spark web app framework . Yahoo JavaScript PHP Amazon.com JavaScript Java, C , Perl Wikipedia.org JavaScript PHP, Hack Twitter.com JavaScript C , Java, Scala, Ruby Bing JavaScript ASP.net eBay.com JavaScript Java, JavaScript, Scala . Note the MVC architecture

Mastering Ajax, Part 6: Build DOM-based Web applications Mix the DOM and JavaScript -- those perfect Ajax companions-- to change a Web page's user interface without page reloads Skill Level: Intermediate Brett McLaughlin Author and Editor O'Reilly Media Inc. 12 Sep 2006 Combine the Document Object Model (DOM) with JavaScript code to create .

JavaScript. Check a framework's documentation for details. Using the SDK with Web Browsers All major web browsers support execution of JavaScript. JavaScript code that is running in a web browser is often called client-side JavaScript. Using the SDK for JavaScript in a web browser differs from the way in which you use it for Node.js. The

Praise for Effective JavaScript "Living up to the expectation of an Effective Software Development Series pro-gramming book, Effective JavaScript by Dave Herman is a must-read for anyone who wants to do serious JavaScript programming. The book provides detailed explanations of the inner workings of JavaScript, which helps readers take better

JavaScript directly within the HTML file. We can also include more than one script tag and can include a mix of internal JavaScript and external JavaScript files. This will be useful, for example, if we have some JavaScript that is appropriate for many of our webpages and then some JavaScript that is specific to one page. Function Definition

HTML JavaScript DOM A GUI toolkit, with some catches DOM serves as model, view, and controller Event handlers written in JavaScript Visual output derived from DOM node props –No paint method!

Soldier’s level of functioning as of the last developmental counseling session IAW AR 380-5, paragraph 5-5; and AR 25-2, paragraph 4-5. 2. First line leaders should: a. Conduct counseling sessions addressing the domains identified on the USA SLRRT with all Soldiers for whom they are responsible IAW paragraph F: Policies and