Evaluating Blazor

Home , Blazor, Data binding, TypeScript, Web standards

Linköping University | IDA Bachelor thesis, 16hp Autumn term 2020 | LIU-IDA/LITH-EX-G--20/079-SE

Evaluating Blazor

A comparative examination of a web framework

Erik Sandberg

Examinator, Petru Eles Copyright The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

For my thesis work I have done an evaluation of the newly released Microsoft developed web framework Blazor. My methodology is based upon a couple of previous articles about evaluating web frameworks. From these articles I have gathered a number of criteria used in my evaluation: documentation, lines of code, community size, framework usage, framework maturity, framework freshness, browser support and framework cost. Additionally, since Blazor is based on C# instead of JavaScript, I have included a 9th criterion, comparing JavaScript with C#. Many of the criteria need some kind of counterpart for Blazor to be compared with, for this purpose I have mainly used the established web framework Angular, and in some cases Ember.js. When evaluating, I have not expected Blazor to exceed Angular. Rather I have counted all cases where Blazor can at least be considered comparable to Angular (or Ember.js) as favourable.

I found that overall Blazor did very well in the comparison as 6 out of the 8 criteria I took from the articles evaluated favourably for Blazor. The two criteria where I found Blazor lacking were framework usage and framework maturity. While there are large numbers of showcases and example sites I did not find any large production websites developed with Blazor, and for obvious reasons the framework that was officially released earlier this year has yet to reach a mature state. Furthermore I found the extra criteria, JavaScript vs C#, was favourable to Blazor.

Thus, my conclusion is that Blazor is certainly worth picking up for new projects. I argue that even though the framework is not yet fully mature it has come far in its short lifespan, and that even though Blazor is not widely used yet it is unlikely to go away considering that it is developed and supported by a large company like Microsoft.

iii Table of Contents 1 Introduction...... 6 2 Background...... 7 2.1 Web Frameworks...... 7 2.2 JavaScript and TypeScript...... 8 2.3 C#...... 10 2.4 WebAssembly...... 10 2.5 Blazor...... 11 3 Methodology...... 12 3.1 My Application...... 13 3.2 Evaluation criteria...... 14 3.2.1 Documentation...... 14 3.2.2 Lines of Code...... 15 3.2.3 Community Size...... 16 3.2.4 Framework Usage...... 16 3.2.5 Framework Maturity...... 17 3.2.6 Framework Freshness...... 17 3.2.7 Browser Support...... 18 3.2.8 Framework Cost...... 18 4 Findings...... 19 4.1 Documentation...... 19 4.1.1 Extent and features coverage...... 19 4.1.2 Tutorials, examples and templates...... 20 4.2 Lines of Code...... 21 4.3 Community Size...... 23 4.4 Framework Usage...... 23 4.5 Framework Maturity...... 24 4.6 Framework Freshness...... 24 4.7 Browser Support...... 25 4.8 Framework Cost...... 25 5 Discussion...... 26 5.1 Documentation...... 26 5.2 Lines of Code...... 27 5.3 Community Size...... 28 5.4 Framework Usage...... 29 iv 5.5 Framework Maturity...... 29 5.6 Framework Freshness...... 30 5.7 Browser Support...... 30 5.8 Framework Cost...... 31 5.9 JavaScript or C#?...... 31 6 Conclusion...... 33 7 Reference List...... 35 7.1 Articles...... 35 7.2 Web pages...... 36

v 1 Introduction

The last decade a myriad of JavaScript frameworks have emerged, and choosing which framework to work with is a major consideration for a project. Recently, new languages have also entered the scene, not only languages related to JavaScript like TypeScript, but traditional languages like C++ that are compiled and run as WebAssembly as well. Microsoft has recently developed the open source web framework Blazor, based on C# mixed with traditional HTML. Blazor consists of a server-side and a client-side implementation where the client-side implementation is based on WebAssembly.

My intention is to first develop a small application using Blazor and then evaluate if the framework is comparable to leading web frameworks by setting various features of Blazor and its community side by side with corresponding features of leading web frameworks. Thus, I hope to determine, to a degree, if it is worth for a web developer or company working in web development to add Blazor to their repertoire.

Personally I have always been interested in bleeding edge technology. For the longest time I have felt that the web has been stagnant, stuck in its old HTML and JavaScript ways. This has started to change during the last decade as both HTML (with HTML5) and JavaScript (with modern frameworks like Angular and React) have evolved. I was very excited when I first heard about WebAssembly, and experimented with it in one of my courses at university. When I started to plan my thesis project something related to WebAssembly was one of my major plans, and when I heard about Blazor exiting its beta stage I felt that I had found a perfect subject that had both personal, academic and commercial relevance.

6 2 Background

2.1 Web Frameworks

Since the conception of the world wide web there has been a constant drive to add more dynamic behaviour to the the original static HTML based webpage. During the middle of the 90s, in the early history of the web, this was accomplished by the introduction of a client side scripting language, JavaScript. At roughly the same time new programming languages, such as PHP, specifically intended to run on web servers were introduced. In their wake software libraries to perform various external tasks appeared. This in turn led to the emergence of the first web frameworks, collecting multiple libraries into a complete stack intended for web development. The idea behind the frameworks were to streamline the development process by delivering a working bundle of technologies out of the bag, allowing web developers starting new projects to begin programming instantly instead of having to spend time looking for suitable technologies. Some frameworks allowed the use of the same programming language for both backend and frontend logic, further simplifying development. Examples of such full stack frameworks include Django (a Python framework) and Ruby on Rails. Since the 90s a myriad of JavaScript frameworks have emerged and during the last decade client-side frameworks like React (developed by Facebook) and Angular (by Google) have gained immense popularity (Hotframeworks.com, 2020). These frameworks focus on powerful presentation and data manipulation on the client-side. Unlike their earlier counterparts these frameworks encourage the developer to decide what backend technologies to use depending on the needs of their project. They combine freely with any backend, and are thus able to work as a frontend to older frameworks as well as more modern server technology.

Other well established frameworks include Vue.js (used by Google, Alibaba among others), Ember.js (used by Apple Music, LinkedIn, Twitch among others) and Laravel. Even with the introduction of modern frontend frameworks older ones like Ruby on Rails and Django are still popular and see active development.

7 2.2 JavaScript and TypeScript

As mentioned earlier JavaScript was originally developed by Netscape, a precursor to Mozilla, in the mid 90s to provide scripting and interactivity for web pages. The language was quickly adopted and several entities (including Microsoft, Mozilla and later Google) worked on competing standards. In the late 00s the separate parties agreed to developing a common standard resulting in ECMAScript becoming the de facto JavaScript standard. From originally only providing some basic scripting JavaScript is now incredibly powerful, capable of manipulating web pages and data to a degree where many modern web sites are broken or simply unable to be displayed without enabling JavaScript. The language has also expanded beyond the web browser, now being used to write server software and general applications using software frameworks such as Node.js and Electron.

JavaScript can be compiled in the traditional sense but on the modern web this is a rare occurrence, instead JavaScript is usually just-in-time (JIT) compiled by the web browsers JavaScript engine when certain functionality is required. This method of compilation provided both faster execution and faster loading speeds. JavaScript is dynamically typed, meaning that types are checked at runtime. In addition to dynamic typing the language makes use of so called weak typing, meaning that the developer is allowed to reassign variables regardless of type. A variable originally representing a string can be reassigned to an integer, as shown in figure 1 on the next page. JavaScript uses a C-style syntax. In line with its design as an easy to use scripting language it is quite permissive. For example, it allows global variables, assignment to undeclared variables and does not require a semicolon to end a statement.

Lately new programming languages have also been introduced to the client- side. Languages like CoffeeScript (2009) and TypeScript (2012) try to improve on perceived shortcomings of JavaScript by adding various technical features, improved syntax and enhancing the development process. These languages are quite similar to JavaScript and work by transcompiling to JavaScript before they are deployed to the web where they run on the browser engines just like normal JavaScript.

8 TypeScript is developed and maintained by Microsoft. The language is a strict superset to JavaScript, meaning that all valid JavaScript is in turn valid TypeScript. Thus, TypeScript supports all features that JavaScript does. In addition, TypeScript adds support for variable types and compile-time type checking, enums, interfaces, generics/templates, namespaces and more. This makes TypeScript a compiled language with a static and strong type system, as illustrated in figure 1. If a programmer wants to change a variable from one type to another they have to do a type cast, highlighting their intention of actually changing the type.

Figure 1: Illustrating type errors in TypeScript and the lack of errors in JavaScript

Historically JavaScript did not support object orientated programming (OOP), so when TypeScript was released OOP was another additional feature. Since then JavaScript has added class functionality so this is no longer a true distinction. However, as almost all major object oriented languages such as C++, C# and Java use static typing one could argue that TypeScript still lend itself better to OOP than plain JavaScript.

9 2.3 C#

C# is an object-oriented (with capabilities for other paradigms) programming language developed by Microsoft as part of the .NET framework. The language has a C-style syntax not entirely unlike that of JavaScript and TypeScript. Similar to TypeScript, C# has strong typing requiring the user to declare the type of their variables and use type casts to perform type changes. Type errors are reported at compile time. Similar but not identical to JavaScript, C# is a just-in-time compiled language, running on the Common Language Runtime (CLR) which is part of the .NET framework and handles JIT compilation and execution of .NET programs. Unlike a JavaScript program, C# code goes through a compilation process before the program can run on the CLR. Before it can be consumed by the CLR the code is compiled into an intermediate language designed to the specification of the runtime. A program written in C# and executed on the CLR can run on any platform with an .NET implementation, giving the language great portability.

2.4 WebAssembly

With the introduction of asm.js in 2013 the client-side was opened up to a host of non-web programming languages such as C/C++, Python and Rust. Similarly to how TypeScript and CoffeeScript transcompile to JavaScript, asm.js compiles its targeted languages to a subset of JavaScript. In comparison to JavaScript, asm.js boast performance closer to natively compiled code. It does this by taking advantage of compiler optimization and the inherently superior performance many of the supported languages, such as C++ or Rust, have compared to JavaScript. The ideas behind asm.js, in turn, lead to the development of WebAssembly, or WASM, which was first announced in 2015. Instead of compiling to JavaScript, or a subset of JavaScript, source code is compiled to a binary format that runs on the same interpreter as JavaScript does, comparable to how a programming language like C# is generally executed. In late 2017 WebAssembly were supported by all major browsers and in 2019 WASM was made an official web standard by the World Wide Web Consortium (W3C).

10 2.5 Blazor

Microsoft has recently developed and released the open source web framework Blazor. Blazor is based on HTML and C# and currently consists of a server-side and a client-side implementation where the client-side implementation is based on WebAssembly. Blazor makes heavy use of the Razor syntax, a markup syntax that lets programmers mix C# into standard HTML to provide logic and data manipulation. Previously Razor has lived on the servers in Microsoft’s other web frameworks, ASP.NET MVC Views and Razor Pages. The big difference that sets Blazor apart from its predecessors is that instead of views or pages it’s based on components. The entire application is made up of a series of individual so called Razor Components. For example, a component can represent a side bar, a list or a footer and together they combine into a complete application. They are inherently reusable and encourage a divide-and-conquer approach to building a web app. As C# is a just-in-time compiled language it needs a runtime environment for a program to run. Since neither browsers nor WebAssembly supply such an environment Client-Side Blazor works by sending a stripped down version of the .NET runtime able to be run as WASM to the client on initial load. This, in addition to sending the entire application, means that the initial payload of a Blazor WebAssembly application will be quite large but once the app has loaded all computation outside of database access is done at the client-side leading to fast responses and low need for messages to the server. This makes Blazor WebAssembly quite similar to apps built in modern frameworks like Angular.

11 3 Methodology

As the first part of my project I will develop a smaller application using Blazor WebAssembly. The purpose of the development phase is to give me experience with the framework, the software used for development as well as the community surrounding it in preparation for evaluating the framework. To get as much as possible out of the development phase I will make sure to use resources relevant to the coming evaluation, such as the official documentation and tutorials. In addition, I will try to use diverse techniques and solutions as opposed to reusing code and patterns, as long as it is not obviously detrimental to the code quality.

As a second phase I will examine Blazor, its community and the ecosystem surrounding it. This evaluation is done according to criteria for choosing web frameworks presented in a series of three articles, Comparative Evaluation of JavaScript Frameworks [Gizas, Christodoulou et al. 2012], Making Sense out of a Jungle of JavaScript Frameworks [Graziotin, Abrahamsson 2013] and Factors and actors leading to the adoption of a JavaScript framework [Pano, Graziotin et al. 2018]. I have prioritized examining the criteria where the second and third articles overlap, as they build on the opinions of developers as opposed to solely framework quality and performance. I will then pick additional criteria from all three articles based on what I can realistically fit in my project time-wise as well as on my own development experience and what factors I found most useful. Since all three articles deal with frameworks based on JavaScript, while Blazor uses C# for its logic, I will also take into account and discuss how the differences between the languages affect the criteria (in addition to JavaScript, TypeScript will often feature as the language compared with C#). As the language itself can also be a criterion in choosing a framework I will additionally discuss the differences between C# and JavaScript and their relevance to picking a framework and web programming in general.

12 While some criteria can be evaluated by looking at Blazor alone (an example of this is the framework cost criteria), most will need a comparison with another framework to make sense. When there is need to compare Blazor to another framework I have decided to compare it to Angular, a modern and well established framework with a big supportive ecosystem. As Angular has existed for almost a decade a reasonable comparison should indicate a well established and usable framework. I do not expect Blazor to exceed Angular. For some criteria Angular might be too big to produce a relevant comparison by itself (community size and framework usage, for example). When that is the case I will also compare Blazor to some less used, but well known framework or software.

For my application I have used the client-side implementation of Blazor, Blazor WebAssembly, and it is therefore the one I am most familiar with. When nothing else is specified it will be the version referred to in the text. Nevertheless, the evaluation is concerned with both the versions and when relevant their differences will be discussed.

3.1 My Application

During the first phase of the project I developed an administration panel for a phone app used by tenants of a housing company. The application is connected to a pre-existing database and its main function is displaying and editing various data. There are four views and a welcome page; users, error reports, logging and notifications. The users page show user related statistics (total number of users, active users etcetera) and allows editing user data. Error reports show a list of all error reports, and a detailed view of individual reports. The logging page log error messages both from the administration application itself as well as the app it is serving. The notifications tab allows the creation of new notifications as well as displaying a list of notifications currently displayed to users, a log of historical notifications and upcoming notifications. My application was built using Blazor WebAssembly, and .NET Core 3.1. The main tool I have used during development is Microsoft Visual Studio. I used the existing Blazor boilerplate and built my application using the provided code skeleton. The various functions allowed me to explore common web concepts such as user input, forms, data-binding and more. I also got to make use of tutorials, documentation and community sites. As stated earlier I tried to use as diverse techniques as possible. For example, I used both ordinary HTML forms and form functionality provided by Blazor to be able to compare them.

13 3.2 Evaluation criteria

3.2.1 Documentation

“Documentation should be precise and include several examples for implementing common tasks. Documentation should allow developers to find guidelines on implementing a feature quickly.” *

Both [Graziotin, Abrahamsson 2013] and [Pano, Graziotin et al. 2018] mention that adequate documentation is a crucial criterion for developers when looking to pick a web framework for a project. Extensive and educative documentation save time and effort as the developer won’t have to struggle against the framework at the beginning of a new project.

To evaluate this criterion I will look at how extensive the documentation is, comparing the official Blazor documentation to the Angular counterpart. I will look for code snippets embedded in the documentation and instructions detailing how to implement common features of web frameworks such as input forms, data binding, and routing. I will also look for follow-along tutorials. In addition to specific tutorials the existence of working templates, or boilerplate applications, for the programmer to extend and learn from is seen as favourable.

*All heading quotations are taken from (Pano, Graziotin 2018)

14 3.2.2 Lines of Code

“The number of lines of code of the new applications created by means of the frameworks should be as low as possible.”

[Graziotin, Abrahamsson 2013] and [Pano, Graziotin et al. 2018] both list the amount of lines of code needed to accomplish a task, or pragmatics as it’s called in the earlier article, as an important criterion when choosing between frameworks. A developer does not want to waste time or screen space on unnecessarily verbose code. The framework should aid in writing efficient, readable and concise code. There are two parts to this comparison, one part concerned with the framework syntax itself and a second regarding the language used for implementing functionality not provided by the framework. For both parts I will compare Blazor with Angular. For the first part I will look at how bulky the extended HTML syntaxes provided by the frameworks are and for the second part I will compare C# with TypeScript. Blazor handles Cascading Style Sheets, perhaps better known as CSS, in the same way as ordinary web pages and web frameworks do, so they will not be discussed.

One thing that has to be considered is the possibility of writing so called one- liners with extensive functionality. Since concise one-liners lead to low readability and make a code base hard to maintain and should not be present in seriously written code, I will compare code written according to solid code standards, and when possible as presented in official documentation.

15 3.2.3 Community Size

“The community behind a framework is its heart and as such its size and contributors signal the trust of developers in the technology.”

In [Graziotin, Abrahamsson 2013] and [Pano, Graziotin et al. 2018] developers claim that the size of the community surrounding a web framework is an important factor when adopting the framework for a project. To estimate the size of the Blazor community I will compare it to other major frameworks. As Angular has a huge community reaching relevant conclusions outside of the fact that Blazor has a smaller community is impossible. Thus, I will also look at the smaller web framework Ember.js.

I will estimate the size of the communities by looking at some of the most popular community web sites for developers, GitHub and Stack Overflow. First I will look at the main repositories of the frameworks, comparing the number of contributors and contributions over a limited time. I will then look at the number of projects using each framework. As for Stack Overflow I will look at the amount of questions tagged with each framework. To get a more accurate picture of the present community activity I will also try to limit the questions to a shorter time period.

3.2.4 Framework Usage

“A framework is estimated as reliable if used by similar companies in their production environment.”

The participating developers in the 2018 study [Pano, Graziotin et al. 2018] had more confidence in a framework used not only by amateurs, but by software companies as well. Rigidly evaluating this criterion would be difficult, one would have to either survey enough companies and developers to gather consensus regarding usage, examine a large number of popular websites to try to identify the underlying technologies, or do something equally large-scale. To gather some basis for discussion I will therefore simply look for mentions of websites on official Blazor sites and on community sites like GitHub. I will also look at the amount of repositories on GitHub to get an approximation of framework usage.

16 3.2.5 Framework Maturity

“Frameworks which have been around for a longer time are preferred to new ones.”

As stated by [Pano, Graziotin et al. 2018] a framework that has been around a long time is preferred to a new one. Maturity is also mentioned in [Graziotin, Abrahamsson 2013] but it’s not specified if it is with regards to framework age, community size or something else. In the most recent article interviewees specifically stated that some age is important in itself, not only related to the size of the community surrounding the framework. In addition to the age of the framework itself I will also look at the maturity of the underlying technology and the software surrounding the framework.

3.2.6 Framework Freshness

“Frequently updating a framework with new features for matching the web design trends is evaluated positively.”

The freshness of a framework is mentioned in both [Graziotin, Abrahamsson 2013] and [Pano, Graziotin et al. 2018]. In the older article [Graziotin, Abrahamsson 2013] it is simply defined as the framework being frequently updated while [Pano, Graziotin et al. 2018] adds that the framework should have modern features and allow the implementation of new technologies.

As Blazor is a new framework built on modern technologies such as WebAssembly it almost pass the second part of the criteria, having modern features and implementing new technologies, by default. Therefore I will only discuss implementation of new features briefly. I will look closer at how frequently the framework is updated, and what kind of release model it follows. Frequent updates are not only relevant when it comes to implementing new features, it is also important for compatibility and security reasons.

17 3.2.7 Browser Support

“Applications created through a framework should run in different browsers.”

Applications developed with the framework should run in a variety of browsers. Evaluating this criterion in depth would be too demanding for the scope of this project as one would have to look at how different browsers implement various web standards, look for rendering variations and test performance. The evaluation will thus be limited to reporting what browsers the frameworks are said to support.

3.2.8 Framework Cost

”Free frameworks are preferred to paid ones.”

According to [Pano, Graziotin et al. 2018] developers prefer free frameworks over paid alternatives. As modern frameworks are almost exclusively free to use I will also look at other potential costs, such as widely used paid development tools or external libraries.

Another property tangibly related to cost is the licence used by a framework. A framework might be free to use by the general public but the licence might impose costs or other restrictions on larger organisations, after you reach a certain number of users or at a threshold revenue. Also some people simply prefer open source software to proprietary for a variety of reasons. Therefore I will also look at what licenses Blazor and related software use.

18 4 Findings

4.1 Documentation

4.1.1 Extent and features coverage

To assess the size of the Blazor and Angular documentations I downloaded the respective documentations from GitHub and wrote a script to count the number of words in each of the documentations. In September 2020 the Blazor documentation found on GitHub consist of 94571 words, approximately 210 pages of text. The Angular documentation, retrieved in October, is slightly short of three times longer at 274171 words, approximately 609 pages.

The Blazor documentation is well illustrated with code snippets and instructions on how to use the displayed code. Feature coverage in the Blazor documentation is extensive and provides in- depth instructions on how to implement things such as forms and validation, data binding, routing, events and much more.

19 4.1.2 Tutorials, examples and templates

The official Blazor documentation contains two distinct tutorials. The first one focuses on Blazor Server and walks the prospective developer through creating an application showing a list of things to do. It covers how to create and run an application using a boilerplate project, the fundamental makeup of a Razor Component, basic interaction between components, event handling, basic data binding and routing. The second tutorial teaches the developer how to build a chat app using Blazor WebAssembly. Like the first tutorial it covers the creation and running of the app. It also covers Razor Components, but in a less detailed and more copy- paste approach. The Angular documentation features six different tutorials, a general tutorial covering the basics and the rest covering specific topics like routing and data binding.

Both Blazor and Angular come with boilerplate applications as seen below in figure 2. By default they are generated when you create a new project. The Blazor boilerplate consists of a navigation menu, the hello world example and two elementary working example pages, one featuring some basic logic and the other server interaction.

Figure 2 Blazor and Angular boilerplate applications

20 4.2 Lines of Code

The Razor syntax used by Blazor allows insertion of variables, methods and logic written in C# into the HTML. This is done by prefacing the logic by an @, indicating that what follow is not pure HTML. In the example below a variable and a function call are shown, it is also possible to insert larger portions of code such as, for example, if-else statements or anonymous functions. Outside the HTML the programmer may also write custom functionality in each Razor Component. Similarly to the @ in the HTML tags, this is done prefaced by the keyword @code and inside of a scope enclosed by brackets. Figure 3 showcases a basic component with a code block containing a variable and a method that, in combination with the Razor/HTML at the top of the file, renders a web page containing a button that will show or hide the string “Now you see me!” when clicked. Notice how the isVisible variable and the setVisibility() method are both present in the “HTML”.

Figure 3: A simple Blazor component

21 Angular works in a similar way, and allows insertion of variables and methods via built in and custom so-called attribute directives and structural directives. In Angular, HTML and logic is by default split into individual files, usually with additional files for CSS/styles and testing, but they can be put in a single file similarly to how it is done in Blazor (it is possible to split up the Blazor files in two as well). Figure 4 shows an Angular program (with logic and markup in a single file) with similar functionality to the Blazor component in Figure 3 above. I wrote the Blazor component first, then generated an Angular component using the Angular Command Line Interface and tried to write the functionality in the Angular component in a code standard comparable to its Blazor counterpart. The results are that the Blazor component is 17 lines long while the Angular component is 25 lines long. It is also worth noting that I deleted some superfluous code generated by the Angular tool, shortening the component with a couple of lines.

Figure 4: A simple Angular component

22 4.3 Community Size

Using contributors and contributions to the GitHub repositories of Blazor and Angular to judge community size in a meaningful way proved impossible. The Blazor repo is a part of the larger ASP.NET Core repository which contains a number of other projects, including other web frameworks, as well. Unfortunately GitHub does not provide detailed enough statistics for sub folders in repositories to isolate Blazor and even if they did it would be difficult to decide what folders to include as technologies relevant to Blazor, such as Razor, are separate projects. On the project page Microsoft reports that .NET have gotten open source contributions from over 60,000 developers and more than 3,700 companies (Microsoft, 2020).

Searching for repositories on GitHub using the keyword Blazor, the resulting number is over 9000. Searching for Angular the sum is more than 681 000, while searching for the smaller web framework Ember.js gives 33.000 results.

On Stack Overflow there are close to 3,500 questions tagged as concerning Blazor as of 10 September 2020 (Stackoverflow.com, 2020). 300 questions out of those 3,500 were asked during the last month. As comparison there are a little over 23 500 questions under the Ember.js tag, 30 of them from the last month. The Angular tag has over 231 000 questions and more than 1000 only during the last week.

4.4 Framework Usage

Numerous example websites and technology showcases, developed both by the Blazor team, third party organizations and amateur developers, are easy to find (Torris, 2020). Actual production websites made for commercial purposes are a different matter, despite searching the web and asking in various Blazor communities I have not been able to find many.

23 4.5 Framework Maturity

As of August 2020 the official release of Blazor WebAssembly, the latest version leaving its beta phase, was less than three months ago (Roth, 2020). Before release Blazor spent about two and half years in development following the initial announcement in February 2018.

While Blazor itself is very new, the techniques it is based on are mature and well established. C# and the .NET framework have been around, and have been continuously developed, since the early 2000s. Razor, the template markup syntax used to power Microsoft's older web frameworks ASP.NET MVC Views and Razor Pages, which are still in use in Blazor, has existed for about a decade. WebAssembly in turn was released in March 2017, although it’s based on the older asm.js originating in 2013. The standard has matured quickly and is now an official web standard implemented by all major web browsers.

4.6 Framework Freshness

Blazor is based on C#, a language that is regularly updated and kept up to date with modern features. The client side implementation of Blazor uses WebAssembly, an emerging web technology. The framework supports HTML5 and allows injection of plain JavaScript (or TypeScript), giving developers access to all ordinary web functionality in addition to that provided by Blazor.

Blazor is open source and hosted on GitHub. It is, thus, possible to download and build new versions the minute a new update is merged. In most cases however a user would simply get the updated versions of Blazor as they update the .NET Core framework. Major versions of .NET Core are released approximately once a year and new minor versions once every month (Microsoft.com, 2020). It is also possible to download the Release Candidate for the coming version of .NET Core, which follows a similar release schedule with new versions about once a month. Angular follows a similar schedule with two major releases every year and a couple of minor releases in between (Angular.io, 2020).

24 4.7 Browser Support

All versions of Blazor support modern browsers, including Mozilla Firefox, Google Chrome, Apples Safari and Microsoft Edge. It should also run on all smaller browsers following modern standards. The client-side implementation, Blazor WebAssembly, does not support the discontinued Internet Explorer as the browser does not support WebAssembly. Blazor Server will run on Internet Explorer and other outdated browsers but does require polyfills to handle features the browsers does not handle natively.

4.8 Framework Cost

Blazor is free to use and is open source. (Microsoft.com, 2020) The framework is licensed under the Apache License 2.0 which allows users to use, modify and redistribute software. In addition the license guarantees the user rights to any patents related to the licensed software, guaranteeing against any hidden licensing costs.

Historically the .NET framework has used a variety of (mostly proprietary) licenses, but as of 2020 Microsoft has made .NET Core, the free and open source implementation of the .NET framework, the primary implementation of the framework indicating that the framework will remain free for the foreseeable future.

Visual Studio is an integrated development environment (IDE) developed by Microsoft for .NET development. In a 2019 survey (Stackoverflow.com, 2020) Visual Studio was rated as the second most used development environment, and the most widely used IDE. Visual Studio is available in three editions, two of which are available as paid subscriptions (Microsoft.com, 2020). The two editions are Professional, aimed at individuals and smaller teams, and Enterprise, aimed at larger teams and companies. In addition to allowing collaboration between more developers the paid editions provide additional services mostly centred around Microsoft's cloud service Azure. The cloud services include tools for development, testing, deployment and more. Furthermore, paid subscribers gain access to training, additional support and additional paid software.

25 5 Discussion

5.1 Documentation

While the Angular documentation is noticeably larger than Blazor’s the Blazor documentation is quite sizeable at over 200 pages. When it comes to code snippets and features the two documentations are quite similar, both providing many examples and broad coverage. It is worth noting that the Blazor documentation is part of the much larger ASP.NET Core documentation, and some important information, such as documentation regarding the Razor syntax, live outside of the Blazor part of the documentation. My personal experience is that the Angular stand-alone documentation model is easier to navigate and understand.

The Blazor tutorials are enough for a programmer to get started, but they are far from as extensive as the ones provided by Angular. When it comes to boilerplate applications the Angular one is more pleasing to the eye and look more professional. However, as one has most likely already found the relevant documentation the links provided by the Angular template are largely redundant. I found that the bare-bones approach of Blazor, including working example of essential functionality, was easier to build upon compared to its intricate Angular counterpart.

It is also worth noting that there is a large number of community driven websites with documentation regarding various functionality, something I had great use of as a complement to the official documentation during my time developing with Blazor.

The Blazor documentation does not reach Angular’s level as it is less extensive and not as instructive. On the other hand it is far from insufficient and is hardly a reason not to pick Blazor for a project.

26 5.2 Lines of Code

As seen in the previous chapter a very basic Angular component might be more than 10 lines longer than a Blazor counterpart. This is mostly because of Angular boilerplate code. If one considers only the logic and the markup the two examples would have consisted of exactly the same number of lines. As the components grow in length, the difference in number of lines should therefore stay roughly the same, as opposed to the difference growing linearly.

When it comes to inserting method calls, variables and other non standard code into the HTML there is no big difference between Blazor and Angular. Angular’s directives are slightly more verbose than Blazor’s @, but on the other hand their built in functionality could lead to more streamlined development in the long run. Both C#, JavaScript and TypeScript use a C style syntax and look somewhat similar as seen in the code examples in the Findings chapter. When it comes to the logic part of a component there should basically be no difference in length whether it is implemented in Blazor or in Angular. One could ague that C# would make for slightly more line efficient code because of the multitude of framework libraries implementing types and algorithms included in .NET out of the box, but even without taking third party libraries available for both languages into account it would most likely be of minor importance.

One must also consider the implication of the lines of code criterion. Developers want efficiency, simplicity and readability. That Angular split its components up in several files by default, generate superfluous code when you generate new components and have more overhead in general is a small disadvantage in this case.

Blazor’s syntax, and by extension the number of lines of code needed to implement a feature should certainly be seen as favourable when picking a web framework. When compared to Angular the difference is not really big enough to say that Blazor is better but its sparse use of connecting code makes it very concise, readable and simple to use.

27 5.3 Community Size

It proved difficult to judge how many contributors Blazor itself has. The numbers of contributing developers and companies reported by Microsoft is impressive, but concern not only Blazor but the entire .NET open source project. However it does show that there is a large supporting community for the underlying technology.

During its short lifespan Blazor has reached almost a third of the amount of repositories that Ember.js has on GitHub. Even if many repos would turn out to just be minor projects by developers trying out a new framework, as opposed to projects of larger scale, the sheer number of repositories featuring Blazor suggests a large interest in the framework.

The activity on Stack Overflow indicates an active community of developers. As an archive of answers to common questions is not yet fully built up a newer framework can probably expect more questions compared to older ones like Ember.js. Two other factors that could inflate the number of questions is the proximity to official release and that features might change rapidly during a framework’s early life. Even considering these factors the amount of activity compared to that of Ember.js supports the image of a framework generating great community interest. Also, reaching a third of the number of questions a huge framework like Angular receives every week is quite notable.

Compared to the huge community surrounding Angular the Blazor community is still slight, but when put side by side with a smaller framework like Ember it is quite comparable. Blazor’s community is active, rapidly growing and has already amassed a solid foundation of information. When looking at communities to pick a web framework for a new project Blazor’s should prove more than adequate, even if it is not as large as the giants.

28 5.4 Framework Usage

While the lack of commercial websites is perhaps to be expected considering the young age of Blazor it is undoubtedly a large disadvantage in a comparison. The numerous community sites and showcases indicate an active community and potential of the framework, but does not prove its ability to power a large scale commercial website.

The 9000 repositories featuring Blazor on GitHub represent a miniscule amount compared to the 681 000+ that turn up when searching for Angular. However, 9000 repositories look like a more respectable number when compared to the 33 000 repositories a search for Ember, created 8 years ago, results in.

The redeeming factor for Blazor is that it’s part of the .NET Framework. While no well known sites are built in Blazor and no companies have broadly adopted the framework as of today it’s part of a hugely popular software bundle with uncountable users worldwide, which partly mitigates the otherwise unfavourable comparison.

5.5 Framework Maturity

Even in the fast moving world of web technologies Blazor, being only a couple of months out of release, is very new. As comparison Angular, the youngest among the most used web frameworks, had its initial release 4 years ago. However, one should take into consideration that Blazor is built upon established and well known technologies, is a part of the widely used .NET framework and (like both React and Angular) is backed by a huge corporation. In addition, the framework has grown quickly and attracted a noticeable community during the short time it has been around.

All things considered, maturity will still favour another framework over Blazor, but its stable base, support and fast growth imply that Blazor is a solid choice that is not going away soon.

29 5.6 Framework Freshness

Blazor features both regular stable releases and the ability to run preview versions if there is need for bleeding-edge features. The framework is new, is designed with modern web development in mind and is built upon emerging technologies.

Freshness will undoubtedly favour Blazor in a comparison between web frameworks. Even when compared with modern frameworks such as Angular or React, Blazor will have a slight edge thanks to its underlying technologies such as WebAssembly.

5.7 Browser Support

For most Blazor projects browser support should not be a problem. As of August 2020 the combined market share of browsers that do not support WebAssembly, thus not supporting client-side Blazor, is somewhere between 2,6 and 4,6 percent. (Statcounter.com, 2020) If a project is targeting a market or demographic where outdated browsers are more common than on average a case could be made for picking Blazor Server over Blazor WebAssembly. The same applies if it is crucial that the application can be viewed by all users. Another potential solution that is sometimes used by sites that want to work on devices without JavaScript enabled is to have an alternate, bare-bones site as a backup.

As other modern web frameworks such as Angular and React are also built on the latest web standards they will similarly require use of polyfills when it comes to supporting outdated browsers. Therefore browser support is unlikely to be a deciding factor when picking among web frameworks.

30 5.8 Framework Cost

For the individual developer, or small team, Blazor and all necessary development tools are free. As I developed my application I never felt the need for any of the additional paid tools or features. Small companies, and committed individual .NET developers might want to get the Professional edition of Visual Studio, and larger teams that want to use Visual Studio will most likely buy the Enterprise version. The most popular development environment, the open source editor Visual Studio Code (commonly known as VS Code) is free and is fully capable of .NET development comparable with that of Visual Studio. However to achieve comparable development capability the user will have to spend quite some time installing extensions and creating a corresponding toolchain. The large number of developers using Visual Studio indicate that the out-of-the-box complete functionality is valued by many in comparison to the effort needed to maintain a free toolchain. One additional point is that both Visual Studio and .NET in general are already in wide use, so many entities that might want to adopt Blazor will already have access to the relevant paid tools.

As the costs are low or non-existent and associated with surrounding software I find it unlikely that cost would be a negative factor for Blazor in a comparison with other free frameworks.

5.9 JavaScript or C#?

The permissive nature of JavaScript can theoretically allow a programmer to produce code more quickly, as they don’t have to bother with potentially time consuming tasks such as type conversions. The drawback of the JavaScript approach is potential uncaught errors caused by faulty typing. In the article To Type or Not to Type: Quantifying Detectable Bugs in JavaScript (Gao, Bird, et al.) the authors look for bug fixes in publicly available JavaScript source code and examine if the bugs could have been prevented by a strict type system. They report that 15% of the bugs, that made it through testing and into production code, would have been detected at compile time by a stricter type system. As they only count bugs that made it into production 15% is a low estimate for the amount of bugs a stricter language would have prevented, compared to JavaScript.

31 In addition to preventing errors, programming in C# could potentially lead to higher productivity. According to the findings presented in (Fischer, Hanenberg, 2015) using a programming language with static typing (TypeScript is used in the article) will significantly increase the productivity of a developer. A direct comparison between C# and JavaScript would of course have been preferable when discussing Blazor, but the wording in the article indicates that the increase in productivity should also apply to C#.

Many of the problems inherent to JavaScript that are solved by C# are also solved by the features added by TypeScript. Angular strongly recommends using TypeScript to a degree where it is almost required. React and Vue.js support TypeScript by default and Ember.js provides an add-on for coding in TypeScript instead of JavaScript. In other words, Blazor using C# does not necessarily provide a benefit over other modern web frameworks. This is the case especially if another modern framework is already used, as the benefits might as well be acquired by simply switching language. One benefit that is not related to the technical nature of the languages is the huge user base of C#. According to the August 2020 TIOBE Index, a measurement for programming language trends, C# is the fifth most popular language, almost twice as popular as JavaScript at spot 7 (Tiobe.com, 2020). This is advantageous for several reasons. For a company hiring new developers there will be more knowledgeable developers to choose from. For a programmer, or a team, moving to web development the learning curve will be less steep if they can write their web applications logic in a language they are already familiar with. And finally, for anyone in need of help when developing using Blazor there will be a huge amount of resources and community help available in addition to that strictly related to Blazor.

Considering these aspects the language of Blazor might favour it over another framework, especially if the user is new to web development, is using an older framework or has previous experience programming in C#, or some language similar to it.

32 6 Conclusion

Out of the 8 criteria I have looked at, the evaluation has been favourable to Blazor in 6 cases. The additional criterion, using C# instead of traditional web languages, does not oppose against Blazor either but rather favours the framework depending on the situation.

To summarize the criteria; while the Blazor documentation does not exactly match its Angular counterpart it is extensive and covers a wide range of topics. When it comes to lines of code, Blazor excels. Its syntax is both compact and comprehensible. Blazor’s community is large considering the age of the framework, and the community around its underlying technology is immense. Regarding freshness and browser support Blazor is a cutting edge software compatible with all browsers that support modern web standards, and a comparison with other modern web frameworks will neither excessively hurt nor favour Blazor. As for the cost, Blazor is free or reasonably cheap for most users. The potential costs arise from development software and deployment, costs that are likely to be present in any larger project regardless of what framework is chosen. The major drawback of Blazor is its young age, as the evaluation of both the framework usage and maturity criteria turned out disadvantageous for Blazor. As the maturity criterion is somewhat mitigated by the stability of the underlying technologies such as .NET, and by the booming community surrounding Blazor, the fact that there are currently no large scale websites built using Blazor is probably the most severe disadvantage. As it seems unlikely that a large company like Microsoft would simply drop Blazor after going through the process of developing and releasing it, these two drawbacks will simply fix themselves with time. This is especially true for the maturity criterion, considering how mature Blazor has already gotten during its short lifespan.

A clearer view of how the criteria evaluated can be seen illustrated in table 1 on the next page. As stated in the methodology chapter I did not expect Blazor to exceed Angular (or Ember.js). Thus, favourable does not mean that Blazor is in any way superior but rather that the criterion could not reasonably be expected to be used as an argument against adopting Blazor.

33 Table 1: How the criteria evaluated

Criterion Evaluation

Documentation Favourable Lines of Code Favourable Community Size Favourable Framework Usage Unfavourable Framework Maturity Unfavourable Framework Freshness Favourable Browser Support Favourable Framework Cost Favourable JavaScript or C# Ambiguous

Thus my conclusion is that while Blazor is not as established as its competitors choosing to use the framework for a new project is not a risky decision. As indicated by the evaluation, Blazor is almost surprisingly well tuned considering its freshness.

34 7 Reference List

7.1 Articles

Andreas B. Gizas, Sotiris P. Christodoulou and Theodore S. Papatheodorou. 2012, Comparative Evaluation of JavaScript Frameworks In: Proceedings of the 21st international conference companion on World Wide Web - WWW '12 Companion, 513-514

Daniel Graziotin, Pekka Abrahamsson. 2013, Making Sense out of a Jungle of JavaScript Frameworks In: Proceedings of the 14th International Conference on Product-Focused Software Process Improvement, 334-337

Amantia Pano, Daniel Graziotin, Pekka Abrahamsson. 2018, Factors and actors leading to the adoption of a JavaScript framework In: Empirical Software Engineering, 3503-3534

Zheng Gao, Christian Bird, Earl T. Barr. 2017, To Type or Not to Type: Quantifying Detectable Bugs in JavaScript In: 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), 758-769

Lars Fischer, Stefan Hanenberg. 2015, An Empirical Investigation of the Effects of Type Systems and Code Completion on API Usability using TypeScript and JavaScript in MS Visual Studio In: DLS 2015: Proceedings of the 11th Symposium on Dynamic Languages, 154-167

35 7.2 Web pages

Hotframeworks.com. 2020. Top Frameworks Available at: https://hotframeworks.com/ [Accessed 4 Nov. 2020]

Microsoft.com, 2020. Blazor Available at: https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor [Accessed 5 Sept. 2020]

Stackoverflow.com, 2020. Tags Available at: https://stackoverflow.com/tags [Accessed 10 Sept. 2020]

Torris Adrien, 2020. Awesome Blazor. GitHub Available at: https://github.com/AdrienTorris/awesome-blazor#sample- projects [Accessed 11 Sept. 2020]

Roth Daniel, 2020. Blazor WebAssembly 3.2.0 Release Candidate now available. ASP.NET Blog Available at: https://devblogs.microsoft.com/aspnet/category/blazor/ [Accessed 7 Aug. 2020]

Microsoft.com, 2020. Download .NET Core Available at: https://dotnet.microsoft.com/download/dotnet-core [Accessed 10 Aug. 2020]

Angular.io, 2020. Angular versioning and releases Available at: https://angular.io/guide/releases [Accessed 10 Aug. 2020]

Microsoft.com, 2020. .NET is open-source Available at: https://dotnet.microsoft.com/platform/open-source [Accessed 16 Aug. 2020]

Stackoverflow.com, 2020. Developer Survey Results 2019 Available at: https://insights.stackoverflow.com/survey/2019#development- environments-and-tools [Accessed 22 Sept. 2020]

Microsoft.com, 2020. Buy Visual Studio

36 Available at: https://visualstudio.microsoft.com/vs/pricing/ [Accessed 22 Sept. 2020]

Statcounter.com, 2020. Browser Market Share Worldwide Available at: https://gs.statcounter.com/browser-market-share#monthly- 202008-202008-bar [Accessed 31 Aug. 2020]

Tiobe.com, 2020. TIOBE Index for August 2020 Available at: https://www.tiobe.com/tiobe-index/ [Accessed 15 Sept. 2020]