Some slightly informed impressions of Blazor

posted by Jeff | Saturday, September 26, 2020, 1:00 AM | comments: 0

After my previously mentioned intrigue about Blazor, the .NET solution for WASM (Web Assembly), I went a little deeper tonight to see if I could make it work with something a little more substantial. I figured that my experimental cloud-based music locker would be perfect for this, maybe because I could even recycle the components later for mobile apps, and also because I could see what it's like to tease out data on the client with libraries I'm used to using on the server. Keep in mind, I won't actually use the client to pull out album covers and meta data from MP3's and then send them both in the long run, I just wanted to see if I could.

I'm using the .NET v5 release candidate, because it includes a lot of new goodies that weren't previously available, including an upload component. The first problem is that debugging is broken, because the port used for listening is blocked when you run it repeatedly. None of the errors really imply this, so I messed around for a half-hour before figuring this out. The solution is to manually kill the dotnet.exe task running. There's a Github issue for it, I'm just disappointed that they shipped a release candidate with this problem because it's so critical to first impressions. It also appears that you have to watch for exceptions in the browser dev tools, which is a little janky, but I can roll with that for now.

My mission was to read a bunch of files in the browser, and using the TagLibSharp library, tease out the metadata of the MP3's, serialize it all and upload it to an Azure Function at the other end that could deserialize it. Again, in real life I'm not going to serialize a binary file, but this was for science. First off, it was really cool to use a library in the browser that I would normally use on the server. Second, even serializing and deserializing byte arrays worked with the updated serializer. And of course, the magic is that the server function and the client shared the same model code. That's pretty great. Imagine using the same validation code on both ends!

Beyond that, I didn't do a lot of typical UI stuff, but binding data and handling UI events is pretty straight forward. Navigation links and context works as expected with a helper you can get via dependency injection. And yeah, the DI you're used to is also there, and it looks like the configuration model is about the same. It really is .NET running in a browser. No dealing with hundreds of megabytes of npm packages to "Hello world" or any of that.

The learning is fun, but there's always that thing in the back of your mind where you remember learning Flash, or Silverlight, and those are both history now. However, WASM is a bona fide standard and all of the browsers support it. Blazor, compiled down to WASM has matured a ton since its inception. The intentions are pretty clear, since it can also be rendered on the server, components can be shared in other ASP.NET server bits and you can in fact share code across literally all platforms now. It seems to have a lot going for it.

I'm going to mess with it more this weekend, because that music locker project seems urgent as Google Music is randomly (and probably intentionally) not working all of the time now. The cloud side of it is pretty straight forward, so I'm excited to see how easy it is to build a simple Blazor client.


No comments yet.

Post your comment: