WebAssembly is a new emerging technology for the web which offers a low-level bytecode format for other languages to compile to. The aim of the technology is to effectively speed up the performance of the web, as well as to offer a way for developers to port existing libraries and code that were written in static languages such as C/C++ or Rust. The technology is currently supported in all the major browsers of today.This study takes a closer look at how the technology works and how it is compiled and executed across two of the major browsers as compared to JavaScript. Furthermore, a smaller experiment was conducted where AssemblyScript was used to compile to WebAssembly, with AssemblyScript being a typescript-to-WebAssembly compiler. The two technologies were then tested in terms of runtime performance and consistency across two browsers, operating systems as well as with different optimizations.The study showed that the technology goes through ahead-of-time-compilation and optimization through a compiler toolchain that depends on the language used as opposed to JavaScript which makes use of just-in-time-compilation. Furthermore, the fundamental structure for WebAssembly proved to be limited in order to be able to better link directly to machine code and through this offer performance benefits. The experiment conducted showed that WebAssembly performed better when it came to pure calculations but fell behind JavaScript when performing operations on an array. The reason is most likely due to the overhead of passing data structures between the two technologies. The experiment further showed that WebAssembly was able to offer a more consistent and predictable performance than JavaScript.

This thesis presents the design, implementation, and analysis of WasmProf, an instrumenting profiler for WebAssembly programs. WebAssembly is a compiled language designed for use on the web that, at the time of this writing, is still being actively developed. At present, performance analysis for WebAssembly programs mostly consists of browsers’ built-in sampling profilers. These profilers work well in many cases but only give a statistical estimation of the distribution of function calls and are, therefore, not well-suited for more fine-grained analysis. The WasmProf instrumenting profiler fills this analysis gap. WasmProf is capable of tracking the number of calls made and the time spent in every function called within the profiled program. Analysis of WasmProf demonstrates performance equivalent to or slightly better than similar tools that perform instrumentation and dynamic analysis on WebAssembly programs.

WebAssembly (Wasm) is an emerging technology for web development that has garnered significant popularity in web-based applications. It enables web browsers to execute codewritten in multiple languages seamlessly, delivering high performance across different platforms. With the introduction of The WebAssembly System Interface (WASI), facilitating the execution of Wasm beyond the confines of the web, Wasm is gaining traction in cloud computing as well. Recently, Docker introduced the support of running Wasm binaries in a container runtime using WasmEdge. This thesis investigates the performance implications and the usability benefits/issues of Wasm in container runtimes using WasmEdge compared to traditional Linux containers. To assess these aspects, two separate applications are utilized within the containers: the first application, inspired by the TPC-C benchmark, is created from the ground up to mimic a database workload, whereas the second application is WordPress, a widely adopted content management system. In evaluating the performance implications of Wasm containers, our experiments focus on gathering metrics relevant to container usage and management. These include image size, start-up times, CPU utilization, latency, and throughput differences between Wasm containers and traditional Linux containers. Additionally, we assess the usability of Wasm containers by examining aspects such as building, managing, deploying, portability, and language support. The finding of the thesis indicates that Wasm containers feature lower image sizes, up to 500% smaller image sizes than the Linux containers, and can improve cold-start times by 160%. However, due to the lack of multi-threading support of Wasm, the application performance becomes significantly degraded, resulting in increased latencies and reduced throughput compared to traditional containers. Furthermore, we underscore the portability advantage of Wasm containers over traditional ones in terms of usability. Nonetheless, the current language limitations of Wasm present more challenges than benefits compared totraditional containers.

This project evaluates the applicability of network edge computing to reduce global latencies of client applications. It determines the dimension of latency reduction network edge computing can provide compared to common cloud computing architectures. Furthermore, this project examines whether Compute@Edge, an exemplary and modern edge computing service, enables the replacement of many latency-sensitive cloud systems by an adequate versatility and a reasonable costbenefit ratio. Compute@Edge is a new, serverless edge computing platform by Fastly built on WebAssembly. A prototype that replicates a globally utilized server of Spotify was implemented on Compute@Edge. To compare the latencies of cloud and edge computing, an experiment captured the latencies of the prototype and the original system using a Spotify client that generated almost 26 million data points from all over the world. Next to the experiment, the implementation of the prototype allows accurate insights into the possibilities of Compute@Edge and whether WebAssembly is a promising approach for edge computing. Successes of this work include data showing that network edge computing can reduce latencies significantly. It offers arguments to ramp up the usage of edge computing, WebAssembly and Compute@Edge for applications that require low latencies. The results of the experiment show that network edge computing is capable of reducing network latency compared to cloud computing by at least 38%. The lower latencies combined with the versatility and feasibility of Compute@Edge show that modern edge platforms enable a much higher utilization for applications like Spotify. / Projektet utvärderar hur applicerbart nätverks edge computing är för att minska global latens av kundapplikationer. Den avgör att dimensionen av fördröjnings minskningen i nätverks edge computing kan ge i jämförelse till vanliga cloud computing arkitekturer. Projektet undersöker också om Compute@Edge, en exemplarisk och modernt edge computing service, möjliggör ett byte av många latens-känsliga cloud system och då med en lämplig användbarhet och ett rimlig kostnads-nyttoförhållande. Compute@Edge är en ny serverlös edge computing platform av Fastly, byggt på WebAssembly. En prototype som replikerar en globalt använd server av Spotify var implementerad på Compute@Edge. För att jämföra latenserna av cloud och edge computing, genomfördes ett experiment som fångade upp latenserna av prototypen och det ursprungliga systemet med hjälp från en Spotify kund som genererade runt 26 millioner globala datapunkter. Med experimentet, ger prototypimplementeringen exakta insikter till möjligheterna med Compute@Edge och om WebAssembly är en lovande lösning till edge computing. Arbetes framgång inkluderar data som visar att nätverks edge computing kan minska latensen betydligt. Det visar också argument för att öka på användingen av edge computing, WebAssembly och Compute@Edge till applikationer som behöver låga latens. Experimentets resultat visar att nätverks edge computing kan minska nätverkslatens i jämförelse till cloud computing med åtminstone 38%. De lägre latenserna kombinerade med användbarheten och möjligheten av Compute@Edge visar att moderna edge plattformar ger möjligheter till mycket mer bättre översättning för applikationer som Spotify.

This study is conducted to evaluate the Blazor WebAssembly framework for the Progressive Web Application (PWA) methodology. A comparative study is conducted with a ReactJS PWA as a baseline. The two frameworks are evaluated in their front-end performance and documentation of PWA-focused subjects. Front-end performance is measured between two experimental applications that test the loading times, heap memory usage and loading consistency during layout generation. It is found that a Blazor WebAssembly PWA takes on average a range of 0.34, 0.18, and 0.06 seconds less time to generate a layout than a ReactJS PWA. The Blazor WebAssembly PWA was less consistent in its loading times when handling many elements. Documentation that covers Progressive Web Application terminology was found to be different between the frameworks. The Blazor WebAssembly documentation covers more topics and provides first-hand knowledge while the ReactJS documentation covers fewer topics and relies on external sources to provide the necessary explanations. These findings indicate that Blazor WebAssembly is a faster framework when updating large amounts of elements in comparison to ReactJS. However, the ReactJS PWA was found to be overall more consistent in its loading times. Documentation varied between the two frameworks. Documentation in Blazor WebAssembly covers more Progressive Web Application subjects and is more in-depth than ReactJS.  This study only evaluates applications developed in ReactJS and Blazor WebAssembly. Both are tested on Google Chrome in a desktop environment.

With 92% of today’s browsers supporting WebAssembly the need for decompilers to discover malicious code is greater than ever. The introduction of the Datalog to C++ compiler Soufflé, in 2016, enables the implementation of effective Datalog-based decompilers. This thesis investigates if a Datalogbased approach to decompilation can be used to implement a WebAssembly decompiler. Such a decompiler is implemented and then evaluated in terms of decompilability, recompilabilty and semantic equivalence using randomly generated programs of various complexity. Each generated program is first decompiled, then recompiled if the decompilation was successful, and finally executed if the recompilation was successful. The results showed that the implementation can decompile all generated programs and that most of the decompiled programs are recompilable. However, only 70% of the lowest complexity programs maintained the output of the original program. As the complexity increased this percentage fell below 20%, a result of more complex programs being more likely to contain code structures that are not handled correctly. If the similarity of the decompiled programs were instead measured by recompiling the decompiled programs to WebAssembly and observing the number of instructions differing from the original WebAssembly binary the percentages were slightly more satisfying with the percentage of instructions differing ranging from 25% for the lowest complexity programs to 65% for the highest complexity programs. While the results are not distinct enough to draw the conclusion that a Datalog-based approach to decompilation is suitable for implementing a WebAssembly decompiler they instigate the need for further research on the topic, e.g. by supporting more WebAssembly instructions as well as supporting WebAssembly binaries compiled from other languages than C. / Idag stödjer 92% av alla webbläsare WebAssembly och behovet av dekompilatorer för att upptäcka skadlig kod är större än någonsin. Datalog-kompilatorn Soufflé som introducerades 2016 gjorde det möjligt att implementera effektiva Datalog-baserade dekompilatorer. Detta arbete undersöker om en Datalogbaserad dekompilator kan användas för att implementera en WebAssemblydekompilator. Detta genomförs genom att en Datalog-baserad WebAssemblydekompilator implementeras och sedan utvärderas i termer av dekompilerbarhet, återkompilerbarhet och semantisk ekvivalens med hjälp av slumpmässigt genererade program av varierande komplexitet. Varje genererat program dekompileras och kompileras sedan igen för att slutligen exekveras. Resultaten visade att dekompilatorn kunde dekompilera alla genererade program och att de flesta av de dekompilerade programmen var omkompilerbara. Däremot gav endast 70% av programmen med lägst komplexitet samma utdata som respektive ursprungsprogram. När komplexiteten ökade sjönk denna procentsats till under 20%, en följd av att program av en högre komplexitet i högre grad innehåller kodstrukturer som hanteras felaktigt. Om likheten mellan de dekompilerade programmen istället mättes genom att kompilera om de dekompilerade programmen till WebAssembly och titta på antalet instruktioner som skiljer sig från den ursprungliga WebAssembly-binären var resultaten något mer tillfredsställande med endast 25%’s skillnad för programmen med lägst komplexitet upp till 65%’s skillnad för programmen med högst komplexitet. Trots att resultaten inte är tillräckligt tydliga för att dra slutsatsen att en Datalog-baserad dekompilator är lämplig för att implementera en WebAssembly-dekompilator, tydliggör de behovet av vidare forskning på ämnet, t.ex genom att stödja fler WebAssembly-instruktioner samt genom att stödja WebAssembly-binärer kompilerade från andra språk än C.

WebAssembly is a new standard of the World Wide Web that is used as a compilation target and which is meant to enable high-performance applications. As it becomes more popular, the need for corresponding decompilers increases, for security reasons for instance. However, building an accurate decompiler capable of restoring the original source code is a complicated task. Recently, Neural Machine Translation (NMT) has been proposed as an alternative to traditional decompilers which involve a lot of manual and laborious work. We investigate the viability of Neural Machine Translation for decompiling WebAssembly binaries to C source code. The state-of-the-art transformer and LSTM sequence-to-sequence (Seq2Seq) models with attention are experimented with. We build a custom randomly-generated dataset ofWebAssembly to C pairs of source code and use different metrics to quantitatively evaluate the performance of the models. Our implementation consists of several processing steps that have the WebAssembly input and the C output as endpoints. The results show that the transformer outperforms the LSTM based neural model. Besides, while the model restores the syntax and control-flow structure with up to 95% of accuracy, it is incapable of recovering the data-flow. The different benchmarks on which we run our evaluation indicate a drop of decompilation accuracy as the cyclomatic complexity and the nesting of the programs increase. Nevertheless, our approach has a lot of potential, encouraging its usage in future works. / WebAssembly est un nouveau standard du World Wide Web utilisé comme cible de compilation et qui est principalement destiné à exécuter des applications dans un navigateur Web avec des performances supérieures. À mesure que le langage devient populaire, le besoin en rétro-ingénierie des fichiers WebAssembly binaires se ressent. Toutefois, la construction d’un bon décompilateur capable de restaurer du code source plus aussi proche que possible de l’original est une tâche compliquée. Récemment, la traduction automatique neuronale a été proposée comme alternative aux décompilateurs traditionnels qui impliquent du travail fastidieux, coûteux et difficilement adaptable à d’autres langages. Nous investiguons les chances de succès de la traduction automatique neuronale pour décompiler des fichiers binaires WebAssembly en code source C. Les modèles du transformeur et du LSTM séquence-à-séquence (Seq2Seq) sont utilisés. Nous construisons un jeu de données généré de manière aléatoire constitué de paires de code source WebAssembly et C et nous utilisons différentes métriques pour évaluer quantitativement les performances des deux modèles. Notre implémentation consiste en plusieurs phases de traitement qui reçoivent en entrée le code WebAssembly et produisent en sortie le code source C. Les résultats montrent que le transformeur est plus performant que le modèle basé sur les LSTMs. De plus, bien que le modèle puisse restaurer la syntaxe ainsi que la structure de contrôle du programme avec jusqu’à 95% de précision, il est incapable de produire un flux de données équivalent. Les différents jeux de données produits indiquent une chute de performance à mesure que la complexité cyclomatique ainsi que le niveau d’imbrication augmentent. Nous estimons, toutefois, que cette approche possède du potentiel. / WebAssembluy är en ny standard för World Wide Web som används som ett kompileringsmål och som är tänkt att möjliggöra högpresterande applikationer i webbläsaren. När det blir mer populärt ökar behovet av motsvarande dekompilatorer. Att bygga en exakt dekompilator som kan återställa den ursprungliga källkoden är dock en komplicerad uppgift. Nyligen har Neural Maskinöversättning (NMT) föreslagits som ett alternativ till traditionella dekompilatorer som innebär mycket manuellt och mödosamt arbete. Vi undersöker genomförbarheten hos Neural Maskinöversättning för dekompilering av WebAssembly -binärer till C -källkod. De toppmoderna transformer och LSTM sequence-to-sequence (Seq2Seq) modellerna med attention experimenteras med. Vi bygger en anpassad slumpmässigt genererad dataset för WebAssembly till C-källkodspar och använder olika mätvärden för att kvantitativt utvärdera modellernas prestanda. Vår implementering består av flera bearbetningssteg som har WebAssembly -ingången och C -utgången som slutpunkter. Resultaten visar att transformer överträffar den LSTM -baserade neuralmodellen. Även om modellen återställer syntaxen och kontrollflödesstrukturen med upp till 95 % noggrannhet, är den oförmögen att återställa dataflödet. De olika benchmarks som vi använder vår utvärdering på indikerar en minskning av dekompilationsnoggrannheten när den cyklomatiska komplexiteten och häckningen av programmen ökar. Vi tror dock att detta tillvägagångssätt har stor potential.

For my thesis work I have done an evaluation of the newly released Microsoft developed web framework Blazor. My methodology is based upon a couple of previous articles about evaluating web frameworks. From these articles I have gathered a number of criteria used in my evaluation: documentation, lines of code,community size, framework usage, framework maturity, framework freshness, browser support and framework cost. Additionally, since Blazor is based on C# instead of JavaScript, I have included a 9th criterion, comparing JavaScript with C#. Many of the criteria need some kind of counterpart for Blazor to be compared with, for this purpose I have mainly used the established web framework Angular, and in some cases Ember.js. When evaluating, I have not expected Blazor to exceed Angular. Rather I have counted all cases where Blazor can at least be considered comparable to Angular (or Ember.js) as favourable.I found that overall Blazor did very well in the comparison as 6 out of the 8 criteria I took from the articles evaluated favourably for Blazor. The two criteria where I found Blazor lacking were framework usage and framework maturity. While there are large numbers of showcases and example sites I did not find any large production websites developed with Blazor, and for obvious reasons the framework that was officially released earlier this year has yet to reach a mature state. Furthermore I found the extra criteria, JavaScript vs C#, was favourable to Blazor.Thus, my conclusion is that Blazor is certainly worth picking up for new projects. I argue that even though the framework is not yet fully mature it has come far in its short lifespan, and that even though Blazor is not widely used yet it is unlikely to go away considering that it is developed and supported by a large company like Microsoft.

Web applications are used more and more and mainly they are developed with the help of Javascript, but when you have heavy demanding processes in a web app, javascript can be too slow. The new language WebAssembly is an alternative that seeks to solve this problem. But unlike Javascript, there are many compilers for many different languages that have WebAssembly as their compilation goal. This means that the choice of language to compile from could make a difference when it comes to execution time. This article takes a closer look at two of the most popular languages, namely C and Rust, to see if language choice makes a difference. The differences between the languages are measured with the help of tests done between a server and a client and also with the help of an analysis of the WebAssembly code. The result shows that Rust is faster than C in matrix multiplication and insertion sort but the addition test shows that the languages are similar in speed.

This thesis is focused on fast rendering of the 3D scene in a web browser with usage of modern technologies, for instance WebGL and WebAssembly. In this thesis you will find out how to compile an application which was written in C++ language into WebAssembly via Emscripten compilator and how to insert this code into a web page. Futhermore, you will find out how to communicate between C++ language and JavaScript, how to call functions, create instances and how to share memory between them. During design of a rendering core you will learn a few methods how to improve rendering performance. In the end the performance of this technologies is compared.