In the past year or two, if you have been concerned about the development of .NET, it is likely Blazor heard the word. Blazor research team is ASP.NET UI framework for a new client. Its biggest advantage is the ability to use HTML, CSS and C # to write, instead of using JavaScript to write good Web UI, which is the dream of many developers.
Since the birth of JavaScript, JavaScript had become the consensus front-end Web development, yet we never really had this feeling satisfied. In recent years, there have been continuous or how much superset language translation, to help improve JavaScript, make it even more easy to maintain? For example: CoffeeScript, Dart, Elm and Scala.
In the most popular language in the famous Anders Hejlsberg design TypeScript language, it is the most talked about. Another of the same type, that is, C # designers, adds features such as interfaces, classes and compile-time type checking even generic like in C #. These features already exist in C #, and have been used for many years. C # is a powerful, flexible and rich language, easy to learn.
However Blazor has begun to show outside the original design, has the potential productive programming model, JavaScript has become a single-page application (SPA) direct competitors framework.
Microsoft has been carried out complex experiments on Blazor, trial Electron and WebWindow (Electron experimental lightweight alternatives) in desktop applications. Near to Blazor programming model mix with the local Xamarin form controls in the local mobile application development.
Can we began to read from a single UI framework that can be used to build any type of .NET application, whether it is Web, the desktop or mobile app? Although I do not know about you, but I'm sure you can find an exciting prospect.
Let Blazor flexible so what is it?
To answer this question, we need to understand how Blazor is designed.
Essentially, Blazor between how to calculate UI change (application / component model) and how to apply these changes (renderer) is different. This makes Blazor can only be created with other UI frameworks (eg Angular or ReactJS / React Native) UI Web-based technologies are distinguished. By using different renderers, Blazor can not only create a Web-based UI, but also can create native mobile UI.
This is indeed the need for the creation of different components, and therefore components written for the Web renderer does not work with the native mobile renderer. However, the programming model is the same. Means that developers familiar with it once, you can create UI using any renderer.
Rendering / hosted model
Blazor applications / core component model is responsible for calculating UI changes, but you can use different renderers to control the actual display mode and update the UI. These renderers are commonly known as managed models. As of this writing, Blazor have hosted four models in different stages of development.
Blazor Server
- Platform: Web
- Status: GA / Product Support
Blazor WebAssembly
- Platform: Web
- Status: Preview (submitted Products)
Blazor Electron
- Platform: PC end (Windows, Mac, and Linux)
- Status: experiment (uncommitted)
Mobile Blazor Bindings
- Platform: Mobile terminal (iOS and Android)
- Status: experiment (uncommitted)
As of this writing, Blazor Server is the only product to support production of the model. Blazor WebAssembly will be released in May 2020 - and I hope this will be an important announcement on a Build. Blazor Electron and Mobile Blazor Bindings are in the experiments, Microsoft is not over yet delivered.
Application / component model
This is the framework of the engine. Here we can find Blazor work of all non-specific UI elements. Programming models, routing and navigation and rendering tree, which is the mechanism used to calculate Blazor UI changes.
Part I want to focus on is the programming model. The four hosting model I mentioned above, the first three have one thing in common, they all need to know Web standards. For these hosting models, we need to use components written in HTML and CSS. But the fourth model Mobile Blazor Bindings are completely unaware of Web standards. Thus hosted model building applications requires the use of controls prepared by native mobile components thereof.
In order to provide a more intuitive example, let's look for the same components written Blazor WebAssembly, in line with the component uses a standard Web renderer, and Mobile Blazor Bindings use non-Web-based standard renderer.
// WebAssembly Renderer
<div>
<p>Current count: @currentCount</p>
<button class="btn btn-primary" @οnclick="IncrementCount">Click me</button>
</div>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
// MobileBlazorBindings Renderer
<StackLayout>
<Label FontSize="30" Text="@($"Current count: {currentCount}")" />
<Button Text="Click me" OnClick="@IncrementCount" />
</StackLayout>
@code {
private int currentCount = 0;
private void IncrementCount()
{
currentCount++;
}
}
You can easily see the difference between the two code samples, but I wanted to let you highlight similarities.
Both samples have a tag portion and a code block. In fact, the code block is the same between samples. Each of which has a specified handler "OnClick" event, and to use the expression value of the current output count field.
Here I must point out that the programming model is the same. This is Blazor powerful features, you can learn a programming model, and make some adjustments in other places, you can generate any type of UI applications on any platform, which it is unable to do so before .NET.
Now, we have more understanding of the combination Blazor, I want to talk about Blazor Server and Blazor WebAssembly two main hosting model.
Blazor Server
Blazor Server hosting model is the only option supported by the product of the current Blazor development. During the .NET Conf, it is September 2019 and .NET Core 3 release together.
In this model, Blazor applications running on full .NET Core servers. When the user loads the application will download a small JavaScript file, the file server to establish a two-way connection SignalR real time. Then, any user interaction with the application are carried back to the server via the transmission connection SignalR, the server for processing. After the server is complete, all UI updates are transferred back to the client, and applied to DOM.
Now, I know what you're thinking. This performance is impossible to achieve, so that these interactive UI update and constantly sent back and forth. But I think you'll actually be surprised.
The team carried out on a number of Blazor Server load testing, to determine what it can handle and can not handle, here's what they found
Test 1 - Standard on Azure D1 v2 Examples (1vCPU RAM and 3.5GB)
The application can handle 5000 concurrently running user, without performance degradation significantly.
Test 2 - standard on Azure D3 v2 Examples (4vCPU memory and 14GB)
The application can handle 20,000 concurrent users to run, but the performance will not be any significant decline.
These figures are impressive, I think you will agree. It was found that the main memory latency and bottlenecks Blazor Server applications. If the delay time exceeds 200 milliseconds, the performance will be impacted, the available memory space is limited.
benefit
- Run on a run-time full .NET Core
- Rapid development cycles
- Small downloads
- Code is saved on the server, rather than downloaded to the client
Shortcoming
- It does not work well in high-latency environments
- No offline support - need to be connected to the server stability
- There are a lot of resources on the server demand
Over the use case
Honestly, I think Blazor Server can be used in many scripts, but also will be used in Intranet applications or user-facing low demand applications. Because everything on the server, so use this hosted model development speed is very fast. No separate API project, for example, you can use the application services directly in the assembly. At first, I was skeptical Blazor Server, but I have to say, I was very surprised by its functionality.
Blazor WebAssembly
Usually cause the greatest interest in hosting model, which is a good reason. The model is JavaScript SPAs (such as Angular, VueJS and React) provides a direct competitor.
By using WebAssembly, we can use C # instead of using JavaScript to write UI logic. Currently in preview state, it is expected to release in May 2020.
Compiled version of the application DLL WebAssembly Mono .NET runtime dependencies together and all downloaded to the client browser. Once everything into the browser, Mono runtime will be directed, followed by loading and executing application DLL.
The first problem to be solved I usually hear the results of the above explanation, the download size is how much? Well, the current preview weighs about 2.4mb, taking into account when it comes to the .NET runtime, which is indeed impressive. However, I appreciate compared with some JavaScript framework, it is not surprising. To the May release WebAssembly hosted model, the team hopes to substantially reduce the scale. When the first prototype Blazor uses a very compact .NET runtime, the runtime compiled to WebAssembly only 60k of the code. I believe that significant improvements size is only a matter of time.
Current, Blazor WebAssembly mode using an interpreter to load and run your application. In this mode, Mono IL interpreter will execute your application .NET DLL in your browser. The only compiled as part of the process WebAssembly is Mono runtime. In the future, the team hopes to allow developers to choose whether to be more likely part of your application or application also compiled as WebAssembly, this is known as AOT or Ahead of Time compilation. The advantage of this model is the performance, but to weigh the large download size.
benefit
- Compiled as a static file, this means that the server does not need to run .NET
- Transfer of work from the server to the client
- Applications can be run offline
- Code-sharing, C # objects can be easily shared between client and server
Shortcoming
- Payload. Now, if you create a new project Blazor, it weighs about 2.4mb. The team hopes to significantly reduce costs in May.
- Loading time. As the download size, poor connection of devices may require more initial load time.
- Limited running time. The application must run in the core browser, and subject to the same with any JavaScript application security restrictions.
Over the use case
Blazor WebAssembly designed to compete directly with modern JavaScript frameworks. Therefore, in any place you wish to use one of these frameworks, you can consider using Blazor. The Blazor WebAssembly application made for the PWA (progressive Web applications) is also very simple. In fact, in May there will be a template ready to use out of the box.
It is also important to note that the use Blazor WebAssembly does not require you to use .NET on the server. This means that if you are a useful back-end Node, PHP or Rails written, will be happy with the Blazor as a front-end, because Blazor WebAssembly can be compiled as a static file, so there is no problem.
What Blazor the future?
There are already a hosted model into production, another is about to go into production, let us turn our attention to the future.
I saw Blazor go? Back to my earlier thoughts about Blazor become any single UI framework in .NET applications. I think this is the direction of Blazor. If all current Blazor hosting models into production, and now I do not know why you do not, then the developer will be able to choose to learn a programming model, and can create the UI anywhere. this is a big problem.
While considerable discussion about the barriers to entry for .NET, and developer of the new platform had to face many choices, Blazor may UI, a single programming model, a learning process and applications to provide clear information. Anywhere. For me, this is Blazor speculation.
Tags: blazor, bulletin, c sharp, dot net, stackoverflow, web dev
Original link: https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/
