Microsoft Blazor – End of JS Era or new “Silverlight” deception? Part 29 min read

And we started with Blazor …

This is Part 2 of 2. If you missed Part 1, go check it out.

So, where Blazor fits in? Simple, it is using WA as a core engine to run dll’s written in C# directly on the browser. But first, what is Blazor?

Name formula – Blazor = Browser + Razor.

So, the name is explained, although should it be Brazor, since Browser and Razor, but I guess it has too much similarity with …. never mind, moving on!!!

OK, this is the magic behind:

First, you write your code, shiny new application, and when it is done (definition of done: You wrote your code, cover everything with unit tests and integration tests if necessary … you do write unit tests, right? Give it to your friends, family, kids to do QA, and if everything is OK, which I seriously doubt, at least in first iteration, it is called done). Next step is building your dll from it. Those dll can be read with mono.wasm (what is mono), which is nothing less than web assembly file. That file knows how to deal with dlls. And everything is running inside web assembly runtime, which ends up with your application displayed in browser. And you didn’t write a single line with JavaScript. Is that awesome or what?

But (there is always but), do we run JS free application? No, let’s remember what is actually going on under the hood. Remember when I wrote that wasm file cannot be ran without JS. That is the case here. Take a look at next figure:

You see your dlls pulled to Web, but there is also JS file for mono. It is JS loader, file that jump-starts mono.wasm in Web Assembly Runtime. So, answer is no, better to say NO! So the next question is why are we so addictive to JS? Reason is simple, almost 30 years we are shaping Internet with it. It is like we have new revolutionary car engine that needs a gasoline engine just to start, and once is running, you have zero emissions and by-product is oxygen and beer. Type of engine that will beat all current car engines. But can it be applied instantaneously, by replacing every car on planet? No, you still have something like 10 billion cars with old engine, driving all around the globe. In time you will reduce the number of old cars, but it will take time. Same thing is with this, we have new engine, that still needs to be started with JS, but after that … have a deep breath and have yourself a pint.

Random thought

“This article started to sound like roasting poor JS, blaming it for world hunger and all wars, but it wasn’t the intention to do so. I think of it as a great revolutionary technology, but it is going out of fashion for some time now, because people are searching for something more. The Internet is developing, moving forward. Today we watch TV, listen radio, play games on it, feels almost like bringing some old fashion back again. It looks like it is moving to terminal ages again. For all of you that don’t know what is that, here:

Back in those ages when Heavy/Hair Metal was mainstream (or even earlier), major companies used terminal computers, one huge computer with bunch of terminals used by developers. They had to stay in queues to build what they did (Imagine creating a bug back then, and then fix it, and then go back in the queue to see if it is OK now).”

The future of Blazor

Currently Microsoft is pushing Blazor to release by any means, which is resulting by some cutting offs. This version that is currently in preview, 0.8x, works a bit hacky. Why? The intension is not to push dlls to web. It is just a first step of “make it work” process. I see it as proof of concept phase. It is sort of efficient, and it is more like a demonstration in “because we can” manner. The future is more interesting than what we currently have in this preview.

This is what we have right now:

And this is about to come (hopefuly):

Comparing those two images, there is a slight difference, but also revolutionary. DLLs described in first figure are loaded via mono.wasm in runtime, but in second they are compiled into wasm file, and after that bound with mono.wasm. So, no need to load dlls in the browser any more. I’d say, it is more natural, since we have WA.

Now, why am I all suddenly against dlls on browser, and all the time I write hymns to that?

There are some major disadvantages regarding pulling dlls down, and I’d like to open a header for that later.

Now I’d like to talk what Blazor offers in this moment.

Blazor Templates

With current preview (0.8x), Blazor offers three templates:

• Client
• Backend
• Both (Client + Backend)

To be honest, all this time I was writing this article with my mind set on client. Simply, running all this on the backend is not some news. But hey, Blazor offers that as well. You can write server application running without web assembly. If you like the idea, you just lost a half an hour reading something this Blazor template is not.

So, the Blazor in this case is ran on server thread, and does communication with UI thread using SignalR technology (SignalR???), meaning that Blazor components are executed on server, and JS interop, client tasks and so are executed on client side. Communication between those thread is executed via SignaR.

Some will like this concept and some will not. Personally, I cannot think of some application I’d do with this. But who knows, maybe in some future I find this as “It is a matter of life and death” technology.

What is more interesting is the third option that gives you everything you need, backend + frontend. Since Blazor is a component related framework, designed firstly for SPA (Single page applications), and we all know that SPA is powered by some REST service. This template provides that all. You have a client side, and server side in solution. It all comes as a demo application that is all set up, basically all you need to do is just continue with development.

Blazor disadvantages

One of the first disadvantages is also the one that made Blazor revolution on web; DLLs on browser. We all know C# has nuget packages, that are nothing more than DLLs of some external library. Those libraries are written for some time now, since the age of early Rave music. And there was never a need for those to be compact and small since those packages was intended for backend applications. Which means that great portion of those are useless for web. Imagine pulling down DLL of 10 MB to your web application. And yes, you can use any nuget you can find in nuget server with Blazor.

So, the future of Blazor depends also on vendors that does popular nugets, to compact their packages and prepare them for web.

If that is the only disadvantage, we can live with that, right?

Unfortunately, no, there is plenty more and not just with Blazor…

What is the most awesome thing about Single Page Application development? And they all have it, Angular, Vue, React ….

Yes, hot reload!

You change something, it recompiles without hitting a refresh on browser. I became addictive on this feature, which is causing me issues with old applications. Sometimes I fix something on some old jQuery code / HTML, switch back to the browser and nothing changes. And of course, after 30 seconds I realize I need to refresh the page manually. And bad news is Blazor still doesn’t work this way. I read they are working on this and I believe they do, but still you need to refresh manually. And I’m afraid that is not all. Running client with Visual Studio 2019 in debug results opening page, but it will not recompile even on page refresh. You need to add Watch in project csproj file to make it work:

<Watch Include=”**\*.razor” />

And you cannot run it from VS. You need to use console with this command:

[syntax_prettify]dotnet watch run[/syntax_prettify]

I came across some forums where part of people is swearing this works even when you hit Ctrl + F5 in VS, and I could put my hand in fire but I believe I saw live demo showing this feature. I believe it was the older version of Blazor, and they had it all sorted out back then. Reality with this version is that it is simply not working as it should.

Furthermore, regarding Visual Studio, creating .razor file results with exception, so the only way of doing this is copy/paste existing file.

Conclusion

So, conclusion … It is still not ready for production. I’m sure that this will be awesome once they fix all these bugs, and frankly I can hardly wait they do. Blazor started something great, hopefully it will live long enough to provide us a choice for web development.

End Part 2 of 2.

If you missed Part 1, go check it out.