Creating a Method to Evaluate Frameworks Used to Build Web Applications

Creating a method to evaluate frameworks used to build web applications

Tony Eriksson

Tony Eriksson Spring 2020 Degree Project in Interaction Technology and Design, 30 credits Examiner: Ola Ringdahl Master of Science Programme in Interaction Technology and Design, 300 credits Abstract

Single page applications are a new kind of applications, these run in almost any web-browser and can therefore use the same code-base independent of the platform that they are used on. To create a Single Page Application a framework for development is often used. Today there exists a wide variety of such frameworks, most with their own specialties and drawbacks. How well different development frameworks made to create Single Page Applications fits a project depends on the situation. This work is creating a framework to evaluate how well a development framework fits in any given project. Blazor are a new framework that can be used to create Single Page Applications. Once the evaluation framework were defined it was used to evaluate how good Blazor would be if it would be used to develop a specific application. By doing this the framework are tested and at the same time knowledge about Blazor are obtained. The work is concluded by application of the developed framework and showing that Blazor are a good fit given the scenario. This evaluation also demonstrates the power of the evaluation framework and leads to the conclusion that it is a good tool that can help strengthen decision on whatever or not to use a specific framework. Acknowledgements

I would like to express my gratitude to my two supervisors. Henrik Schafer¨ for his valuable help to get me setup and started at Vitec and for his contin- uous interest in my work. Anders Broberg for his ongoing feedback throughout this work. Contents

1 Introduction 2 1.1 Project Partner 2 1.2 Problem Description 3 1.3 Project Structure 4

2 Pre-Phase and History 5 2.1 A introduction to Single page frameworks 5 2.2 Blazor 6 2.3 Single page applications 6

3 Building a Testing Framework 7 3.1 Scalability, performance and legacy support 7 3.1.1 Summary 8 3.2 Testability and debugging 9 3.2.1 Modularity and loose coupling 10 3.2.2 Summary 10 3.3 Community and documentation resources 10 3.3.1 Summary 11 3.4 Code quality 11 3.4.1 Deﬁning Quality 12 3.4.2 Filling the criteria for Quality 13 3.4.3 Summary 13 3.5 Chapter summary 14

4 The Testing Framework 15 4.1 Scalability, performance and legacy support 15 4.1.1 Scalability and Performance 15 4.1.2 Legacy support 16 4.1.3 Numerically evaluating results 16 4.2 Testability and debugging 17 4.3 Community and documentation support 17 4.4 Code quality 18 4.5 Summary 19

5 A Theoretical Evaluation of Blazor 20 5.1 Measuring values of the framework 20 5.1.1 Context of evaluation 20 5.2 Estimating the performance, scalability and legacy support of Blazor 21 5.2.1 Expansion possibilities 21 5.2.2 Scale capabilities with regards to change in system load 22 5.2.3 Supporting the intended target group 24 5.2.4 Support for long lasting continued development 25 5.2.5 Section Summary 26 5.3 Evaluating the testability and debugging options of Blazor 26 5.3.1 Tight coupled elements 26 5.3.2 Toolset of the framework 28 5.3.3 Section Summary 30 5.4 Estimating community and documentation resources available to Blazor. 30 5.4.1 Community size 30 5.4.2 Angular 30 5.4.3 Stars on github 31 5.4.4 Value of open source 32 5.4.5 Documentation Quality 33 5.4.6 Maturity and adoption 34 5.4.7 Section Summary 35 5.5 Evaluating code quality with Blazor 35 5.5.1 Development environment support 35 5.5.2 Design pattern support 36 5.5.3 Section Summary 37 5.6 Theoretical Summary 38

6 A Practical Evaluation and implementation with Blazor 39 6.1 The value and premises of a practical evaluation 39 6.2 Testing environment and machine 40 6.3 Program ﬂow 40 6.4 The Prototype 41 6.4.1 Prototype structure 41 6.4.2 Final prototype 41 6.5 Implementation 42 6.5.1 Components 43 6.5.2 Debugging and testing 45 6.5.3 Implementation time 46 6.5.4 Implementation Result 46 6.6 Summary 46

7 Evaluating Results and a ﬁnal Conclusions 48 7.1 Results of evaluation 48 7.1.1 Summary of results from the theoretical evaluation 48 7.1.2 Veriﬁcation and Contradictions found by the Practical Implementation 49 7.2 Limitations in the work 49 7.3 Final Conclusion 49

8 Summary 51

9 Future work 52 1(54)

List of Figures

1 tight coupled class without dependency injection 27 2 loose coupled class with dependency injection 27 3 Diagnostics panel from visual studio 2019 29 4 Growth of stars over time of aspnetcore on github 31 5 Growth of stars over time of angular on github 32 6 Percentage of question tagged with Blazor on Stackoverﬂow 35 7 Percentage of question tagged with Angular on Stackoverﬂow 36

8 System specifications of development machine 40 9 flowchart visualizing interaction flow in the original application. Due to the sensitive nature of the data all names have been blurred out. 41 10 One part of the prototype displaying its structure. Due to the sensitive nature of some data all property names have been blurred out. 42 11 data-flow from parent to child in Blazor components. names have been blurred out. 44 12 A page of the final product implemented using Blazor Server. Due to the sensitive nature of some data all names have been blurred out. 47 2(54)

1 Introduction

The tech-world is rapidly changing with new techniques and methods constantly being developed and launched. This makes it possible for companies to consistently provide better and more involved experiences for their users on their homepages. When looking at web development the expectations on the user experience on tech companies homepages are high. To really stand out it is fundamental that the correct technique is chosen when their pages or web applications are built. Making a incorrect choice of the most appropriate framework for development can come with huge costs in both development costs and time spent. There is also the possibility that an incorrect choice leads to problems with framework limitations. The purpose of this work is to narrow down the risk that companies make these kinds of mistakes by proposing a method, or perhaps better worded, a framework to help guide companies in their choice of a development framework. In the making of this framework different methods and important aspects of development are explored and identified. By highlighting these parameters, they can be used as input parameters for the evaluation framework. After defining the framework, it will be applied and used to evaluate Blazor. Blazor is a framework for development of Single Page Applications. The theoretical findings are then further verified by observations and knowledge gathered from an actual implementation. By comparing the output of the framework with some practical implementations the promises made by the framework can be compared and verified by insights gathered for real implementations. By doing this, the reliability of the framework is further tested.

1.1 Project Partner

The project was performed at Vitec, in Umea.˚ Vitec is a market leading company for Vertical Market Software in the Nordic region. The group was founded in 1985 and as of today they have around 700 employees. Vitec has an interest to transfer some of their applications from native implementations onto the web by remaking them in form of Single page applications. This could have a variety of different beneﬁts. One is that maintenance of the applications over different platforms becomes easier to perform. Another is that some of the older applications can beneﬁt from newer design patterns and principles during re-implementation. Before the company moves their apps, they need to choose which underlying framework to use. Since Blazor looks like a promising framework, but is not yet a widely adopted one, more evaluations of its capabilities are needed. 3(54)

1.2 Problem Description

Vitec have an interest in exploring and evaluating the possibilities with Blazor. Evaluation of frameworks for development is currently a difficult task that requires a variety of audits and evaluations. Because Vitec, like many other software developers, develops a variety of different programs for different platforms and different target groups this task often must be repeated and redone for each new project. This work seeks to solve this recurring problem of constant, time-consuming reevaluation by creating a general testing framework for this type of evaluation. By providing this kind of framework evaluation and decisions that otherwise would be both time and energy -consuming can be optimized and performed on a much faster phase. After the evaluation framework is defined the problem at hand is solved by putting the framework to use and an theoretical evaluation of Blazor is thereby obtained. To strengthen the theoretical results that the testing framework provides, one of Vitec’s applications gets re-implemented using Blazor. By remaking one of Vitec’s existing programs they get a chance to see and evaluate some actual results of implementations done in Blazor. At the same time theoretical evidence found using the framework can be evaluated with an actual implementation as a foundation and thereby ensure the validity of the frameworks theoretical output. The research questions this paper ultimately aims to answer can be divided in to two different but highly related questions the first one is:

• Are there any beneﬁts or drawbacks of using Blazor over other frameworks when developing single page applications?

This question is especially of interest to Vitec. To answer this question a method of evaluating frameworks of this kind are needed. Without a given context there is no value in measuring if a framework is good or bad for development. All major frameworks are likely to be good if the only thing measured are how they work in general cases. therefore, in order to estimate if the framework is good for development a context describing the intended scenario are needed. There are many different sides to development and therefore when evaluating a frameworks capability all different aspects of development need to be considered. These facts are forming a second question whose propose are to provide a way of answering the ﬁrst question. This question can be formulated as follows:

• How can an objective method for evaluation of development frameworks be designed to give a context aware and complete evaluation?

When looking at development it is important to differentiate between what is produced by a framework and what it is like to produce something with the framework. What is produced are the product of work done within the framework, this is the product that is created by work within the framework. This product is a direct result of the amount of work done with the framework. Without constraints on the amount of work it is possible that a wide variety of frameworks can produce similar outputs, therefore the possible output of a framework is of less importance than the efforts needed to achieve such a result. To answer the second research, question a Framework for evaluation of the efforts needed to achieve a given goal with a given framework are going to be created. 4(54)

The development experience and efficiency of working with a framework are far more important than what can be produced by the same framework as time consummation are a key factor in most development. Therefore, the evaluation framework that are produced should be aimed at the developer’s experience and potential to carry out effective work. If the developer can be more effective, less time needs to be spent. In order to create a good testing framework all essential parts of development with the toolset that is to be evaluated must be covered. In order to ensure that the framework really covers the needs of the developer, some developers have given inputs about which areas they feel are most important. This input combined with knowledge obtained from previous studies will be making the core of the evaluation framework and have been compiled into four different main categories. These categories are as follows: “Performance, scalability and legacy support”, “Testability and debugging”, “Community and documentation resources” and “Code quality”. In chapter three, previous studies in these areas are reviewed and what the areas included is defined. In chapter 4 of this work a testing framework is defined, whose goal is to provide a toolset for evaluation of all the about mentioned areas. One goal of this work is for the new evaluation framework to be applicable to evaluate any arbitrary coding framework. Thereby this work will provide a toolset for Vitec and other companies to use when they need to decide on which framework to use during any arbitrary development.

1.3 Project Structure

The rest of this work is structured as follows:

• Chapter 1: Gives a introduction to the project and presents the project description

• Chapter 2: present the history behind single page applications.

• Chapter 3: Identiﬁes what and why different parameters are of importance during development with a framework.

• Chapter 4: Create a testing framework using the ﬁndings from chapter 3 for evaluation of frameworks aimed at development of single page applications.

• Chapter 5: makes an theoretical evaluation of Blazor using the framework created in chapter 4.

• Chapter 6: make a practical evaluation of Blazor based on ﬁndings from the evaluation in chapter 5.

• Chapter 7: Veriﬁes the validity of the framework created in chapter 4 by evaluating its resoults found in chapter 5 with ﬁndings from the practical evaluation done in chapter 6.

• Chapter 8: gives a short summary of the overall work

• Chapter 9: presents possible future work 5(54)

2 Pre-Phase and History

During this section a brief history of Single page applications and their development frameworks are given.

2.1 A introduction to Single page frameworks

The network we know as the internet is a place that is constantly evolving and changing. In 93’ the whole network contained around a million servers, ten years later this number exceed 400 million servers [1]. This growth has pushed development of tools for communication and interaction on the internet forward with a rapid speed. Basic communication techniques such as Email and Ftp where actuating tools that allowed the masses to connect and interact from all over the world. Today we have come a long way from the common web hosting models of the early days. The launch of GeoCities [11] can be seen as the starting point of when individual users got the ability to publish their own content on the web. Today this ability can be confederated given and not only are many publishing their own content, but some are also operating their own servers. With the millions of webhosts that now exists on the internet there is a constant need for tools and frameworks designed to publish and operate webpages. In the last decade, several frameworks have been developed to help the user’s create content for the web that is good looking and also have the capabilities of more classical desktop programs. This kind of webpages are often known as Single Page Applications (SPA) [20] and are probably a big part of the future of the web as they have a wide range of capabilities that common webpages lack. Single page applications can, and often are, designed and used as desktop applications. A big strength to these applications is the capabilities they must run on different devices. A single page application does not need any native code for different platforms, every platform that got a modern web browser available are able to run them. This gives this kind of application a great beneﬁt when it comes to cost of development. Single page applications are often developed on top of a framework, today there exists a few different frameworks that are open for the public to use. Exactly how adopted and used these frameworks are is hard to tell, but by looking at the star markings on Github[12] an approximation of the size of each project can be obtained. The largest ones. as of today, according to their Githubs star rating are Angular [2], React [22] and Vue.js [24]. All these frameworks are based on and programmed in JavaScript [7] (or Typescript[4], that is a subset of Javascript). This is introducing a big limitation as there exists many programmers that is specializing in backend languages other than Java. When it comes to platform speciﬁc application development C# [18] is a commonly used language. As application development are moving more and more towards web and SPA solutions there is a need for frameworks that is using other backend languages than JavaScript in order to attract already skillful application developers. This is probably one of the reasons why Blazor[8] was developed. Blazor is like Angular, Vue and React a 6(54) framework for building webpages and web-applications but differ in the backend language. Instead of using JavaScript Blazor is using C#, allowing programmers already skilled in the language to move on to web development without changing development language. Bla- zor is a completely new framework created in 2018 and built as a feature of ASP.NET[8] that extends the .NET development platform [8]. As Blazor is such a new technique little is known about its performance, usability, strength, and weakness. This missing area of knowledge is what this work is going to focused on. Getting a deeper understanding in this area not only needed to answer questions about how well the framework preforms but can also be crucial when new projects needs to decide which framework best suits their needs.

2.2 Blazor

Blazor is a completely new framework for web development focused on Single Page Ap- plications. The Blazor framework allows C# code to be used instead of JavaScript when rendering webpages. This allows for programmers that is already skilled in development of native programs in C# to move onto web-development without changing their development language and thereby preserving already existing knowledge and skills in these developers. Being able to transfer knowledge and code from other development projects opens up for a great variety of new possibilities, especially when it comes to development of single page applications.

2.3 Single page applications

Single page applications or SPA:s are applications that is developed to run on the web. These are often designed to have all their logic executed on the same web address, or a smaller collection of subpages. Another thing that make SPA:s differ from classical webpages are the more logical function execution that these often do, making them feel and look more like classical desktop applications than webpages. A core advantage with SPA:s over classical applications are the number of devices that they are able to support. As all that is needed to run them are a modern web browser there is almost no extra work needed in making them run on different systems or architectures. Classical applications on the other hand often must be completely redone to be able to do the same thing, this requires countless hours of extra work and effort. 7(54)

3 Building a Testing Framework

In order to construct a well-functioning evaluation framework, critical and universal elements must first be identified. Through discussion with well-established developers at Vitec and studies of common development patterns some important areas have been identified: “Performance, scalability and legacy support”, “Testability and debugging”, “Community and documentation support” and finally “Code quality”. By building on these areas, a good framework for evaluation from a developer’s perspective can be created. For this framework to be properly creates it is necessary to specify each of these areas on a more scientific basis and look at conclusions and methods found and used by others work on each of these areas. Only when the intentions of each area are well understood can a relevant and well-formed framework be created. The following sub-chapters intend to specify what defines each area, how they can be tested appropriately and of what importance to overall development they have. The actual Framework for evaluation is presented later in this work are derived from the knowledge obtained during this chapter.

3.1 Scalability, performance and legacy support

In the work made by Bondi A. B., -”Characteristics of scalability and their impact on performance” [5] scalability is described as a subject with two different aspects. The author defines one as ”Structural scalability”, a system’s property to be expanded without major modifications to its architecture. The other one is ”Load scalability”, how well a system preforms when the traffic is scaled up. When the assessment of whether a system has good properties or not is made, this classification of scalability suits well as it is divided into two distinct parts that each can be tested separately. in ”A framework for characterization and analysis of software system scalability” [10] the authors describe that scalability is a term that is often found in the context of computer literature but rarely is well defined, in this paper a framework for measuring scalability is presented. The authors framework is well defined but focused on a more advanced level than what is necessary for the overall per- spicuous evaluation framework that this work comprises. In their paper scalability testing is described as a multi-criteria optimization problem where this work limits it as a problem divided into the two parts previously mentioned. When looking at ”Structural scalability” a variety of sub-attributes belonging to this definition can be identified. The way in which code is written is one such attribute that also holds a great importance for the overall project. This attribute is also overlapping with some important qualities found in the ”Code Quality” part of this work. The ability to divide code into reusable parts are of great importance as this improves the ease of which the system can be scaled and the overall readability of the code. With insight that the different areas chosen inevitably to have some overlapping attributes comes an understanding that certain properties of a framework may be important in a variety of cases, and this also means that 8(54) some evaluated areas will have certain dependencies between each other. Legacy support is another term that can be seen as an attribute of ”Structural scalability”. Good Legacy support does not only mean that the framework can target and build for older architectures but also that upcoming future versions of the framework keep having good support for code designed for the current versions. The importance of good legacy support is especially valuable for long-lasting project and projects whose target group is one that is using older hardware or software. Bad legacy support might lead to a direct exclusion of a great part of the intended target group, which in turn also hinder the system’s ability to scale to its users. ”Load scalability” got a different set of attributes that is of equal importance. One of the most important attributes of this category are the ability to accept large amounts of users simultaneously. The rate of which the system load is changing depending on the current number of connected users is a good indicator of the performance of this attribute. In the paper ”The Future of Systems Research” from 1999 by John Hennessy [13] it is suggested that ”scalability is an aspect of research that should receive more emphasis in the future than performance”. Today, over 20 years after the article where published this is at least partly true, with processor performance expanding at a rate close to what is described by Moors law [21], the speed of operations are of less importance while the resource usage in terms of memory are more important. To put this in context with an example: it does not matter if a system can calculate the first million decimals of pi or calculate an optimal route from point A to point B in fractions of a second, if the same system cannot be scaled to more than one user without investing enormous resources. In most framework related cases a rule is that: if a system cannot be scaled up given a reasonable amount of resources it does not matter how good its performance is. This example illustrate how performance does not matter as much since scalability can have a more important impact on the overall performance of a system then the actual computationally performance of components in the system. Without possibilities to scale and acquire sufficient memory the system will not work or at least will not perform as good as expected.

3.1.1 Summary

Summed up, the attributes that are derived from the system’s structure and its backward compatibility and its scale factor are tightly bound to each other. A deviation in any of these areas can therefore have a large impact on all of them. To measure and evaluate these attributes it is of great importance to have a core understanding of some contextual attributes of the work. These attributes are:

• The projects expected life-cycle

• Comprehensive information about the target group and its size

• A good estimate of the potential simultaneously user-count and server load on the system. 9(54)

3.2 Testability and debugging

The IEEE definition, given in the IEEE Standard Glossary of Software Engineering Ter- minology[15] of the word Debug are “To detect, locate, and correct faults in a computer program. Techniques include use of breakpoints, desk checking, dumps, inspection, re- versible execution, single-step operation, and traces”. Even though the IEEE definition in the context of computer science are quite old the core meaning remains the same. To debug a program, process, or anything else is to use the correct tools given the context to identify and correct existing problems. In the article ”Improving the Testability of Object-oriented Software during Testing and Debugging Processes” [23] by Sujata Khatri, R.S. Chhillar and V.B.Singh Testability is described as “Testability is the probability whether tests will detect a fault, given that a fault in the program exists”. This definition of the word clarifies the importance of good testability as it establishes the link between testability and debugging. With bad testability options, the tools for debugging are inadequate and as a result debugging will not be as effective. This in turn results in it being more likely that unwanted behaviours and bugs avoid getting detected or never gets properly solved at all. This high- lights the importance of having good testability and debugging options during development. Both testability and debugging are critical parts in developing good and working products. The above statements do only describe the importance of good testability and debugging but omits the problem of actually identifying parameters and presenting ways of measuring these parameters. Identifying which parameters that is of importance when measuring these values on a generic plan that fits all cases might be impossible as different methods and frameworks are using different ways and tools for debugging. Therefore, the context of the framework that is being evaluated must decide what values and tools are of importance and which are not. In ”A preliminary testability model for object-oriented software” the authors B. W. N. Lo and Haifeng Shi try to capture what factors that affect testability in object-oriented software. Lo and Shi group these factors in to three classes, namely: structure factors, communication factors and inheritance factors. Citing the description of these factors from the authors: ”Structure factors reflect the testability of coding structure of the program segment; communication factors measure the testability of object-oriented software by the degree of coupling among classes and objects; and inheritance factors contribute to the testability via the inheritance features of object-oriented design.”[16] the similarities to factors when developing a SPA are easy to detect. Applying this model to development of SPA Structure represent the testability of the components that most SPA are constructed with. These are often modular and have a high reusablity-factor similar to parts of classic object-oriented programs. Communication can be applied in the exact same way as during object-oriented development (in fact one could argue that development of SPAs often are done in a object-oriented fashion) where the degree of couplings among components are measured. Inheritance factors are the hardest to directly fit in the context of SPA development as the inheritance features of object-oriented design do not always have to be present in the context of SPA-development even if it often are, at least to some degree. Assuming that this factors proposed by B. W. N. Lo and Haifeng Shi are a good way of measuring testability of programs created by a specific framework there is still modifications that needs to be applied as the objective with this paper is to test a framework before any actual products is produced rather than after. More specifically the goal is to test the testability and debugging potentials of a given framework, and not the testability of any 10(54) already created specific output from such a framework. By the realisations given from the previously mentioned studies it is clear that the testability framework outputs (eg. programs or completed SPA’s) are depending on the tools provided by the framework, it also seems that better support for modality is of great help when doing debugging and testing as errors more easily can be narrowed down to smaller sections.

3.2.1 Modularity and loose coupling

Modality is the frameworks ability to construct its outputs of loose coupled or completely sterile objects. This way when a bug or error is encountered the object that is producing the error can be debugged instead of the whole system. If a systems classes and object are dependent on each other they are considered to be tight coupled. systems that have a lot of tight coupled elements are in general harder to debug and make changes to since one element may produce the output of another or depend on behaviors of others. For a system to have a high grade of Modality it should have none or very few tight coupled elements.

3.2.2 Summary

This section concludes that some important areas within frameworks for better debugging and testability support are: Modality, the debugging toolset, the ability to trace errors and the degree of dependencies between components needed to accomplish tasks. Less dependencies are considered as better.

3.3 Community and documentation resources

The size of the community does not directly affect the quality of the development framework, a Framework can have almost zero adoption and still be perfectly good for complex tasks. Effects of a large community are best observed when looking at the indirect affects to developing with a framework. In the post titled ”The size of open-source communities and its impact upon activity, licensing, and hosting” [6] by Donnie Berkholz the size of development communities and their effects are studied: The author comes to the conclusion that larger project with larger communities tend to have more active communities as a whole. This statement are in line with what Dustin Marx explains in his post ”Software De- velopment Communities: Size Matters” [17] where its described how products with larger communities often are chosen by client as they tend to have a better community knowledge, be more established and therefor also be seen as safe options. Frameworks that are of an Open source nature get even more value from large communities as these project often can be partly or completely community driven meaning that there is no founding company or no paid developers that drive the work forward. In these cases, everything in terms of continued development, bug ﬁxing and documentation are in the hands of the communities. If a product is widely adapted and have a large amount of users there exists a variety of different advantages. The product itself are more tested and the chance that there exists good guides and templates are higher. When the user runs in to a problem there is a much higher possibility that someone else have had a similar problem and have provided a solution for it. The documentation is often better as its often improved by users. The list of beneﬁts can be made long and almost every aspect shows positive effects when a product has a large community. 11(54)

There are of course some negative effects as well, especially within completely community driven projects. When for example there is a need for fast changes, disagreements and different opinions within a large community can be a problem. Overall, the positive effects of a large community out weight the negative ones and a frameworks community size should have a part in its overall evaluation but that create a need for methods of measuring the size of a community. As it turns out community size is a hard parameter to measure where there exist no directly available values. In order to get a estimation of this parameter data from large internet forums dedicated to development in general can be used. One of the larger sites that fits this description are StackOverflow. StackOverflow are a site where users can ask questions and mark these questions to the area that they are related to. StackOverflow are also providing an API with functionality to count the number of occurrences of different parameters on the site. This functionality allows for counting of the number of questions asked on StackOverflow regarding a specific framework, the ratio of questions that got an accepted answer and the growth rate of questions for the framework. These values can all be used to get a representation on the size of the community. Assuming that the distribution of users coming from different frameworks are in direct correlation with the total numbers of users of the framework estimates of the frameworks total adoption can be made. With this assumption different frameworks can also be compared to each other to get a representation of the overall popularity of the framework. When it comes to measuring the overall popularity of the framework another good indicator should be the star making and activity on Github. Github are a software development platform where source-code and projects under development can be kept. Using measurements from Github only works if the framework that is to be evaluated is present on the site. Since many frameworks are open-source nowadays chances are that they can be found on Github. Grow rate and popularity are probably time dependent and when comparing different frameworks it is therefore important to measure them with data taken at the same time from launch and not just use snapshots of the current day to get proper estimates of growth rates and overall adoption. This data can also be used to project a potential future growth of the framework.

3.3.1 Summary

Summarized the important factors that should be considered to get the best possible results out of a framework can be narrowed down to: the total size of the community, weather the source-code are open source or not, the overall quality of the documentation and the maturity and adoption of the framework.

3.4 Code quality

The ability to write good code within a framework is essential for the developers that are to understand and expand the framework. It is critical for the overall development that code is of good quality, with bad code quality it is likely that a project encounter development slowdowns and suffers throughout its entire course. 12(54)

3.4.1 Deﬁning Quality

To understand the meaning of ”Code quality” it is first essential to understand the meaning of the general term ”Quality”. Quality is a rather general term and can be applied to a wide variety of different scenarios. In ”Juran’s quality handbook” [3] it is explained how the term Quality can be defined in at least two different ways that somewhat contradict each other. Table 1 is presented in this work and explains this rather well. Here two definitions for the word Quality are given that both are valid but have widely different meanings. In the context of this specific project the second definition is probably more applicable since it focuses more on development and reduced rates of internal failure. Following this definition most of the parameters of the second definition that is desired when producing code can be concluded from the list given by Table 1 as follows:

• Reduce error rates and Reduce rework waste are both related to ability to produce code with low error

• Reduce failures can derives from the ability to identify problems on a early stage before the get critical.

• Reduce inspections,tests, and audits are translatable to reduced needs of debugging and code reviving.

• Shorten time to develop new products is directly applicable.

• Increase yields, capacity correspond to a higher amount of good code produced by a developer over time.

• Improve delivery performance and Reduce customer dissatisfaction both correspond to the ability to deliver a better product with less prominent problems.

Table 1 Juran’s two definitions of quality, Juran’s quality handbook, 2017, p.50 Juran’s two definitions of quality Definition 1 Definition 2 Higher quality enables organizations to: Higher quality enables organizations to:

Increase customer satisfaction Reduce error rates Meet societal needs Reduce rework waste Make products and services salable Reduce failures, warranty charges exceed competition Reduce customer dissatisfaction Increase market share Reduce inspections,tests, and audits Provide salesrevenue Shorten time to develop new products Secure premium prices Increase yields, capacity Improve delivery performance

The major effect is on revenue the major effect is on costs Usually higher quality costs more Usually higher quality costs less 13(54)

3.4.2 Filling the criteria for Quality

If a framework got the ability to fill the previously listed criteria it can be considered to have good code quality. How can these criteria be measured then? The ability to produce code with low error can be dependent on a variety of different factors, one of these are the Testability of the code. From the previously part about testability and debugging it is stated that being able to break down code into smaller parts is an important factor to filling these criteria. Another important factor is the help that is provided by the development environment. If for example proper highlighting of code and spellchecking are provided it is much less likely that errors caused by typos appear in the code. Therefore, part of measuring code quality should be measuring the performance of the Integrated development environment (IDE) that support the framework. A good tool when it comes to detecting problems as early as possible is the ability to test the code early on. Unit testing is a form of software testing where building blocks of an application are tested on a as small as possible level, this is often done on individual components or classes. Unit testing is commonly used during object-oriented development. If parts developed within a framework can be unit tested in a good fashion the rate of failure on larger compositions of component will be reduced. Therefore, the ability to perform unit-tests or similar low-level testing should be seen as a significant criterion in any framework designed to handle larger projects. Following common patterns allows written code to be more readable and developers not familiar with the project but the pattern itself can more easily join, understand, and contribute to a project. The MVC (Model View Controller) design pattern [9] is one well defined and adopted design pattern. In MVC the code base is split into three different parts:

• Model - This is the pure data. • View - This consists of the user interface. • Controller - This is the application logic.

Some beneﬁts of using this pattern are the re-usability of code, not only in the current application but Views and Models can often easy be refactored and reused over multiply project as well. Another strength of this pattern is that it facilitated the opportunity to work in groups. Since the code is split-up developers can work in different parts without interfering with each other. There are many other well established and good patterns available besides MVC that can be used with the same result. Since these patterns provide major beneﬁts during development a criterion for a good framework should be to support, at least, one major and well adopted design pattern.

3.4.3 Summary

When looking into what is required to be able to produce high quality code some important criteria have been identiﬁed, these include:

• Support from a good IDE with tools designed to ease the overall development. • The ability to test the smallest building blocks of the product often referred to as components or classes. 14(54)

• Support fort at least one major and well adopted design pattern.

If a Framework ﬁlls all these criteria probability that it supports code of good quality should be considered as good.

3.5 Chapter summary

By examining the different areas of interest using literature and previously made studies the most significant aspect of each area is identified and broken down to its basic properties. Through this, the needs that must be fulfilled for each area to be considered as good is, is made visible. In some cases, it is shown that multiply definitions and conclusions can be drawn, here the context of this work is used as a reference to decide on which definition fits this specific context best. The depth of which each area is investigated is limited to what is seen as a reasonable level given the context of this work. One important finding during this chapter is the value of the user context, a property that is completely irrelevant in one case can thus be completely crucial in another. 15(54)

4 The Testing Framework

The understanding of what defines the different areas of interest described under chapter 3 are used to define a framework for evaluation of SPA development frameworks. Evaluation done with this framework will naturally depend on the needs of the individuals. Their expectations of the product being evaluated are of high importance for the final evaluations and conclusions that this framework is intended to provide. Being based on evaluation of individual needs the framework should not be seen as a direct guide to finding the perfect product but rather as a set of tools to evaluate what pros and cons that exists given some expectations and criteria. Conclusions made are highly contextual. The framework itself is constructed of a set of evaluating questions where the answers must be provided by the user. The framework is not designed or intended to directly provide the user answers but rather provide the correct questions given certain context. The answers are merely an indirect product provided to the user by conclusions drawn based upon the results of applying the framework. Evaluation the importance of different areas is to be done by the user with respect to their own context. To help the user facilitate this estimation, each part of the framework offers an estimated value of the area’s competence given its context. there is no requirement for this value to be used for a final evaluation, but rather it is provided as an extended tool and guideline for the importance of an area. This framework is designed to return evaluated subsets on the range from 1 to 10 in all the categories that previously have been analyzed. All results are based on individual assessments of the different areas and returns a fitting value for each context. There is no need to use this score-based system when using the structure presented in the framework, its sole purpose is to give an more comprehensible image of the evaluated objects strengths and weaknesses.

4.1 Scalability, performance and legacy support

To test how good the performance, scalability and legacy support of a system would perform if it were implemented given a framework some core values have to be identiﬁed and evaluated. In chapter 3 these values are identiﬁed as attributes. The Importance of each attribute must be weighed against the expectations of every individual project. The sub chapters provide question are derived from the information gathered in chapter 3 and are designed to catch the core concepts of each area that will be evaluated.

4.1.1 Scalability and Performance

The following two questions are designed to cover the most important parts that needs to be considered when looking at the Scalability and Performance of a framework:

• How easily can a system developed with the given framework be expanded? 16(54)

When answering this question, it is important to focus on the raw structure that the framework is using. Support within the framework for reuse of code, classes alongside with the ability to apply an object-oriented design pattern should for example be considered good attributes. If a system without much effort can be expanded upon its structural scalability it can be considered good. Since time is of great importance during development another factor that should be considered here is the amount of pre-made assets.

• How well does the framework that is to be evaluated handle an increase in load? Can a product created with the framework be expected to easily handle the expected load without the expenses for resources getting to high?

If the system can increase its load to a good value within the current context its load scalability can be considered as good.

4.1.2 Legacy support

When it comes to Legacy support, as proven in chapter 3, there are two parts that needs to be taken in consideration, one focuses on the hardware available to the intended target-group and the other focuses on how long products developed with the framework can be expected to work without major changes. The following questions takes this in consideration:

• How good are the legacy support of the out-puts of the framework and does it support the majority of the intended target-group?

• How good are the legacy support of framework itself and how well can code written against it today be expected to run in future updates?

4.1.3 Numerically evaluating results

To get a numeric evaluation of this part the questions presented can all be given an individual priority value that reﬂects the importance of the part given the context of the current framework and its expected goals. The following formula can then be used to get an overall score for this area of the framework.

(X × R + X × R + ... + X × R ) S = 1 1 2 2 n n (4.1) n10 The formula calculates a weighed mean value on the scale from 0.1 to 10. X is the evaluated score of the current question, R is the importance of the current question and S is the ﬁnal evaluation score and is the total number of questions. This formula is evaluating the questions and taking their weighted importance in consideration. The formula assumes inputs between 1 to 10 and returns a value between 0.1 to 10, 0.1 being the worst and 10 being the best. The multiplication by ten done in the denominator adjusts the score to the zero-to-ten scale. 17(54)

4.2 Testability and debugging

In order to regard a framework to have good test- and debug-abilities it, or its development environment should provide at least one working tool of debugging for each well- established method or approach used within the framework. If it is applicable to the context this tool can be reused over multiply methods. The debugging capabilities should always include the ability to test individual functions and classes, follow data ﬂows and variable values as well as easily preforming test executions separated from live environments. Even if the framework contains potential for good testability there is no guarantee that outputs of it will inherit this property as this, as shown in chapter 2 are very much dependent on the design pattern used during development. If the framework is bestowed with the above- mentioned properties it has a great foundation for potential good testability of the projects developed with the framework that is tested. The following questions are based on the conclusions from Chapter 3 and are designed to include all essentials knowledge identiﬁed during that chapter. By answering these questions, a general idea of the framework’s ability to perform in this area will be given. By giving all answers an value of 1 to 10 the evaluation function 4.1 can be used.

• Does the framework require the use of tight coupled elements to function properly? If so to what extent are this type of couplings needed?

If non or very few tight couplings are needed the Modality grade when using the framework can be considered as good.

• Dose the framework, or it’s supported development environments provide a broad tool-set that includes tools for all development that is supposed to be done with the framework?

When answering this question, the quality of the frameworks built-in debugging tools and the development environments tools should be considered. A better-deﬁned context will result in a more accurate answer for this question as developers previous knowledge of the existing debugging tool can be weighed in. If, for example, a tool that is commonly used by other frameworks or that is often used by the supposed developers is missing the frameworks score on this question should be decreased.

4.3 Community and documentation support

A good development community can have a large impact upon a development process. When running in to problems there is a high probability that there exists knowledge within a good community. The quality of the community does not entirely have to be dependent on its size, but it is reasonable to assume that there is a better probability to ﬁnd people with similar problems within a larger community. As community size and quality are a hard factor to measure it is suggested that development-oriented forums and source code repositories can be used in size estimation of communities. To get any value out of an estimation of a communities size it can be put in relation to its closest competitors. Through this one can get a insight in the adoption of the framework. By answering the following 18(54) questions an approximation of the communities overall size and quality can be done. These questions are designed based on the ﬁndings from chapter 3.

• How does the frameworks community size compare to its closest competitors?

When answering this question, it is important to remember that a frameworks adoption can be related to the time it is been available. To avoid getting false impressions on newer frameworks the frameworks current rate of adoption can be looked at. By giving all answers an value of 1 to 10 the evaluation function 4.1 can be used.

• Is the documentation well written and can the community contribute to it?

This question needs to be partly answered by individual assessment as quality of the written word are a hard thing to measure. If the documentation however does allow for community suggestions or contributions it should be seen as a positive attribute,

• Is the framework open source and can users contribute to the development?

Projects that are made under open source are not as threatened by the releasing companies continued development. A largely adopted project under open source can be completely community driven.

• How mature and well adopted is the framework?

A well adopted and mature framework should have more internal resources available and does not tend to be changing internally as much as a newer and less adopted framework. A few of the factors that can be taken in consideration when measuring these values are: the age of a framework, its overall size, how often it is used by larger parties and its user activity.

4.4 Code quality

The term ”Code Quality” refers to the possibilities that a developer is given by the framework to write high quality code and not the quality of any actually written code. Hence, it is not what is already written but rather what is possibilities to write that is of interest when evaluating a framework. The word quality can be defined in multiply ways one that fits the content of an evaluation framework is chosen during chapter 3. This definition act as a foundation for the choice of evaluation areas that is of importance when evaluation the code quality of a framework. To establish if the framework enables the user to write code of high quality these following questions are design based on the conclusions drawn in chapter 3. By giving all answers a value of 1 to 10 function 4.1 can be used for evaluation.

• Are there any development environments that support the frameworks? If so are these providing a good tool-set for development? 19(54)

When answering this question, the tools needed can be contextual and therefor the supposed context should be taken in consideration.

• Is there any built-in support for any major and well adopted design pattern? If so, do this pattern ﬁt well in to development of the supposed context?

Built-in support can be given both as a part of the framework itself or as a feature of the development environment that is used with the framework. The ﬁnal question is in many ways very similar to one of those given under the ”Testability and debugging” part of the framework, what separates them are the context of which they are asked. In some cases, the overlap of these two areas result in the questions having the exact same answers.

• Does the framework have the ability to test the smallest building blocks of the product created?

These are often the components or classes and the core of the foundation of everything created with the framework. Being able to perform tests on these makes more complex constructions easier to create as the foundation can be better trusted.

4.5 Summary

In chapter 3 the most important aspects of the following areas are identified: Scalability, performance and legacy support, Testability and debugging,Community and documentation support and Code quality. From these aspects a set off evaluation questions are presented. These are designed to include all the important aspects of each area. These questions have a high variation in value depending on the context the framework that is being evaluated is supposed to be used. Therefore, a contextual assessment on the value of each area need to be made when using the questions of this framework. Under the first part of the framework an evaluation function is presented. By assigning a priority value and then giving each question an evaluative value, this function can be used to derive a score of each area. This is supposed to give the user of this evaluation framework a better overview if the evaluated framework is suitable to their context. Some parts of these questions require the user to do individual assessments, these are a result of different needs having different criteria. For these assessments to be as good as possible it is important that the framework that is evaluated have a well-defined context of what that is desired to be fulfilled before any evaluation are done. If a framework has good results on the evaluation of these questions probability for it to be suitable to the current context can be considered high. 20(54)

5 A Theoretical Evaluation of Blazor

To properly evaluate Blazor an evaluation framework has been created. The included factors in this framework are identified in chapter 2 and with help from these the framework itself is defined in chapter 3. Previous chapters identify what is of importance with an evaluation framework and concludes that the most important factors are not what is possible to achieve within the framework but what is possible to achieve given a constraint on time. Therefore, this evaluation framework is created with the developer in mind intending that the importance of the evaluation lies in the time and difficulty to achieve a certain goal rather than the possibility of achieving or not achieving such a goal. This chapter presents an evaluation done using this previously implemented framework. Its ultimate purpose is to give a complete insight into the Blazor framework and development process used with it. It is important to note that this evaluation is solely focused on the perspective of the developer, and the capabilities of Blazor during development. Therefore, all user testing on finished products developed with the Blazor framework is excluded. When evaluating Blazor there are two different results that are of particular interest, namely what the Blazor framework is capable of in theory and how well it performs in practice. A technical result is given by evaluation using the defined testing framework. To validate the theoretical results given by the testing framework a practical implementation of an application is made in chapter 5. The experience of this implementation is then in chapter 6 used to make a validation of how well the result given by the testing framework in practice is consistent with actual implementation. The practical nature for the implementation in chapter 5 act as an extension and verification of the results given by the framework in this chapter. This result is also used as a demonstration to Vitec of both the capabilities of the evaluation framework and what a practical implementation made with Blazor may look like. The results of this part provide an answer to the second research question presented in the problem description.

5.1 Measuring values of the framework

Several properties are to be evaluated within the framework. These properties have been identiﬁed in chapter 2 and all of them can be seen as central in successful development of single page applications. A value on a scale from 1-10 are to be given as a grade on each of these properties for the framework being evaluated, 1 being the worst and 10 being the best. In the following sections the questions presented by our evaluation framework are answered with given context for development with Blazor in mind.

5.1.1 Context of evaluation

To better answer the initial question given by Vitec Blazor are to be evaluated with a context that are provided by them and is likely to be applied in a real use scenario. Vitec are looking 21(54) to build an internal web application that is created to optimize in-house workﬂows. They need this application to be able to simultaneously handle a few hundred of connections, since the number of current connections is limited to the current number of employees the applications maximal load can easily be predicted. It is important that this application easily can be connected to a database and that working with it does not introduce unnecessary loading times. Since it is an in-house application the target group can be made to use newer software and thus the legacy support in terms of running on old software are of little importance. It is however important that this application can be used and upgraded during a long period of time as they do not want to invest in an application that get outdated within just a few years. In order to better grade the property performance in some of the different areas a comparison with the native performance on c# will be used as a preference. As the areas that shall be evaluated are widely different from each other a comparison with c# will only to be used where it is ﬁtting to use as a reference for good performance. A more detailed method for each of the property comparisons are explained in the subsections of this chapter.

5.2 Estimating the performance, scalability and legacy support of Blazor

Here the questions given by the evaluation framework are answered with respect to the context that Vitec are looking to use Blazor in. The numeric evaluation provided from the evaluation framework is used in this evaluation and therefor the context is also used to decide a ﬁtting priority value for each area.

5.2.1 Expansion possibilities

This subsection aims to give an answer to the ﬁrst question given by the evaluation framework concerning the possibilities to expand upon a system that are created using the Blazor framework with regards to the current context. How easily can a system developed with the given framework be expanded? Vitec are in need of an in-house software that can be used to handle tasks needed within the company, as these kind of tasks often can vary over time the application that they are looking to build need to be able to be adapted according to the current needs. Therefor this question holds a high value in Vitecs case and is assigned the highest priority value possible, namely a priority of 10.

5.2.1.1 Components

Blazor applications can be built using Components. Components are reusable objects which when designed well does not have any hard couplings to other parts of the implementation and therefore can be used anywhere within an application without depending on any other element. Components got the ability to accept arguments and can even be stacked on top of each other allowing for complex structures. The ofﬁcial documentation describe components as ”A component in Blazor is an element of UI, such as a page, dialog, or data entry form”[8]. Having this kind of structure should allow Blazor to be very adaptable and expandable as adding, for example, a new form to a Web application should be as easy to 22(54) either reuse a already implemented Component for this purpose or simply create a new one. As components can be designed to work completely independent of each other this should not introduce any dependency problems to the program.

5.2.1.2 Library’s

Blazer is built upon ASP.NET Core with C# as implementation language, with this comes the ability to implement almost all library’s and extensions designed for this language and underlying framework. This gives Blazor the ability to use a huge variety of well- established and already implemented functions and libraries. If extensions that for example include using complex mathematical functions are needed there is a high chance that these functions can be provided by simply implementing an existing library instead of implementing them from the ground. This property of Blazor provides good possibilities of expansion if needed.

5.2.1.3 Existing ﬁeld knowledge

At the moment Blazor is a new framework that is not as well established as other frameworks with the same purpose, therefor expertise’s of development with the framework are harder to come by than for many competitive frameworks. This problem is however min- imized by the fact that Blazor are using C# as a development language. Even if Blazor speciﬁc knowledge is hard to come by C# knowledge is not. Taking the step over from classic C# development to Blazor development should not be harder than learning any other new extension library for C#. This puts Blazor in a good position where developers that can work with the framework should not be that much harder to acquire than for any other competing framework.

5.2.1.4 Question summary

Blazor applications have good capabilities of expansion since these applications can be constructed by independent objects. Having this feature allows easy implementation of new features without affecting other parts of the application. There is also a large variety of extensions and library’s available to help speed up development and ease the implementation of more complex functionality. Blazor itself do however have less available pure knowledge in terms of developers than many other frameworks since it is still new and not yet as adapted. The fact that C# knowledge easily are transfers onto Blazor helps stabilize this point of view. All this compiled puts Blazor made applications in a strong position where their capabilities to expand do not have many limits, the lack of existing knowledge do however somewhat limit the score of this question and its ﬁnal answer. Overall Blazor got good possibilities to expand and on a scale to ten it is given a score of 8.

5.2.2 Scale capabilities with regards to change in system load

This subsection aims to give an answer to the second question given by the evaluation framework concerning the increase in system load with an increased number of users. Focus are on a system that are created using the Blazor framework and with regards to the given 23(54) context. How well does the framework that are to be evaluated handle an increase in load? Can a product created with the framework be expected easily to handle the expected load without the expenses for resources getting to high? Given the current context where the application will be used for a set number of users whose amount is not expected to have any drastic increase or decrease, extreme scalability is not that important since it is unlikely to happen. However, it is important that the set expected number of users can be handled without too much stress to the system. The priority value of this part is set to 4 as it is not a main concern for Vitec if the system cannot be scaled up multiply times without an impact on performance.

5.2.2.1 Server side performance

Blazor apps can be created in two different ways, the first one are as a Blazor Server app, in this type of application all vital calculations are done on the server and there for each new connected client can be assumed to take up the same amount of processing power. On this kind of Blazor app the systems base load can be assumed to be linear with each new connected client, if the application have functions that is of a more complex nature processing spikes can be expected when these are executed from the clients. If such spikes are expected the amount of extra processing power that always needs to be available given a certain percentile can be calculated using statistics formulas. This can for example be done by first calculating the average usage time of these function each day. That is done by multiplying the number of times the operation is expected to occur with the average processing time the operation takes. By then dividing that with the total time the system is in use during a day, the total probability that the function is executed at any given time is given. Given this value it is easy to estimate the probability of something happening within a given percentile. the following expression explains this and can be used to estimate how much extra processing power that needs to be available to the system at any time. The following expression can be adjusted to fit any given percentile.

n(AT ∗ X) P ( )N < ( ) T 100 AT is the functions average execution time X is the average number of times the function is executed each day T is the total time the system is in use each day P is the percentile that’s used N is the number of simultaneously actions By ﬁnding the largest possible value of N for this expression to be true the amount of extra processing power needed can be calculated as follows:

N ∗W = E

W is the processing power needed during execution of the function one time. E is the total amount of extra processing power needed. The total amount of computing power on the server side can, as seen above, easy be estimated but applications that are using more resource intense functionality can also be pretty 24(54) heavy on the servers and often need lots of extra resources available to ensure smooth performance. Blazor do however have a way of at least partly solving this problem. This is done by creating Blazor apps as WebAssembly.

5.2.2.2 Blazor WebAssembly and client side calculations

Blazer offers to run its applications using WebAssembly, doing this allows, among other things, functions that are calculation heavy to execute on the client side, this allows the program to spread out its workload and thereby avoiding to put too much load on the server. By spreading out calculations to clients the systems created against the Blazor framework will always need to validate more sensible data that is produced on the client side to avoid having bad clients that is posting incorrect data, by mistake or intentionally.

5.2.2.3 Question summary

Blazor applications have two main possibilities when they are designed, they can chose to use the Blazor server solution, this one can be assumed to have a linear increase in load with new connected clients or Blazor can use WebAssembly to have the clients themselves do lots of the calculation and thereby ease the load on the server. In Vitec’s case were an internal application with a predictable number of users are going to use the application the solutions offered in the Blazor framework can be assumed to handle the workload without problems. If problems emerge, despite this assumption, the application can be made to use WebAssembly and even further relax the servers. Given that nothing points towards any problem on this area a full score of 10 is given to it.

5.2.3 Supporting the intended target group

This subsection aims to give an answer to the third question given by the evaluation framework concerning supporting the given target group in a system that are created using the Blazor framework with regards to the current context. How good are the legacy support of the out-puts of the framework and does it support the majority of the intended target-group? The priority value of this area is set to 10 since it is important that the whole target-group are able to run applications written in the framework in our context. This is especially important when the intended application is a tool that the company will use internally, if the target- group cannot run the software they cannot do their work. Blazor requires the web-browsers of the users to be able to run Blazor WebAssembly to properly render the webpages. Blazor servers got support for all the major browsers including Internet Explorer from version 11 the same goes for Blazor WebAssembly except for the case of Internet explorer that is not supported at all.

5.2.3.1 Question summary

In Vitec’s given context the target group is only internal users and thus the software requirements can be assured to be meet as knowledge about the entire target groups available 25(54) software and hardware exists. Given the context where it can be assured that none is using unsupported software there is no problems to ﬁll this criteria and a score of 10 is given to this area.

5.2.4 Support for long lasting continued development

This subsection aims to give an answer to the fourth question presented by the evaluation framework concerning the legacy support and future estimates of code in a system that are created using the Blazor framework with regards to the current context. How good are the legacy support of framework itself and how well can code written against it today be expected to run in future updates? Once an in-house program is financed the company expect it to preform for as long time period as it is possible. Therefor the priority of this section is quite high and given a value of 8. As internal programs don not always handle dynamic and ever-changing data there is of course cases where the program is implemented and then never needs an update, but as this cases can be expected to be relatively rare the priority in this area is kept high. Blazor is a newly released framework where only the Blazor server part has had a real release, Blazor WebAssembly is still in preview and is still getting new functions and features implemented and rewritten. This means effectively that functions that are working on this version of Blazor WebAssembly can be broken in the very next version. Blazor WebAssem- bly should therefore be avoided for larger project, at least until it is moved out of preview. Looking at Blazor server that had its first official release there is less insecurity of what functions will be kept and can be used in production. At the moment Blazor Server should therefore be seen as the only reasonable version to use for production in larger projects.

5.2.4.1 Lifespan History of related products

When it comes to judging the expected lifetime of the Blazor framework the only thing that can be done is to look at its production company and the lifespan of their other products. Blazor is created by Microsoft and therefore the company’s previously products lifespan can be used to estimate the lifespan of Blazor. One similar framework to Blazor that Microsoft have been producing earlier is Silverlight [19]. Silverlight was another framework released by Microsoft focusing on streaming media, multimedia, and graphics. Silverlight was ﬁrst released in late 2007[19] and was actively supported until early 2019. Silverlight was thus actively supported for 12 years form its initial release. Assuming Microsoft have the same ambitions with Blazor as they had with Silverlight the framework can be assumed to have support for at least the coming decade.

5.2.4.2 Question summary

Even if it is probably safe to assume that the Blazor framework will be actively supported for at least the coming years it is still undergoing a lot of changes. It is a new framework that is still getting lots of content added to it and still are missing some features. Even if code written for Blazor Server probably will be supported and working in upcoming releases there is a chance that it is getting deprecated or outdated due to new features being implemented into the framework itself. With uncertainty of how well the framework is going 26(54) to be maintained and upgraded and even if code written for the existing early releases will be compatible with later releases this area is lacking. The only thing that is accurate when giving some promises is the releasing company’s history of maintaining their products, but even this are uncertain as they may consider it a waste cost to maintain the framework if it is not widely adopted. The evaluated score of this area are set to 2, with all the previously mentioned uncertainties in mind.

5.2.5 Section Summary

According to these evaluations Blazor seems like a good fit for Vitecs intended project, even if its total score is lacking in some area, it is the areas that is of less interest given the current context. The most concerning aspect that have been identified is related to the young age of the framework. This brings up some insecurity about the frameworks persistence, it is simply not sure if the framework still will be around in five to ten years. Even if this raises valid concerns the framework makes up for these in the other areas where it is a good fit given the context. The target group are not a problem and performance should be solid, even when harder tasks are processed. The scalability of the framework is also good, especially when looking at Blazor WebAssembly that have the ability to push complex calculations on to the clients and thereby sparing resources on the server. Blazor applications being based on an object-oriented fashion in form of its Components are a good contribution and safety when looking possibilities to build upon and expand projects created in the framework. By using the weighted mean-value formula given by the framework a value of 5.9 out of 10 is acquired

5.3 Evaluating the testability and debugging options of Blazor

Good debugging options and proper ways of testing code are important parts of development. This part of the paper will look at the different ways these two frameworks handle this within Visual Studio (2019).

5.3.1 Tight coupled elements during this section the need of tight coupled elements and how they can be avoided within Blazor are explored and an answer to the ﬁrst question of this area are provided. Do the framework require the use of tight coupled elements to function properly? if so to what extent are this type of couplings needed? The priority value of this area is set to 8 as the application that Vitec is going to implement only is going to be used in-house and probably will not have any need of frequent updates and extensions.

5.3.1.1 Validations

Some minor parts of the Blazor framework are tight coupled, one example of a such part are the Validations. Validations in Blazor are tightly coupled with the ASP.net Core component system. A EditContext is shared state among many of the built in components. This method 27(54) is standard for many of the built-in components in Blazor. Components that integrate this state can have some actions done automatically. For example the EditForm component that also provides validation uses the EditContext state to activate validation on its child components (that native also uses the EditContext ). Because of this the built-in model of validation works best inside of the framework and makes the use of custom validation models harder to use. This problem is especial visible if JavaScript components are wrapped and used with the framework.

5.3.1.2 Dependency Injection

When new components are created in Blazor a dependency injection pattern can be used to avoid having tightly coupled elements. Dependency injection means that the needed dependencies of an object are injected when the object is ﬁrst created instead of more traditional instantiated by the object when it is created. Figure 1 shows how a tight coupled class is created, not that this class is creating a new instance of the ExternalService class in its constructor. This makes this class tightly coupled to the external class ExternalService. To solve this one makes the two classes loose coupled and Dependency Injection can be used. In Figure 2 the same example is presented but this time implemented with a Dependence Injection pattern. Here the instance of the external service is sent as an argument rather than created. This decouple the classes and make them loosely coupled. public class WithoutInjection { private readonly IExternalService ExternalService; public WithoutInjection() { ExternalService = new ExternalService (); } }

Figure 1: tight coupled class without dependency injection

public class WithInjection { private readonly IExternalService ExternalService; public WithInjection(IExternalService externalService) { ExternalService = externalService; } }

Figure 2: loose coupled class with dependency injection 28(54)

5.3.1.3 Question summary

There are some built in parts of the Blazor framework that on some degree are using tight coupled elements. This is mainly a problem when components that not belonging to Bla- zors built in selection are trying to achieve very speciﬁc tasks. The context of the evaluation does not require any use of previously made JavaScript components. Because of this there should be no problem for Vitec to use the Blazor framework. Using Dependency Injection Components that are created can be kept loosely coupled and are thereby easier to maintain and handle. The requirements of the question are almost fully ﬁlled and therefor the question is given a score of 9.

5.3.2 Toolset of the framework during this section the toolset provided for Blazor are explored and an answer to the second question of this area are provided. Do the framework, or it’s supported development environments provide a broad toolset that includes tools for all development that is supposed to be done with the framework? The priority value of this area is set to 10 since the options to preform debugging and run tests are of a high importance when developing larger projects. This is of especial heavy importance since the framework is relatively new and the resources on solving common problems might be limited.

5.3.2.1 The Visual Studio integrated development environment

When working with Blazor the development endowment that is used are Visual Studio. Visual Studio is a long going well established framework that got most of the standard development tools already built in. Visual Studio is also produced by Microsoft, since Microsoft is creating Blazor most of the needed tools are present within Visual Studio. Some of the included tools are:

• a diagnostics tool that allows the user to log everything from process memory, cpu usage to events and actions, Figure 3

• support for breakpoints and logging

• support for LiveShar - this allows sharing of the current Visual studio instance with other users in real time

• support for development builds to be run and updated live in the browser

• unit testing of c# objects

5.3.2.2 Unit tests

Unit testing is done on the smallest possible parts of a program, unit tests often consists of only one output and often only one input. By doing unit testing one can ensure that every individual part of a program is working and behaving as expected. Unit testing is naively 29(54)

Figure 3: Diagnostics panel from visual studio 2019 supported in Visual studio and can therefor also be applied to Blazor. Since components like the previously mentioned can be made with loose couplings unit-testing can easily be done on the c# logic of the components. If more functionality than what is provided by visual studio is desired there is a variety of extensions and improving tools that easily can be obtained by using Visual studios built in NuGet-package manager.

5.3.2.3 Client side debugging

When creating applications that is meant to run on the client it is not only the debugging of the server-side that is relevant. To properly test and create this kind of applications the debugging options that exist on the client are of high importance. Since Blazor applications can run in any newer major browser the tools built into the Browser can be used for this. Most of the major web browsers built to run on a desktop today have some standard tools included for doing this. These tools include options to look at logs, brows the structure of the page and log the rendering time of different actions.

5.3.2.4 Question summary

Blazor support is naively implemented in Visual studio and thereby the developers are able to use most of its development and debugging tools. This is a great strength of the Blazor framework. Since Vitec previously have been using Visual studio the tools and possibilities 30(54) available within the development environment are mostly known which makes Blazor a even better suiting framework for Vitec. All requirements of this area are easily ﬁlled by the framework and thus this area is assigned a full score of 10.

5.3.3 Section Summary

In this area Blazor is a perfect framework for Vitecs intended project. The framework has everything that Vitec needs and it is probably safe to assume that the part of the development that is connected to this area would work well. Blazor and visual studio provides a lot of tools that the developers already are familiar with and have good support for unit testing. By using the weighted mean-value formula given by the framework a value of 8.6 out of 10 is acquired.

5.4 Estimating community and documentation resources available to Blazor.

During development it is easy to sometimes get stuck, when this happens different sources of help are of great importance. This part focuses on what sources of information that exists around the frameworks. When evaluation the quality of these aspects the result often is a subject of opinion, to decrease this factor most of the evaluations that follow will be made based on actual data. Estimates of size are, as suggested by the framework, deﬁed in chapter 4 based on the data available from some of the large development focused websites.

5.4.1 Community size

The size and growth of the community are a indicator of how healthy the framework are, a fast growing framework have good future projections. How do the frameworks community size compare to its closest competitors? Since Vitec holds some internal resources in form of seasoned developers the importance of a large community is not critical but still beneﬁcial, therefore this question got an importance value of 7. Blazor is a relatively new framework and therefore the community size should be expected to be smaller than the one of competing frameworks where many were released several years before Blazor. In order to get a estimation of the community size the stars-rating of GitHub are listed over time and compared to some of Blazors competing frameworks.

5.4.2 Angular

Angular is a framework for developing web applications, originally based on JavaScript and later, on a typeset of it named TypeScript. Angular is like Blazor open source and can be used to develop Single page applications. Angular is supported and developed by Google, a big company with large ﬁnancial strengths and area knowledge. All these qualities are similar to the ones of Blazor and therefore angular can be seen as a main competitor to Blazor. 31(54)

5.4.3 Stars on github

Up until 9 January 2020 Blazor had a repository on GitHub that were described as a repository for ”Blazor infrastructure purposes” this description where however changed to an explanation of Blazor being moved to the asp.net core repository. The repository titled ”Blazor infrastructure purposes” had around 9 thousand stars on GitHub before the claim of the Blazor source were moved. This repository was dating back to early 2018. Currently the aspnetcore repository got around 17500 star markings on GitHub. As seen from Fig- ure 4 the aspnetcore repository have since 2018 taken a great boost in star markings. As Blazor where beginning to be publicly developed around this date an assumption that the Blazor part of the repository should be accredited at least part of this boost. At the beginning of 2019, the aspnetcore repository had about 8100 stare ratings, at the same time 2020 this number had risen to 15100 ratings. This is s rise with approximately 86 percentage. Angular went from around 42500 Star markings to approximately 56000 on the same time period, this is almost 32 percentage. Looking at the total number angular grew with around 13500 stars and Blazor with around 7000. Looking at the age instead during the years 2015 to 2016 Angular where the same age as Blazor where 2019 to 2020. Angular grew from 6600 stars to 17200 this year, that is an increase with 10600 stars or 160 percentage. Figure 5 displays the current star rating of the aspnetcore repository verses the angular one.

Figure 4: Growth of stars over time of aspnetcore on github

5.4.3.1 Question summary

Blazor have been fast growing during the last time-period but is not surpassing the total growth of Angular, while Blazor increased its stars signiﬁcantly so did Angular. As Blazor got its repository moved there is a chance of the displayed values giving a to low indication 32(54)

Figure 5: Growth of stars over time of angular on github of Blazors total rating. Even though Blazor is not as fast growing as Angular the framework is still fast growing. Since it is a very young framework chances are that it will grow even faster over the years to come. In this category the Blazor framework is thus given a score of 5.

5.4.4 Value of open source

One great thing with open source are that users are allowed to inspect and build upon the code base, this gives the users of the framework a safety that even if the framework are discontinued by the creators it can still be maintained by community driven development. Are the framework open source and can users contribute to the development? The importance of Blazor being open source given our context is not critical and therefor the priority of this section is set to 5.

5.4.4.1 Open source

Blazor is an open source project and do allow users to suggest improvements or even fork their own copies. The Blazor source is found on Github.com under the aspnetcore repository. Here users can contribute to the code by creating pull requests. All the code related to Blazor can also be read on this page. 33(54)

5.4.4.2 Question summary

Blazor is open source and allows for bout user contribution in form of pull requests and user clones in form of forks on GitHub. This gives Blazor a score of 10 in this area.

5.4.5 Documentation Quality

The quality of the documentation can help solve problems and provide answers to otherwise hard tasks. Therefore, the quality of the documentation is of importance during development. Are the documentation well written and can the community contribute to it? This question aims to evaluate the documentation of Blazor, to get a better evaluation some comparisons to the documentation of Angular are made. The quality of the documentation is an important factor when developing using a new framework and therefor this area got a priority value of 10.

5.4.5.1 Documentation evaluation and comparison

The Blazor documentation is part of the ASP.NET Core Documentation and is therefore written as a sub-tree of this. The documentation of Blazor do allow users to suggest edits, this is a good feature as the documentation is likely to get a better coverage. The documentation of Blazor got a total of 30 categories including some templates, tutorials, and examples of more advanced scenarios. Comparing this to the documentation of Angular the angular documentation got more than the double number of objects in its structure tree. Angular provides an entire section with examples of good techniques, a deep explanation of its fundamentals and even suggestions on workflows. Even though the size of the structural trees of Blazor compared to angular does not tell the complete truth IEEE [14] have some described guidelines of ”program testing” documentations, some of which can be directly translated and applied to this kind of documentation. On the subject of keeping the data at the correct places in order to keep the documentation clean IEEE states that ”There is no need to copy the content of approved work instructions and system manuals into test documentation. Relevant sections of such material can be referenced in test documents and then copied for use during test activities as needed ” - this describes how information of a non-lethal nature that got its foundation in an outside source don’t need to be repeated but can only be referenced. Blazor whose documentation are quite compact do use this method defined by IEEE and do reference to external resources for extended reading in many areas. I do however personally feel like the Blazor documentation could have been more extensive and given better examples in some areas. A section for examples of good workflows or more examples on good practices when doing common tasks would have helped improve the overall documentation experience.

5.4.5.2 Question summary

The Blazor documentation is allowing user edits and can therefore be driven forward by the community. The overall impression of the documentation gives a feeling of it being very compact and only focused on the basics. Compared to the documentation of angular it 34(54) is lacking in the amount of advice and good practice examples that is provided to the user. Since Blazor is a new project it is likely that the documentation will get improved over time, but as of now it is missing some parts that would have been nice to have. Because of this the section is given a score of 5. The documentation is existing and complete on a basic level, but is lacking on its extended features.

5.4.6 Maturity and adoption

Maturity and adoption of a framework are in direct relation to the amount user generated resources that is being put out for that framework. A well adopted framework can be assumed to have much user generated content such as questions and answers, tutorials, templates and more. How mature and well adopted are the framework? Having access to the beneﬁts that comes with a mature and well adopted product are of great value during development with a new framework. Therefore, the importance of this question is set to 8.

5.4.6.1 Maturity and adoption

To get an estimate of the maturity of the framework data related to the framework from Stackoverflow is used. To get a perspective on the size this data is compared with the one of Angular. At the start of 2020 the number of questions marked with Blazor where about 0.13 percentage as shown by Figure 6 at the same time the number of questions asked about angular where around 2.75 percentage as shown in Figure 7. the number of angular related questions asked on Stackoverflow where 21 times as many as those asked about Blazor. This indicates a huge difference in the number of active users among the two frameworks. The current trend of questions asked indicates that Blazor have been seeing a large increase in questions asked, this is probably due to the framework being newly released. The total numbers of questions with one or more answers tagged with Blazor on Stackoverflow are 1886. The number of questions that have not yet got an answers are 492. This means that 79 percentage of the questions regarding Blazor have gotten an answer. The percentage of questions that got at least one answered tagged angular are 80 percentage. This indicates that the user activity of Blazor in percentage are as good as the one of angular despite it being much smaller in its total number.

5.4.6.2 Question summary

Blazor is much smaller and much less adopted than Angular and this is probably due to Blazor being a new framework. When looking at the activities within the two communities it can be seen that Blazor got almost the same percentage of answered questions indication that the Blazor community is an active one. One other factor that looks promising for Blazor is the rise in activity that can be seen in Figure 6. This shows that since the framework where released it have started to gain more users and thus a better adoption. Since Blazor still is lacking in adoption compared to its competitors but shows great promises for the future this question is assigned a score of 7. 35(54)

Figure 6: Percentage of question tagged with Blazor on Stackoverﬂow

5.4.7 Section Summary

Blazor is a new framework and this is something that can be seen when looking at community and documentation resources available to it. Compared to its main competitors Blazor are still rather small but do however show some signs of great future adoption. Estimates during this section have been made from data given by some major development sites and might therefor not give a perfect description of the current situation. The frameworks total score in this area shows that Blazor probably would be okay for Vitec to use even if there might exist better options in this area. The total score in this area are 4.78 out of 10.

5.5 Evaluating code quality with Blazor

To write code of high quality is often of great importance for the performance of the program. In order to write good code, there is some criteria that need to be filled. This section takes a look at how well the Blazor framework fill these. The third question given by the framework are in our context exactly the same as the first question of the ”Testability and debugging” section and are therefore omitted. Results for this question can be taken directly from the first question of the ”Testability and debugging” section.

5.5.1 Development environment support

The development environment can make a major difference when it comes to the quality of the code written within the framework and are therefore of high importance. Are there any development environments that support the frameworks? If so, are this providing a good toolset for development? 36(54)

Figure 7: Percentage of question tagged with Angular on Stackoverﬂow

The development environment that is supported is of a high importance for Vitec as their developers already have knowledge in some environments. This section has a priority of 10.

5.5.1.1 Supported development environments

As already mentioned under the part ”Evaluating the testability and debugging options of Blazor” of this chapter Visual studio are supporting Blazor. Apart from visual studio there is not any other real options of development environments available. As the logic of Blazor are written in C# all environments supporting C# can support parts of the development but to get a complete experience with a full set of tools visual studio are needed.

5.5.1.2 Question summary

Work with the Blazor framework are bound to be done inside of visual studio. Except from this environment no options with complete support where found. This hard constraint on a development environment can be a problem when in some cases but are not in the context of this evaluation. Visual studio is already an established tool at Vitec and thus this area are given a full score of 10.

5.5.2 Design pattern support

Design pattern can be of good use when writing readable code, especially for larger project that involves many simultaneously developers. Are there any built in support for any major and well adopted design pattern? if so do this pattern ﬁt well in to development of the supposed context? 37(54)

In the context of this evaluation the beneﬁts of a good design pattern are not critical as it is a project that does not need to involve that many developers. Thus, this areas priority are set to 5.

5.5.2.1 Model-View-Controller

Model-View-Controller(MVC) is as mentioned under chapter 3 a design pattern commonly used during soft development. This design pattern splits project in to three different parts:

• Model - This is the pure data.

• View - This consists of the user interface.

• Controller - This is the application logic.

5.5.2.2 ASP.NET Core MVC and Blazor

The Model-View-Controller design pattern is included in ASP.NET CORE MVC as its own framework. Projects made using this framework can include Blazor. Making an MVC Blazor project are possible but to get a good-looking structure, Blazor components should probably be kept separated. Doing this separation would result in deviations from the structure of a clean MVC design pattern.

5.5.2.3 Model-View-ViewModel

Model-View-ViewModel (MVVM) as a design pattern that separates the development of the back end (module) from the graphical user interface (view) making the view independent. In MVVM the ViewModel is converting values from the model so that they are easy to handle for the view. this design pattern is possible to apply to Blazor. Doing so all Blazor speciﬁc code is wrapped to the ViewModel. Html elements can then be bound to properties of the ViewModel.

5.5.2.4 Question summary

Blazor can be implemented using various well-known design patterns, some examples include both MVC and MVVM. ASP.NET Core MVC that on its own is a framework built upon the MVC design pattern can be combined with Blazor code but is easier to understand with some minor structural differences in its layout compared to classic MVC. As common design patterns can be applied to Blazor, even if they sometimes need minor changes, the performance of Blazor is good in this area. Therefor the score of this question are set to 8.

5.5.3 Section Summary

Code quality within Blazor is overall good, the fact that Blazor is supported by Visual studio open a variety of options bout for debugging and good structuring of code. Blazor can also be implemented using many different design patterns without much effort. The results given 38(54) by this section are well ﬁtting for the context and thereby Blazor is probably a good choice for Vitec with regards to the current area. The ﬁnal score of this section is 7 out of 10.

5.6 Theoretical Summary

When applying the evaluation framework an image of Blazors match with the current context is given. From this it is shown that Blazor probably would perform good if it were to be used for the intended implementation. Some areas gave a better result than others and areas where the framework probably would perform especially good are ” code quality” and ”testability and debugging options” . The area where most problems probably would be seen are in the ”community and documentation ” section. The main problem within this area where the relatively low number of adoption of the framework. There where however indicators pointing towards this changing over the upcoming years. The root to this problem could be traced to the framework being relatively new. 39(54)

6 A Practical Evaluation and implementation with Blazor

By merely observing and making theoretical evaluations important observations about practical parts of the framework can easily be missed. By making an actual implementation with the framework a complement for the theoretical results are created. By conducting a practical implementation experiences and conclusions about how it actually is to work against the framework through various stages of development is obtained. When using these results a more complete evaluation of Blazor as a framework can be drawn. Results and conclusions from this evaluation can later be compared to the results given by the theoretical evaluation preformed in chapter 5 and then used to evaluate the precision of the evaluation framework that where presented in chapter 4. For this evaluation to be as good as possible the development context given during the theoretical evaluation in chapter 5 are in this chapter implemented and used for the evaluation.

6.1 The value and premises of a practical evaluation

As there is no standardized way to measure this kind of tasks and therefore the overall experience are evaluated through individual assessment. The results of this part can be seen separately from the ones based on the theoretical framework given in chapter 5. This part of the work is containing evaluations that is a subject of opinion. This part still holds a value as it complements the theoretical evaluation. By doing an implementation and looking at the framework from a developers point of view there is a chance that problems not before visible are discovered. The application developed during this section are a re-implementation of an outdated application used in-house at Vitec, this application is the same as the one described as the evaluation context during chapter 5. The implementation during this part are to be handed over to Vitec and should be seen as a ”proof of concept” of the capabilities of a Blazor Server application. In order to get good possibilities for evaluation and at the same time deliver a product that can be seen as a ”proof of concept” to Vitec the development process where preformed using the following Steps:

• A interaction ﬂow of the old application is identiﬁed by interviewing users.

• A prototype is created and demonstrated to users at Vitec.

• The application is implemented.

Doing implementation this way allows for errors in user interaction as well as program design can be spotted and corrected before the actual implementation. By designing a pro- 40(54) totype based on what where found possible by the theoretical evaluation in chapter 5 goals of the actual implementation can be created and later evaluated. limitations by the framework and other elements that contradict the results from chapter 5 are easier to identify when set goals are given before implementation. An alternative to this would be to implement functions with a ”design on the go” basis, this would allow difﬁculties to be missed as there would be no hard restrains on what to implement given by the approach. Following this implementation steps also provide a way of measuring the efforts needed to achieve a given goal within the framework. As the program that have been re-implemented are rather large only a chosen subset of its functionality is actually implemented.

6.2 Testing environment and machine

The device and environment used during this evaluation can have an impact on the results in terms of performance. In order to not get any variations depending on this all of the implementation are done on the same machine and in the same development environment. All evaluation and implementation made will be limited to a Blazor Server project used with Visual Studio (2019). Blazor server where chosen as it has had a stable release compared to Blazor WebAssembly that is, at the point of writing, still in preview. The machine that used got its speciﬁcations in Figure 8.

Processor: Intel Core i7-8700k @3.7GHz Ram: 32GB OS: Win 10 x64

Figure 8: System speciﬁcations of development machine

6.3 Program ﬂow

In the fifth appendix named ”QUALITY IMPROVEMENT TOOLS” of Juran’s Quality Handbook by JURAN, J. M., GODFREY, A. B. (1998) [juran98] some tools are defined, one of these are Flow Diagrams. Flow diagrams are defined as ”A graphic representation of the sequence of steps needed to produce some output. The output may be a physical product, a service, information, or a combination of the three”.When creating a graphical illustration of the program flow the core ideas of this definition where used. The flow of the old application are captured in a flowchart (or flow Diagram), as seen in Figure 9. This gives a good estimate of how complex the application really is. In Figure 9 the start page of the program is marked in green after that sub-pages are marked with yellow and functions with blue. As seen from Figure 9 the complete application is rather large and it is unreasonable to assume that all of it can be implemented given the time restraint of this work. This type of diagram did however also allow for identification of parts that where reasonable to actually implement in a newer version. This flowchart maps interaction of all functions and are used to identify the once that are essential for the program to function properly. These are then chosen and included in the prototype and the final implementation. This flowchart 41(54) can also be used to identify if there are any potentials for optimization in the program flow. without going into details about them such found optimizations are applied to the flow of the prototype.

Figure 9: ﬂowchart visualizing interaction ﬂow in the original application. Due to the sensitive nature of the data all names have been blurred out.

6.4 The Prototype

Before building an application, prototyping is important. This part aims to evaluate how difﬁcult it is to create prototypes that matches capabilities and look of Blazor applications. The goal of the prototype is to give an illustration of what an implementation would look like. As Blazor apps essentially only are homepages any application capable of prototyping a homepage can also be used to prototype a Blazor application. The application chosen to produce the prototype there photoshop, this choice where only based on my own existing knowledge about the application and that this application where available.

6.4.1 Prototype structure

As indicated by the evaluation in chapter 5 Blazor should have good support for loosely coupled components therefor the prototype where built up of a variety of different layers of component. This design focused on reusing the same component multiple times, this where done as the theoretical evaluation where showing that Blazor should have good reusability of its components.

6.4.2 Final prototype

The resulting prototype consists of only 4 different components. A shown by the evaluation in chapter 5, These should be able to be loosely coupled and thereby repeated across the 42(54) implementation multiply times. The components that the prototype is built up of are:

• A frame - This component is a frame for other components and are used to achieve a uniform look of the entire application.

• A list - This component where made to accept an object and display a list of its properties.

• A Text display - This component where to display and edit information about an object in a nice fashion

• A navigation bar - This are used to navigate and present information

Apart from these components some components from Blazors already included components where used. Figure 10 are displaying part of one view of the prototype. In this image the layout of the four different components are visualized.

Figure 10: One part of the prototype displaying its structure. Due to the sensitive nature of some data all property names have been blurred out.

6.5 Implementation

An actual implementation is made using Blazor, this implementation is aimed too closely resemble the Prototype. The methods used here are closely tied to the processes identiﬁed during the theoretical evaluation. This part is used to get a more practical understanding of the developers perspective when using Blazor. By re-implementing an actual software Vitec and others can gets an insight of what development with the framework actually looks like on a more practical premise. 43(54)

6.5.1 Components

In the prototype some different components where created these are now implemented in a Blazor Server project. apart from these some built in components where used during the implementation. implementation of these components is aimed to reassemble the look of the prototype while also using the theoretical ﬁndings from chapter 5. In chapter 5 Blazors ability to create loosely coupled components where highlighted and therefor all components implemented are created to not contain any hard couplings.

6.5.1.1 Custom components

All components specified by the prototype where also implemented. To get a cleaner structure of the codebase all logic where decoupled from the rendered parts of the component. This where done by creating separate C# files for the logic and make them inherit the Com- ponentBase object. This allows for the razor view (that now have no C# code) to inherit the logic. Razor is the format of which Blazor html pages are saved. To achieve what where specified in the prototype some of Blazors built in functions where also used.

6.5.1.2 Built in components

The implementation made use of some Built in components. The built-in components that were used are:

• NavLink - This component is used for the applications navigation bar. It enables navigation within the application and are used in the default layout of a new Blazor project.

• EditForm - This allows do bind input values to properties on a model, using this component also gives access to calling functions on submit of forms

• DataAnnotationsValidator - This component attaches validation support using data annotations, data annotations need to be deﬁned on the models for third component to have any effect.

• ValidationSummary - This component summarizes validation messages by displaying a message for the user.

• Input components - These are a set of components for handling different types of input, for example strings, Integer and Boolean.

Most of these components are using the shared editcontext state for communication. An example of this is the EditForm component who allows for validation parameters to be automatically passed between components over branches in its hierarchy.

6.5.1.3 Communication in component hierarchy

Communication Between components can be done on a variety of different ways but are often done from the parent to the child. There are ways of communicating with the parent 44(54) from the children, but these are more limited than the other way around. bindings and two- way bindings allow for either binding a parameter in the parent to a function in the child or the other way around creating a binding from the child to the parent. bindings and two way bindings can be used for communication but as these creates tight couplings this method of communication have been avoided where it’s not needed as the theoretical framework pointed out that almost only loose bindings should be an alternative. To send data down a component hierarchy can easily be done by letting components accept parameters upon creation or by using cascading values. Cascading means ”flowing downstream” and as the name indicates cascading values can only be sent from a parent to its chills, not the other way around. Figure 11 illustrate the standard data-flow of Blazor component communication without tight couplings. To follow the requirements of the prototype a child at a depth of N needed to update its root parent. Blazor got no built-in function that achieves this without using tight coupling. To achieve this goal an Interface where used in combination with an optional reference to the root parent of the child. By letting the child do a check on whether or not the parent is an instance of the interface lets the child execute interface defined functions presents in the parent. This way data can be passed from the child component to the root parent without tightly coupling the two.

Figure 11: data-ﬂow from parent to child in Blazor components. names have been blurred out.

6.5.1.4 Identiﬁed problems

The use of interfaces for communication upwards in the component hierarchy without creating hard bindings are a bit problematic when trying to create a clean code structure. This can also be a problem as the child component are checking if the interface exists and if so, are blindly executing its functionality. The problem with this is that functions that is not meant to be run can be executed anyway. The risk of this happening in smaller projects are however minimal and it never where a problem during this development. 45(54)

6.5.1.5 Summary

Custom components where implemented and used alongside some built in components. the application has a need of communication between children and their root parent. To solve this without creating and dependencies or tight couplings interfaces where used.

6.5.2 Debugging and testing

Debugging and testing are expected to be easily done from the results given be the theoretical evaluation. During the development, some different kinds of debugging where done and the tools provided for this where used.

6.5.2.1 Solving problems

The most common problem are typos, or missing references, this kind of problems generate an error when the program is test run and can from this be traced back to their origin. This trace is often exact and when for example a library is missing visual studio are often able to suggest the correct one. Another type of problem is those that causes crashes. This can be produced by almost anything and even these are easy to locate in visual studio as they produce a stack-trace that displays where the crash happened and what lead up to it. Visual studio got a function that often are able highlight the function or code line that caused the problem. The most difﬁcult kind of bug to solve are the logical bug. this kind of bugs don’t pre- vent the application from running and often don’t make the application crash but produce a unpredicted behavior in the application itself. To solve this kind of bugs breakpoints, debugging prints and variable watches have been used. these tools allow the developer to follow the ﬂow of data in an application an thereby identify when values of functions are producing incorrectly results.

6.5.2.2 Finding solutions in the community

In some stages during the implementation, questions arose that needed to be answered by either documentation or community support. During these stages there where some difficul- ties to find good information. On some subject there were even contradicting answers given. This made help from outside sources hard to find and relay on during the implementation.

6.5.2.3 Summary

Debugging in Visual studio and Blazor are effectively done by the tools provided with visual studio. Using these tools even the hardest kind of bugs can be traced and solved. Finding help from outside sources are a harder task and when information is found its often unclear if it is good or bad. 46(54)

6.5.3 Implementation time

On variable that hare hard to estimate with the theoretical framework are the time it takes to actually do any implementation. This is estimated here based on the development that have been done with the implementation.

6.5.3.1 Reuse of knowledge

Blazor are using C# as a development language as I already possess knowledge in this language much of my already acquired knowledge can be directly transferred on to this development. This is an internal power of Blazor and could be applied to everyone coming from C# development.

6.5.3.2 Time to learn the basics

In my case I learnt the basics of Blazor development in about a week by reading and following the examples provided with its documentation. I was also using some community generated content from various sources. After learning the basics development could be made at the same rate as usual C# development. The support for known design pattern and the fact that I already knew Visual studio and many of its built-in tools contributed to me being able to implement the prototype with a relatively good development speed.

6.5.3.3 Summary

If the developer has previously knowledge with C# basic development with Blazor should not take much time to learn. A great strength of Blazor is its ability to reuse knowledge acquired by previously C# development.

6.5.4 Implementation Result

The result of the implementation is an application that closely resemble the prototype. This application where put together by using the previously named components. One of the views in the application are displayed in Figure 12. Data used in the application are fetched from an external database. In Figure 12 it can be observed how the different component have been composed together to produce a ﬁnal product. As these components are loosely coupled, they can easily be rearranged and replaced if needed.

6.6 Summary

First a data-flow where identified and visualized of an old application, this flow where then used to create a prototype of an new application. This prototype where created based on theoretical knowledge about what where possible provided by the theoretical evaluation that were made in chapter 6. The prototype where den implemented using a Blazor server solution. As parts of this implementation some custom components where created and communication on a loosely coupled basic where applied to these. Some of Blazors built 47(54)

Figure 12: A page of the ﬁnal product implemented using Blazor Server. Due to the sensitive nature of some data all names have been blurred out. in components were also used during this development. During the development, some different kinds of debugging had to be done and some of Visual Studios tools for debugging where used. Besides this a smaller estimate of the time requirements to start development in Blazor are made, this estimation is performed on an individual basis and don’t necessarily hold true for everyone. in the ﬁnal part of this chapter the resulting program are displayed. 48(54)

7 Evaluating Results and a ﬁnal Conclusions

This work where aimed to answer two research questions and by doing so have resulted in:

• A framework for evaluation of development frameworks aimed at single page applications

• A theoretical evaluation of Blazor using this framework

• A practical evaluation of Blazor based on promises made by the theoretical evaluation of Blazor

During this chapter the results of each part of the work are presented. These results are then used to verify the validity of the evaluation framework. Then limitation of the overall work is presented and discussed and lastly a ﬁnal conclusion about the work are made.

7.1 Results of evaluation

A summary of the theoretical results is ﬁrst presented. The results from the practical implementation are used with these results to prove that assumptions made by the framework can be veriﬁed or contradicted.

7.1.1 Summary of results from the theoretical evaluation

The theoretical evaluation is using the framework deﬁned in chapter 4 to evaluate four different areas of working with the framework. Each of these areas are given an evaluated value on the range 0.1 to 10. The different areas that are included in the framework and their respective score are as follows:

• Scalability, performance and legacy support who got a score of 5.9

• Testability and debugging who got a score of 8.6

• Community and documentation support who got a score of 4.78

• Code quality who got a score of 7

Under each section the different reasons for these ﬁnal scores are discussed and explained. It is important to remember that the context of the framework being evaluated have a major roll. 49(54)

7.1.2 Veriﬁcation and Contradictions found by the Practical Implementation

During the implementation one goal where to keep all components loosely coupled. This goal where created from the conclusions made in the theoretical evaluation. This goal where archived and during the implementation all the components where kept independent of each other. Even if this goal where achievable it took some effort to get the implementation working. Another area that where tested during the implementation where Testability and debugging. This area got a score of 8.6 in the Theoretical evaluation and where therefore expected to work without problems. This where veriﬁed as all debugging and testing where preformed without any problems. During the implementation some help where also taken from outside sources. In the theoretical evaluation Community and documentation support where the most lacking area something that where reﬂected when taking this help. On many of the areas where help or documentation support where needed the documentation where lacking or the community resources where absent.

7.2 Limitations in the work

The extent to which the different areas of the evaluation are explored could have been broader and included more factors. An example of such a factor that the evaluation framework is completely leaving out are the time constraint of implementations. Measuring and getting an estimate of the time that a framework requires to achieve a set goal could have been a nice contribution to the frameworks and its evaluations. The evaluation framework is only practically tested by doing an evaluation of Blazor. If more time where given this could have been extended to some more frameworks. If the results continued to be consistent in terms of evaluation quality this would have improved the trustability of the framework. Another limitation and weakness in this work is the limited user testing that is done with the framework. As all the testing are done by me there is a risk of a bias in the results. There is also the possibility that more testing would yield different results from the once seen in this work. This could have been avoided by doing more testing with different users. This where not done due to the time-limitation of the work.

7.3 Final Conclusion

The research questions that this work aimed to answer where How can a framework for evaluation of development frameworks be designed to work with arbitrary test cases with a good result? and Is there any benefits of using Blazor over other frameworks when developing single page applications? The first question is ultimately answered during chapter 3 and 4 where a framework for this kind of evaluation is defined. This framework is creating by looking at different aspects of various areas of development and finding key values for these. These key values are then used to construct questions that involves all the importance of every area. The second question are then answered by using the created framework to evaluate Blazor. This evaluation has a dual purpose, firstly it made to answer the second research question and secondly 50(54) its done to produce some theoretical results from the defined framework. To further prove the validity of the results given by the evaluation framework a practical implementation of the Blazer application used as a context during the evaluation are done. Results from this implementation are almost conclusively in line with the expectations given by the evaluation done with the theoretical framework. This proves that the theoretical results given by the framework defined in chapter 4 are consistent with the practical experiences obtained by a real implementation. This are in conclusion proving that a theoretical evaluation with the framework provide enough information about what can be expected on its own. Any practical implementation in evaluation purposes are there by redundant if the evaluation framework has been used correctly. 51(54)

8 Summary

The overall work includes everything from drawing conclusion from literature to creating a prototype and implementing it. the size of this work where mostly limited by the time constraints given for the project. without this limitation the project would probably have been even larger. During this work in chapter 3 the requirements of what defines a good framework for developing Single Page Applications (SPA) where first identified. Then in chapter 4 these requirements where used to create a framework for evaluation of frameworks for development of Single Page Applications. After this work where done the created framework where applied to Blazor during chapter 5. In chapter 6 the results of the evaluation where used to create a prototype that defined the properties of an actual implementation. An actual implementation where later also done based on the prototype during this chapter. During chapter 7 the work done in chapter 6 are used to verify the results given by the framework. The process and structure of this work have been meant to first produce a result and then verify or contradict this result to strengthen or disprove it. During chapter 7 the previously results of the framework end up being proved and thereby strengthening the believably of the framework. The second research question where ”How can an objective method for evaluation of development frameworks be designed to give a context aware and complete evaluation?”. The framework that are created in chapter 4 and verified to be working in chapter 7 are ultimately also the answer to this question. By using this framework, we can make an evaluation of a framework and evaluate how well it would work in any given context. This is exactly what the question is asking about. The first question where: Are there any benefits or drawbacks of using Blazor over other frameworks when developing single page applications?. This question can now be answered by applying defining a context for which Blazor should be used and then applying Blazor to the evaluation framework. By doing this a complete image of the strengths and weaknesses of Blazor within the specified context are given. Exactly this are done during chapter 5. If the results where to be compared to any other framework the evaluation framework could be applied to these as well. 52(54)

9 Future work

This work can be extended in several ways. One that probably would provide much value would be to extend on and reﬁne the questions that the evaluation framework is built upon. These could probably be made to include even more properties of development. To verify the results provided by the framework some more evaluations beyond the one made of Blazor would need to be done. Even if the results of the practical evaluation of Blazor where in line with the results of the framework there is no guarantee that this holds true for other frameworks as well. By doing more evaluations the conclusions given by the framework can be strengthened. 53(54)

Bibliography

[1] Internet Systems Consortium (ISC). “Internet Systems Consortium webpage”. https://web. archive.org/web/20120518101749/http://www.isc.org/solutions/survey/history (visited 2020-05-13). [2] Angular. “the Angular Docs”. https://angular.io/docs (visited 2020-05-12). [3] Anon. Jurans quality handbook: the complete guide to performance excellence Sev- enth edition. New York: McGraw-Hill Education, 2017, pp. 46–50. [4] anon. “TypeScript”. https://www.typescriptlang.org (visited 2020-04-12). [5] Bondi A. B. “Characteristics of scalability and their impact on performance”. In: 2nd international workshop on Software and performance ISBN 1-58113-195-X (2000), pp. 195–203. [6] D. Berkholz. “The size of open-source communities and its impact upon activity, licensing and hosting”. https://redmonk.com/dberkholz/2013/04/22/the-size-of-open- source-communities-and-its-impact-upon-activity-licensing-and-hosting/ (visited 2020- 05-10). [7] MDN web docs. “JavaScript Documentation”. https://developer.mozilla.org/sv-SE/docs/ Web/JavaScript (visited 2020-05-12). [8] Microsoft Documentation. “Blazor documentation:Components”. https://docs.microsoft.com/ en-us/aspnet/core/blazor/?view=aspnetcore-3.1 (visited 2020-04-16). [9] Microsoft Documentation. “MVC pattern int ASP.Net Core”. https://dotnet.microsoft.com/ apps/aspnet/mvc (visited 2020-04-20). [10] L. Duboc, D.S. Rosenblum, and T Wicks. “A framework for characterization and analysis of software system scalability”. In: Proceedings of the 6th Joint Meeting of the European Software Engineering Conference ISBN 9781595938114 (2007), pp. 375–384. [11] GeoCities. “GeoCities webpage”. https://web.archive.org/web/19961219234328/http:// www.geocities.com/BHI/about.html (visited 2020-05-13). [12] Github.com. “the github Docs”. https://help.github.com/en/github/getting-started-with- github (visited 2020-05-13). [13] John Hennessy. “The Future of Systems Research”. In: IEEE Computer Volume 35– No.11 (1999), pp. 27–33. [14] IEEE. “IEEE Standard for Software and System Test Documentation”. In: IEEE Std 829-2008 - (2008), pp. 1–150. [15] IEEE. “IEEE Standard Glossary of Software Engineering Terminology”. In: IEEE Std 610.12-1990 No.98EX220 (1990), pp. 1–84. 54(54)

[16] B. W. N. Lo and Haifeng Shi. “A preliminary testability model for object-oriented software”. In: International Conference Software Engineering: Education and Prac- tice No.98EX220 (1998), pp. 330–337. [17] D. Marx. “Software Development Communities: Size Matters”. http://marxsoftware. blogspot.com/2009/01/software-development-communities-size.html (visited 2020- 04-25). [18] Microsoft. “C documentation”. https://docs.microsoft.com/en-us/dotnet/csharp/ (visited 2020-05-12). [19] Microsoft. “Silverlight”. https://www.microsoft.com/silverlight/ (visited 2020-04-16). [20] microsoft. “single-page-apps”. https://docs.microsoft.com/en-us/dotnet/architecture/modern- web-apps-azure/choose-between-traditional-web-and-single-page-apps (visited 2020- 04-12). [21] Gordon E. Moore. “Cramming more components onto integrated circuits”. In: Elec- tronics Volume38- No. 8 (1965). https://newsroom.intel.com/wp-content/uploads/sites/ 11/2018/05/moores-law-electronics.pdf (visited 2020-05-16), pp. -. [22] React. “the React Docs”. https://reactjs.org (visited 2020-05-12). [23] V.B.Singh Sujata Khatri R.S. Chhillar. “Improving the Testability of Object-oriented Software during Testing and Debugging Processes”. In: International Journal of Computer Applications Volume 35– No.11 (2011), pp. 24–35. [24] Vue.js. “Vue.js Docs”. https://vuejs.org (visited 2020-05-12).