Blazor and what it means for web development

As a web developer I am amazed on web assembly and what Blazor could do with it. And, I am saying that even though I absolutely love what Javascript can do.

The Back Story

I had been hearing about this Microsoft experiment with web assembly (WASM) for quite sometime, but got an opportunity to take a further look starting late 2018. This was the time when news of Blazor being released as part of .NET Core started going rounds. At a later time this was expected to be server side Blazor. I can’t find the patience to go over the messaging confusion with Razor pages, Razor components, server-side and client-side Razor / Blazor. We will get back to that topic at some time.

NDC demonstrations are always great, and I got blown away by a couple of demonstrations that showed what Blazor can do. (another demo from May ‘19, another excellent presentation on Microsoft Developer channel).

  • Code in C#
  • Same code for client and server
  • Shareable code

None of this is path breaking in the Javascript world, but what I was interested was in Web Assembly.

Web assembly has been in development for quite sometime and, today, enjoys good support in major browsers. Web assembly has been an accepted standard across the industry and that is the major difference between the capabilities offered by WASM vs. similar applications of the past like Adobe Air, Silverlight et al.

Web assembly is also exciting because we can literally wipe away the difference between devices and get our web applications the respect they deserve.

  • Run a full-fledged app in browser
  • Run almost any app
  • Complete offline capabilities and seamless online/offline switch
  • True cross-platform with natural native capabilities using native libraries

I mean, what more can anyone ask for? Even the man in the Tolstoy book would want to start working in this technology rather than trying to walk full day to acquire land.

Where I stand today?

As we came closer to .NET release schedules, we learnt that .NET 3 will be late 2019 and may not have full-time, production-ready client-side Blazor.

By this time, those schedules did not matter much to me.

I was going through the previews of .NET 3 and was quite surprised by what Microsoft could achieve. Though the documentation was sparse, we could follow the architecture of a .NET Core application of yore, and have a web application delivered to the client - DLLs and all. The toolsets that came with and promised for later releases are expected to push developer productivity to newer heights.

What I liked about Blazor other than the part that it could deliver a fully client-side app was -

  • More succinct code
  • Tooling. Visual Studio is much faster and better than what it was
  • Integration with existing Nuget packages incl. those for integrating with Office apps

What I don’t like -

  • Boiler plate. Man, I did not quite remember the amount of boiler plate code I was writing at the time
  • Super picky type-safety. Our beloved Typescript allows us to cheat, C# does not give a damn about what we love
  • A not-so-nice to work with ORM in Entity Framework Core(Dapper can potentially change that - but I don’t have experience there)

I am on the fence with SignalR.

What is the future?

As we see more and more of WASM, and the support for WASM in multiple languages (incl. Rust, Javascript etc.), we will probably blur differences between desktop/web applications to a large extent.

What I intend to do with .NET Core 3 is to write applications that depend less on server side infrastructure (so server-side Razor does not interest me much). I intend to create a few simple apps where users have full control over their data, choose their own back-end without limiting the web front-end experience - all without sacrificing easy upgradeability and at super minimal costs.

What time to be alive, eh folks?

Last updated:
Categories: Misc,
Tags: Blazor
comments powered by Disqus