When it comes to making a decision between multiple things — ranging from physical objects to software — you need to ensure that the objects are all related to one another or help achieve similar goals, and therefore, are comparable.
This is especially true when it comes to comparing frameworks. To make an excellent, fair comparison requires comparing things in the same category, with the same base features. All SPA frameworks/libraries have the same goal, and Blazor is no exception.
Blazor is a web framework for building modern and interactive web-based UIs with C# and Razor. Blazor can run on WebAssembly or the server. It’s also the first and only commercially supported frontend framework that utilizes WebAssembly.
I’ll cover BlazorServer later in this article, let’s stick with WebAssembly first.
To see the differences in action, I’m using a default Blazor template. I have .NET 5 installed on my machine. You can scaffold the project by command-line below:
dotnet new blazorwasm
To see how it compiles the project, execute following command:
dotnet publish -c Release -o ./output
It compiles and trims the .NET output assemblies to reduce the size of the application. Inside the output folder, _framework folder, you’ll see all assemblies. For people with a .NET background, most of those DLL files are familiar.
You might ask where WebAssembly is. Notice that next to these DLLs, there is
dotnet.wasm file with the size of 2.65MB; that’s dotnet runtime itself. To see how the application looks and works, watch the following video:
It loads everything that is needed and executes .NET codes on the behind.
Blazor’s output is WASM, unlike other SPA frameworks/libraries (Angular, Vue, React, etc.). WASM is the new standard and the future. Instead of running your codes in the browser JS engine, the browser executes your application in a binary format.
.NET/Mono runtime is compiled to WASM, and the rest of your project is still .NET Assembly DLL files. The .NET team and community are working hard to deliver WASM AOT so that you can compile the whole project into WASM bytecode.
WASM is fast, and it’s already compiled. It doesn’t need to be parsed or interpreted, and the browser runs it as-is. It’s as fast as native code. It’s excellent for performance-intensive cases like image editing, 3D rendering, video games, encryption, and the like.
A rich set of libraries in the .NET ecosystem: There are tons of powerful libraries that developers are using on desktop or backend applications. With Blazor, you can utilize them in your frontend application, too.
C#, statically typed language: C# speaks for itself — I don’t need to promote it. It’s powerful, and thanks to its nature and the tools that already exist, refactoring C# and .NET code base is easy as apple pie and with less chance of failure.
Follow design pattern architecture and more clean code: Already using multiple libraries for better application structure and design? Do you need dependency injection? Reflection? How about the MediatR pattern? Static analyzers? Everything already exists in Blazor. It’s mature, battle-tested, and industry standard.
Shared-codebase: The benefit of using .NET and WASM shows its values here. You already have different layers and services in your backend .NET application. Using the shared code from the backend to the frontend won’t be any problem.
For example, consider a scenario in which you already have a validation and security layer for your inputs because you already wrote them for your backend. Why should you rewrite them for your frontend? With Blazor, just reference the same project and use it like it was written for the frontend.
Remove the gap between frontend and backend development: With the mindset of sharing the code base, developing the frontend shouldn’t be that different from the backend — at least in theory.
But what’s different with Blazor is that you write your application in C#, and it will run as WASM and .NET on the browser — the same code, without any magic like what babel and webpack do. Not using JS could benefit default applications and developers who are not familiar with frontend development because it uses the same language for almost everything.
There is a reason why I say, “almost.” WASM code cannot access DOM directly (yet), but there are some workarounds to achieve it. Blazor supports JS interop; with that, it’s easy to call JS from .NET inside the browser.
With Blazor, it’s all about WASM and .NET. For companies and developers who have significant applications that are not yet web apps, they can, with some effort to redesign the GUI part, port their application for the web!
Even in other languages such as C++, Rust, etc., there is native support for WASM.
BlazorServer is different from ServerSide Render. You can activate it on your BlazorWasm project with the help of server mode, which means all of the logic will execute on the server and the changes will reflect on the frontend.
I’m not a big fan of this feature, but it’s a great help for many cases. It’s more secure because everything is running on the server, but there is latency.
This feature helps developers and companies save some time on their application development. They develop frontend and backend at the same time, and it can be hosted on a Docker container.
If you’d like to learn more, read this document from .NET team.
WASM and .NET are two functionalities of Blazor that make it difficult to compare with other SPA frameworks and libraries. Each tool has cons and pons, but in the end, they try to deliver a high-quality tool set to enable developers to make excellent products.
In my opinion, Blazor is excellent, especially for companies who want to migrate their legacy app to the web. It gives developers the option of harnessing all the power of the .NET in their application to create robust apps.
Hopefully, the community and companies that created excellent Blazor components will continue to add robust tools. The future is bright for web development. It doesn’t matter if it’s WASM or modern JS/ES web apps. The result is a robust application produced by you and your team.
LogRocket works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app’s performance, reporting metrics like client CPU load, client memory usage, and more.
Build confidently — start monitoring for free.
Let’s see how SolidJS props work to promote component reusability, exploring basic to advanced concepts for a complete understanding.
We evaluate Eleventy and Next.js and compare both static site generators in terms of performance, developer experience, scalability, and ecosystem.
We show how to use Goxgen to scaffold a full-stack React app. See how to integrate React with Go and modify Goxygen to suit your project requirements.