BETA POST: this post must be improved a lot, as soon as I will have time to do some test on Blazor.
Anyway, because it is a long time since I started to write it (December 2018!!), I publish it as it is because it contains anyway some link that can be useful to someone ….
As said in Blazor.net site, Blazor is an experimental .NET web framework that allows to build a Web UI using C#/Razor and HTML that runs in every browser with WebAssembly (that is every updated browser families – desktop and mobile – released since mid-2017). So the secret behind Blazor is WebAssembly, a standard, binary instruction format that provides a portable target for compiling high-level languages. Blazor project stated in February 2018 and it has an update every two months.
It allows a full-stack web development, using stable and consistent tools, languages, and APIs both in the browser and on the server. That project aims to do what earlier efforts like Silverlight could not, that is to enable developers to write .NET-based Web apps for the browser without a plug-in.
In fact it runs in all updated browsers on the real .NET runtime with full support for .NET Standard, it requires no plugins and no code transpilation, but only open web standards. Moreover a Blazor.net site works even in older browsers too, by falling back to an asm.js based .NET runtime.
Blazor runs completely inside the browser and once a Blazor app is compiled, it’s essentially a set of files that gets loaded into the browser and runs. Unlike traditional ASP.NET applications, there’s no need for anything special on the back end to serve it so a Blazor site can be served by any Web server on any platform.
Blazor apps access Web services using HTTP REST APIs that can be created using Microsoft tools, such as Web API, or whatever technology that can present an HTTP REST endpoint.
Latest Blazor release explored running Blazor in a separate process from the rendering process. For example, you might run Blazor in Web Worker or even server-side on .NET Core, and then handle all the UI updates and event handling over a cross-process channel.
Many work need to be done improvement of WebAssembly-based .NET runtime, so smaller download sizes, better runtime performance and support for .NET Standard 2.0)so it is still an experiment-in-progress project, but it could redefine Web application development. Anyway in following available examples clearly show what it can be already implemented … and it is not much more you can think!
To get started with Blazor and build your first Blazor web app, check out its getting started guide.
In the following you can find the link to some recent articles already published on MSDN magazine where most of the information of this post was taken. You will find even more articles in the future in that Magazine site, searching for “Razor” [be careful that the search engine page of the MSDN site seems not to work with Internet Explore, so please use Edge]:
[NOTE: you can get MSDN articles automatically translated in Italian changing in the URL /en-us/ with /it-it/ (e.g. https://msdn.microsoft.com/it-it/magazine/mt833274.aspx )
- Cutting Edge – Hierarchical Blazor Components (by Dino Esposito | March 2019 | Get the Code)
- Cutting Edge – Dealing with Forms in Blazor (by Dino Esposito | February 2019 | Get the Code)
- Template-Based Components in Blazor (by Dino Esposito | January 2019 | Get the Code)
- Cutting Edge – Blazor Custom Components (by Dino Esposito | December 2018 | Get the Code)
- .NET Core – What’s Coming in .NET Core 3.0 (by Scott Hunter | Connect(); Special Issue 2018)
- Cutting Edge – Blazor at Work: Events, Binding and Composition – (by Dino Esposito | October 2018) – Get the Code)
- Web Development – C# in the Browser with Blazor (by Jonathan Miller | September 2018 | Get the Code)
- Editor’s Note – .NET in the Browser (by Michael Desmond | September 2018)
Here an other GitHub project with Blazor examples: https://github.com/aspnet/Blazor
Other useful links:
latest Blazor release explored running Blazor in a separate process from the rendering process. For example, you might run Blazor in Web Worker, in an Electron app, or even server-side on .NET Core, and then handle all the UI updates and event handling over a cross-process channel.
Blazor running on the server-side and using SignalR to connect with clients. The approach eliminates the need to download a full .NET runtime to the browser. The nice thing about this model is that it’s completely symmetric with running Blazor in the browser, but all the existing .NET libraries and tools just work, and you don’t have to pay the cost of downloading a full .NET runtime into the browser.
Blazor remains very much an experiment-in-progress, but one that could redefine Web application development. This much is certain: We’ll be keeping an eye on this promising effort in the months and years to come. (Michael Desmond is the Editor-in-Chief of MSDN Magazine).