Web development has always been synonymous with JavaScript development. That is, until now. As a software developer with many years of experience in web development, Microsoft’s new Blazor framework has captured my interest. Blazor is a Single Page Application (SPA) framework that is becoming mainstream. Its success is due to a unique implementation of WebAssembly which opens the web ecosystem to .NET developers.
WebAssembly (wasm) is a binary instruction format for web browsers that is designed to provide a compilation target for high-level languages like C++. In 2017, Microsoft began experimenting with WebAssembly to bring .NET to the browser using the Mono run-time.
Mono provides the plumbing for .NET libraries (.dll’s) to run on WebAssembly. The WebAssembly-Mono-Blazor stack enables web developers with a full stack .NET application platform that doesn’t require writing JavaScript, furthermore it doesn’t require the user to install any browser plugins.
Introducing the concept of a “non-JavaScript web” immediately brings forth the question “What Does WebAssembly Provide That JavaScript or TypeScript Doesn’t?”.
My answer comes with a great amount of bias and opinion, and I feel it should as not all developers, projects, and tools are the same. For me the answer is clear, and short, “choice.” Opening web development beyond JavaScript means choice and the freedom to choose not only JavaScript, or .NET, but an even wider array of options. More precisely and personally, I have the choice to develop a web application using tools and languages that I’m already using elsewhere.
SEE ALSO: Is now the time for gamification in software development?
npm and Webpack
One of the benefits of opening the web to .NET is that we now have alternatives to npm and Webpack. As a long time, .NET developer, I’m greeting NuGet package manager and MSBuild with excitement. For me, these technologies are less problematic, more familiar, and far more productive. While nothing is ever perfect, my relationship with NuGet and MSBuild has been mostly positive.
At first this may come with the impression that npm and Webpack are somehow bad, and that I’m advocating to abandon those tools, but the opposite holds true. npm and Webpack are great tools and they will likely be around for quite some time. If your JavaScript tools work well for you and the apps, you create then this is a wonderful thing. Having a long history of experience with the web, I understand why npm and Webpack exist and appreciation for what they have and will accomplish.
Reduced learning curve
One thing that shocked me about Blazor is how genuinely simple it feels to use. Blazor combines the ease of Razor with other .NET concepts. It has borrowed the best patterns from popular JavaScript frameworks like Angular and React while leveraging Razor templates and provided parity with other .NET conventions. This combination of features allows for the reuse of skills in a way that was unavailable before. The same could be said for Node developers who use one language and familiar concepts in full stack JavaScript apps.
You’ll find the Razor Component model very familiar to working with ASP.NET MVC or Razor Pages. Razor Components incorporates the Razor syntax with a new method of encapsulating markup into reusable components. With Razor Components you’ll quickly create the building blocks of your application’s user interface (UI). Components are .NET classes whose properties are component parameters; this basic system makes Razor Components easy to author. By breaking the component model down into three concepts: directives, markup, and code, we can understand how they are created.
While Razor Component, and Blazor Component are widely used interchangeably, the correct terminology is Razor Component. This is important when searching online as both terms are quite prevalent.
Figure 1: A breakdown of Razor Component, the most basic building block in a Blazor application.
In Figure 1, components use directives to add special functionality like routing or dependency injection. Syntax for directives is like what’s used in ASP.NET MVC or Razor Pages. Component markup is primarily HTML which is enhanced through the Razor syntax. The Razor syntax allows C# to be used in-line with markup and can render values in the UI. The component’s logic is written inside a @code block. This is where component parameters and data bound values are defined. Alternatively, code be referenced using a code-behind approach much like ASP.NET WebForms. We’ll cover the code-behind approach in a later chapter, but for now it’s good to know the option exists. The Razor Component model allows us to break down our UI into manageable pieces. Components can then be assembled into larger UIs forming more complex components and pages.
SEE ALSO: Node.js is Dead – Long live Deno!
Blazor interop
Blazor applications can make calls to JavaScript, providing a migration path for APIs that are beyond the reach of pure WebAssembly. Because Blazor is new, the Blazor interop allows developers to fall back on JavaScript when there are shortcomings of WebAssembly itself, or because the Blazor framework does not provide access. A block diagram of the application stack can be seen in Figure app-stack.
The interop is an abstraction layer that many developers will work with in C#, and they will not need to worry that underlying technology is still executing JavaScript code. Over time the need for abstractions will decrease as WebAssembly matures.
Moving forward
If developing for the web using .NET as a JavaScript alternative is of interest to you, then Blazor is worth investing time in. The promise of a widening ecosystem with .NET has not only gotten my attention and created a thriving community as well. As a huge fan of web development, I want to see it move forward and expand ideas of how apps are written for the platform. The prospect of leaning on years of .NET experience to build apps in a way that makes me more productive is exciting to say the least.
The post Microsoft Blazor to become mainstream in 2020 appeared first on JAXenter.
Source : JAXenter
