Javascript DOM Manipulation Performance Comparing Vanilla Javascript and Leading Javascript Front-End Frameworks

Total Page:16

File Type:pdf, Size:1020Kb

Javascript DOM Manipulation Performance Comparing Vanilla Javascript and Leading Javascript Front-End Frameworks 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: [email protected] 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.1Scope................................... 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 Firstrender............................ 5 2.3.2 Repaintandreflow........................ 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 JavaScriptandtheselectedframeworkscompare?........... 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 itcomestoapplicationsize?....................... 10 3.4.1 Motivation ............................. 10 3.4.2 Expected Outcome ........................ 11 ii 4Method 12 4.1LiteratureStudy............................. 12 4.2 Empirical Study .............................. 12 4.2.1 Experiment design ........................ 12 4.2.2 Testcases............................. 13 4.2.3 Testscript............................. 15 4.2.4 Testapplications......................... 15 4.2.5 Deploymentoftestscriptandtestapplications......... 16 5 Results 17 5.1DOMmanipulationmethodologycomparison.............. 17 5.1.1 VirtualDOM........................... 17 5.1.2 IncrementalDOM......................... 18 5.2Performancecomparison......................... 18 5.2.1 Initialpagerender........................ 18 5.2.2 Create 10000 elements ...................... 20 5.2.3 Updateallelements........................ 22 5.2.4 Updateeveryotherelement................... 24 5.2.5 Deleteallelements........................ 26 5.3Applicationsizecomparison....................... 28 6 Analysis and Discussion 31 6.1 RQ 1: How does the DOM manipulation methodology of Vanilla JavaScriptandtheselectedframeworkscompare?........... 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 itcomestoapplicationsize?....................... 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
Recommended publications
  • Machine Learning in the Browser
    Machine Learning in the Browser The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:38811507 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Machine Learning in the Browser a thesis presented by Tomas Reimers to The Department of Computer Science in partial fulfillment of the requirements for the degree of Bachelor of Arts in the subject of Computer Science Harvard University Cambridge, Massachusetts March 2017 Contents 1 Introduction 3 1.1 Background . .3 1.2 Motivation . .4 1.2.1 Privacy . .4 1.2.2 Unavailable Server . .4 1.2.3 Simple, Self-Contained Demos . .5 1.3 Challenges . .5 1.3.1 Performance . .5 1.3.2 Poor Generality . .7 1.3.3 Manual Implementation in JavaScript . .7 2 The TensorFlow Architecture 7 2.1 TensorFlow's API . .7 2.2 TensorFlow's Implementation . .9 2.3 Portability . .9 3 Compiling TensorFlow into JavaScript 10 3.1 Motivation to Compile . 10 3.2 Background on Emscripten . 10 3.2.1 Build Process . 12 3.2.2 Dependencies . 12 3.2.3 Bitness Assumptions . 13 3.2.4 Concurrency Model . 13 3.3 Experiences . 14 4 Results 15 4.1 Benchmarks . 15 4.2 Library Size . 16 4.3 WebAssembly . 17 5 Developer Experience 17 5.1 Universal Graph Runner .
    [Show full text]
  • Create Mobile Apps with HTML5, Javascript and Visual Studio
    Create mobile apps with HTML5, JavaScript and Visual Studio DevExtreme Mobile is a single page application (SPA) framework for your next Windows Phone, iOS and Android application, ready for online publication or packaged as a store-ready native app using Apache Cordova (PhoneGap). With DevExtreme, you can target today’s most popular mobile devices with a single codebase and create interactive solutions that will amaze. Get started today… ・ Leverage your existing Visual Studio expertise. ・ Build a real app, not just a web page. ・ Deliver a native UI and experience on all supported devices. ・ Use over 30 built-in touch optimized widgets. Learn more and download your free trial devexpress.com/mobile All trademarks or registered trademarks are property of their respective owners. Untitled-4 1 10/2/13 11:58 AM APPLICATIONS & DEVELOPMENT SPECIAL GOVERNMENT ISSUE INSIDE Choose a Cloud Network for Government-Compliant magazine Applications Geo-Visualization of SPECIAL GOVERNMENT ISSUE & DEVELOPMENT SPECIAL GOVERNMENT ISSUE APPLICATIONS Government Data Sources Harness Open Data with CKAN, OData and Windows Azure Engage Communities with Open311 THE DIGITAL GOVERNMENT ISSUE Inside the tools, technologies and APIs that are changing the way government interacts with citizens. PLUS SPECIAL GOVERNMENT ISSUE APPLICATIONS & DEVELOPMENT SPECIAL GOVERNMENT ISSUE & DEVELOPMENT SPECIAL GOVERNMENT ISSUE APPLICATIONS Enhance Services with Windows Phone 8 Wallet and NFC Leverage Web Assets as Data Sources for Apps APPLICATIONS & DEVELOPMENT SPECIAL GOVERNMENT ISSUE ISSUE GOVERNMENT SPECIAL DEVELOPMENT & APPLICATIONS Untitled-1 1 10/4/13 11:40 AM CONTENTS OCTOBER 2013/SPECIAL GOVERNMENT ISSUE OCTOBER 2013/SPECIAL GOVERNMENT ISSUE magazine FEATURES MOHAMMAD AL-SABT Editorial Director/[email protected] Geo-Visualization of Government KENT SHARKEY Site Manager Data Sources MICHAEL DESMOND Editor in Chief/[email protected] Malcolm Hyson ..........................................
    [Show full text]
  • Extracting Taint Specifications for Javascript Libraries
    Extracting Taint Specifications for JavaScript Libraries Cristian-Alexandru Staicu Martin Toldam Torp Max Schäfer TU Darmstadt Aarhus University GitHub [email protected] [email protected] [email protected] Anders Møller Michael Pradel Aarhus University University of Stuttgart [email protected] [email protected] ABSTRACT ACM Reference Format: Modern JavaScript applications extensively depend on third-party Cristian-Alexandru Staicu, Martin Toldam Torp, Max Schäfer, Anders Møller, and Michael Pradel. 2020. Extracting Taint Specifications for JavaScript libraries. Especially for the Node.js platform, vulnerabilities can Libraries. In 42nd International Conference on Software Engineering (ICSE have severe consequences to the security of applications, resulting ’20), May 23–29, 2020, Seoul, Republic of Korea. ACM, New York, NY, USA, in, e.g., cross-site scripting and command injection attacks. Existing 12 pages. https://doi.org/10.1145/3377811.3380390 static analysis tools that have been developed to automatically detect such issues are either too coarse-grained, looking only at 1 INTRODUCTION package dependency structure while ignoring dataflow, or rely on JavaScript is powering a wide variety of web applications, both manually written taint specifications for the most popular libraries client-side and server-side. Many of these applications are security- to ensure analysis scalability. critical, such as PayPal, Netflix, or Uber, which handle massive In this work, we propose a technique for automatically extract- amounts of privacy-sensitive user data and other assets. An impor- ing taint specifications for JavaScript libraries, based on a dynamic tant characteristic of modern JavaScript-based applications is the analysis that leverages the existing test suites of the libraries and extensive use of third-party libraries.
    [Show full text]
  • Microsoft AJAX Library Essentials Client-Side ASP.NET AJAX 1.0 Explained
    Microsoft AJAX Library Essentials Client-side ASP.NET AJAX 1.0 Explained A practical tutorial to using Microsoft AJAX Library to enhance the user experience of your ASP.NET Web Applications Bogdan Brinzarea Cristian Darie BIRMINGHAM - MUMBAI Microsoft AJAX Library Essentials Client-side ASP.NET AJAX 1.0 Explained Copyright © 2007 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, Packt Publishing, nor its dealers or distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: July 2007 Production Reference: 1230707 Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-847190-98-7 www.packtpub.com Cover Image by www.visionwt.com Table of Contents Preface 1 Chapter 1: AJAX and ASP.NET 7 The Big Picture 8 AJAX and Web 2.0 10 Building
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Security Analysis of Firefox Webextensions
    6.857: Computer and Network Security Due: May 16, 2018 Security Analysis of Firefox WebExtensions Srilaya Bhavaraju, Tara Smith, Benny Zhang srilayab, tsmith12, felicity Abstract With the deprecation of Legacy addons, Mozilla recently introduced the WebExtensions API for the development of Firefox browser extensions. WebExtensions was designed for cross-browser compatibility and in response to several issues in the legacy addon model. We performed a security analysis of the new WebExtensions model. The goal of this paper is to analyze how well WebExtensions responds to threats in the previous legacy model as well as identify any potential vulnerabilities in the new model. 1 Introduction Firefox release 57, otherwise known as Firefox Quantum, brings a large overhaul to the open-source web browser. Major changes with this release include the deprecation of its initial XUL/XPCOM/XBL extensions API to shift to its own WebExtensions API. This WebExtensions API is currently in use by both Google Chrome and Opera, but Firefox distinguishes itself with further restrictions and additional functionalities. Mozilla’s goals with the new extension API is to support cross-browser extension development, as well as offer greater security than the XPCOM API. Our goal in this paper is to analyze how well the WebExtensions model responds to the vulnerabilities present in legacy addons and discuss any potential vulnerabilities in the new model. We present the old security model of Firefox extensions and examine the new model by looking at the structure, permissions model, and extension review process. We then identify various threats and attacks that may occur or have occurred before moving onto recommendations.
    [Show full text]
  • Analysing the Use of Outdated Javascript Libraries on the Web
    Updated in September 2017: Require valid versions for library detection throughout the paper. The vulnerability analysis already did so and remains identical. Modifications in Tables I, III and IV; Figures 4 and 7; Sections III-B, IV-B, IV-C, IV-F and IV-H. Additionally, highlight Ember’s security practices in Section V. Thou Shalt Not Depend on Me: Analysing the Use of Outdated JavaScript Libraries on the Web Tobias Lauinger, Abdelberi Chaabane, Sajjad Arshad, William Robertson, Christo Wilson and Engin Kirda Northeastern University {toby, 3abdou, arshad, wkr, cbw, ek}@ccs.neu.edu Abstract—Web developers routinely rely on third-party Java- scripts or HTML into vulnerable websites via a crafted tag. As Script libraries such as jQuery to enhance the functionality of a result, it is of the utmost importance for websites to manage their sites. However, if not properly maintained, such dependen- library dependencies and, in particular, to update vulnerable cies can create attack vectors allowing a site to be compromised. libraries in a timely fashion. In this paper, we conduct the first comprehensive study of To date, security research has addressed a wide range of client-side JavaScript library usage and the resulting security client-side security issues in websites, including validation [30] implications across the Web. Using data from over 133 k websites, we show that 37 % of them include at least one library with a and XSS ([17], [36]), cross-site request forgery [4], and session known vulnerability; the time lag behind the newest release of fixation [34]. However, the use of vulnerable JavaScript libraries a library is measured in the order of years.
    [Show full text]
  • 6. Client-Side Processing
    6. Client-Side Processing 1. Client-side processing 2. JavaScript 3. Client-side scripting 4. Document Object Model (DOM) 5. Document methods and properties 6. Events 7. Calling a function 8. Table of squares function 9. Comments on previous script 10. Defining a function 11. Event handlers 12. Event handlers example 13. Event listeners 14. Functions and form fields 15. Defining the function myTranslate 16. Navigating the DOM tree 17. Finding elements by name 18. Finding elements by name (function body) 19. Using CSS selectors 20. Adding elements 21. Deleting elements 22. Using jQuery 23. Using jQuery to add elements 24. Finding elements by name (jQuery) 25. DOM and XML 26. jQuery method to load an XML file 27. Retrieving RSS item titles 28. Retrieving JSON data 29. JSON country data 30. Code for JSON retrieval (1) 31. Code for JSON retrieval (2) 32. Exercises 33. Links to more information 6.1. Client-side processing client program (e.g. web browser) can be used to customise interaction with the user validate user input (although HTML5 now provides this) generate (part of) document dynamically send requests to a server in the background make interaction with a web page similar to that of a desktop application this is typically done using JavaScript, since a Javascript interpreter is built into browsers 6.2. JavaScript interpreted, scripting language for the web loosely typed variables do not have to be declared the same variable can store values of different types at different times HTML <script> element specifies script to be executed type attribute has value text/javascript src attribute specifies URI of external script usually <script> appears in the <head> and just declares functions to be called later ECMAScript, 10th edition (June 2019) is the latest standard 6.3.
    [Show full text]
  • Mozilla/Firefox: MDN Web Docs, Recommended Extensions and Tenfourfox FPR23 for Intel
    Published on Tux Machines (http://www.tuxmachines.org) Home > content > Mozilla/Firefox: MDN Web Docs, Recommended Extensions and TenFourFox FPR23 for Intel Mozilla/Firefox: MDN Web Docs, Recommended Extensions and TenFourFox FPR23 for Intel By Rianne Schestowitz Created 12/06/2020 - 5:32am Submitted by Rianne Schestowitz on Friday 12th of June 2020 05:32:58 AM Introducing the MDN Web Docs Front-end developer learning pathway[1] The MDN Web Docs Learning Area (LA) was first launched in 2015, with the aim of providing a useful counterpart to the regular MDN reference and guide material. MDN had traditionally been aimed at web professionals, but we were getting regular feedback that a lot of our audience found MDN too difficult to understand, and that it lacked coverage of basic topics. Fast forward 5 years, and the Learning Area material is well-received. It boasts around 3.5?4 million page views per month; a little under 10% of MDN Web Docs? monthly web traffic. At this point, the Learning Area does its job pretty well. A lot of people use it to study client- side web technologies, and its loosely-structured, unopinionated, modular nature makes it easy to pick and choose subjects at your own pace. Teachers like it because it is easy to include in their own courses. Recommended extensions ? recent additions [2] When the Recommended Extensions program debuted last year, it listed about 60 extensions. Today the program has grown to just over a hundred as we continue to evaluate new nominations and carefully grow the list. The curated collection grows slowly because one of the program?s goals is to cultivate a fairly fixed list of content so users can feel confident the Recommended extensions they install will be monitored for safety and security for the foreseeable future.
    [Show full text]
  • Introduction to HTML/CSS/SVG/D3
    D3 Tutorial Introduction of Basic Components: HTML, CSS, SVG, and JavaScript D3.js Setup Edit by Jiayi Xu and Han-Wei SHen, THe OHio State University HTML - Hyper Text Markup Language • HTML is the standard markup language for creating Web pages • HTML describes the structure of Web pages using markup • HTML elements • HTML elements are the building blocks of HTML pages • represented by tags • Tags • HTML tags label pieces of content such as • <head> tag for “heading” • <p> for “paragraph” • <table> for “table” and so on • Browsers do not display the HTML tags, but use them to render the content of the page HTML - Plain Text • If we display the information only by plain text HTML Basics HTML is designed for marking up text by adding tags such as <p> to create HTML elements. Example image: HTML - Codes and the Result HTML - DOM • When a web page is loaded, the browser creates a Document Object Model of the page • The HTML DOM model is constructed as a tree of Objects HTML - DOM Document Root element: <html> Element: Element: <head> <body> Element: Element: Element: Element: <p> Element: <p> <title> <h1> <img> "to create Text: "HTML Text: "HTML Element "is designed Element: "by adding Element Element: Attribute: Attribute: HTML Tutorial" Basics" <strong> for" <em> tags such as" <code> <strong> "src" "style" elements. " "marking up “Example "HTML" "<p>" text" image” HTML - DOM • With the object model, JavaScript can create dynamic HTML by manipulating the objects: • JavaScript can change all the HTML elements in the page • Change all the
    [Show full text]
  • Mitigating Javascript's Overhead with Webassembly
    Samuli Ylenius Mitigating JavaScript’s overhead with WebAssembly Faculty of Information Technology and Communication Sciences M. Sc. thesis March 2020 ABSTRACT Samuli Ylenius: Mitigating JavaScript’s overhead with WebAssembly M. Sc. thesis Tampere University Master’s Degree Programme in Software Development March 2020 The web and web development have evolved considerably during its short history. As a result, complex applications aren’t limited to desktop applications anymore, but many of them have found themselves in the web. While JavaScript can meet the requirements of most web applications, its performance has been deemed to be inconsistent in applications that require top performance. There have been multiple attempts to bring native speed to the web, and the most recent promising one has been the open standard, WebAssembly. In this thesis, the target was to examine WebAssembly, its design, features, background, relationship with JavaScript, and evaluate the current status of Web- Assembly, and its future. Furthermore, to evaluate the overhead differences between JavaScript and WebAssembly, a Game of Life sample application was implemented in three splits, fully in JavaScript, mix of JavaScript and WebAssembly, and fully in WebAssembly. This allowed to not only compare the performance differences between JavaScript and WebAssembly but also evaluate the performance differences between different implementation splits. Based on the results, WebAssembly came ahead of JavaScript especially in terms of pure execution times, although, similar benefits were gained from asm.js, a predecessor to WebAssembly. However, WebAssembly outperformed asm.js in size and load times. In addition, there was minimal additional benefit from doing a WebAssembly-only implementation, as just porting bottleneck functions from JavaScript to WebAssembly had similar performance benefits.
    [Show full text]
  • Downloads the Lists of Search Engines and Query Terms That Are Previously Defined As Part of an Experimental Design
    Running Head: ALGORITHM AUDITING AT A LARGE-SCALE 1 Algorithm Auditing at a Large-Scale: Insights from Search Engine Audits Roberto Ulloa1, Mykola Makhortykh2 and Aleksandra Urman3 1 GESIS – Leibniz-Institute for the Social Sciences 2 University of Bern 3 University of Zurich Author Note We have no conflicts of interest to disclose. This is a preprint and working version of the paper. Data collections were sponsored from the SNF (100001CL_182630/1) and DFG (MA 2244/9-1) grant for the project “Reciprocal relations between populist radical-right attitudes and political information behaviour: A longitudinal study of attitude development in high- choice information environments” lead by Silke Adam (U of Bern) and Michaela Maier (U of Koblenz-Landau) and FKMB (the Friends of the Institute of Communication and Media Science at the University of Bern) grant “Algorithmic curation of (political) information and its biases” awarded to Mykola Makhortykh and Aleksandra Urman. Running Head: ALGORITHM AUDITING AT A LARGE-SCALE 2 Abstract Algorithm audits have increased in recent years due to a growing need to independently assess the performance of automatically curated services that process, filter and rank the large and dynamic amount of information available on the internet. Among several methodologies to perform such audits, virtual agents stand out because they offer the ability to perform systematic experiments, simulating human behaviour without the associated costs of recruiting participants. Motivated by the importance of research transparency and replicability of results, this paper focuses on the challenges of such an approach. It provides methodological details, recommendations, lessons learned and limitations that researchers should take into consideration when setting up experiments with virtual agents.
    [Show full text]