Let’s examine the possibilities of creating an application with Blazor instead of a SPA based website. The case study I will use for this is YouTubeDownloader. It is simple enough to understand and has just enough technical challenges as a web site. The application lets the user search for a video, then select the video to download from YouTube.
What is Blazor?
Who am I?
I’ve been developing web applications for a living since the mid-nineties. I’ve worked through the CGI era, the server-side scripting era, the server-side compiled era, the client-side AJAX era, the client-side SPA era, and I’m just starting on the Web Assembly era. Yes, I think it's the beginning of a new era in web technology.
I am not the maintainer of YouTubeDownloader, I’ve just used it before and understand how it works.
The first limitation here is interactivity. When we have a video ready for download it’s going to drop it into the download folder. We don’t have access to any other storage space. The application would work very much like y2mate.com and not feel much like an application.
The second limitation is offline support. We could just download it to the server and then play it, but that sort of completely missing the point of the application.
The third limitation is hosting costs. All the video processing is going to take place on our server, and we need to store the converted videos for a limited time. This is not an application we can host on something like the free hosting offers from Azure. This could get quite expensive under load. We could overcome that by having each user host their own copy of the application, but most users are not going to do that.
The fourth limitation is throttling. If YouTube suddenly starts to see abusive spidering of their site, they could block it entirely. I believe that’s what happened to podsync.net.
In our case we don’t have any API limitations because this application uses a web scraper and not the official API, but API usage is quite common. Most APIs will limit you to several calls over a given time, like a day. Server-side applications can help limit those calls by caching data, but that increases hosting costs. Other APIs limit the calls by IP address, which hampers a server-side solution since they are all coming from the same place.
We would also need to worry about API keys. If your application needs to access an API you are going to have hide that key by communicating with the API from your server. This is an issue that will follow every single application model. If the key is on the client, it is vulnerable.
Client-side Blazor does its magic by running C# in Web Assembly, the newish standard for compiling code safely to run in the browser. This would seem to be the holy grail and the savior to our server-side limitations, but there are other challenges.
The second limitation is processing and RAM. Web Assembly is limited to a 32-bit process and 4GB of RAM. For most applications this is not going to be an issue, but video decoding is another beast.
The third limitation is sandboxing. YouTubeDownloader uses a third-party decoder, FFmpeg, for anything higher than 720p. We won’t be able to use that feature because we can’t download and launch another application not designed for Web Assembly.
The fourth limitation is storage. What started as a MB limit for Web Assembly has grown to a percentage of your hard drive. Our application is going to be okay on most browsers and devices. However, it is always possible that the browser cache will get cleaned up and all downloads lost.
The fifth limitation is debugging. At the time of this writing, Blazor does have the ability to debug client-side applications in Visual Studio and Visual Studio Code now, but it is limited, buggy, and you‘re’ going to feel it. This is likely to improve drastically and quickly, so by the time you are reading this article it may be a non-issue.
Progressive Web Apps
This is an extension of the client-side model. It is available out of the box by simply selecting an option on the template. It brings us several nice features but does not prevent any of the limitations of a client-side approach listed above.
Now we get to the option that eliminates every limitation I have mentioned so far, except the need to secure API keys, which our example does not have. Creating a desktop application lets you use the server-side template with all its power and deploy a client-side application with all its benefits.
The limitation here is there is no official support for native applications yet. It’s on the roadmap, but it's not done. So, we need to apply a wrapping technology to host the server-side application we create.
The good news is, it's extremely easy to wrap Blazor with Electron.NET and it does work, even if not officially supported yet. It will work on Windows, Mac, and Linux. Applications you may already use have taken the Electron route like Visual Studio Code, Slack and Microsoft Teams. But Electron does have one big issue: it's a memory hog.
An alternative is WebWindow, a super lightweight alternative to Electron, but its experimental and not ready for production apps.
You may consider distribution another limitation. You’ll need to deal with an installer or a store to get your application in the hands of your users.
This, like desktop applications, eliminates the web limitations.
The limitations here are also the same as a desktop application in that there is no official support and you must handle distribution.
I have not been able to find anyone that has tried Cordova, aka PhoneGap, with Blazor. In theory it should work. WebAssembly is supported in a WebView on Android and WKWebView on iOS, which is what Cordova uses.
The Blazor team itself is currently moving in a different direction and trying to integrate Xamarin and Blazor with Mobile Bindings. This like WebWindow is also experimental. But at least it has an entire dedicated section to it on Microsoft’s documentation site which is more than can be said about WebWindow. This also seems to line up with Xamarin Forms future as Maui.
Our application has another limitation, video processing is intense, and it could rip apart your mobile device. The library I am using will limit it to 720p which is okay for phones but not great for tablets.
I do see a future where Blazor runs everywhere from watches to televisions. .NET Core is very portable, as the team has proven by getting it to work on Web Assembly. Target as much code as you can to .NET Standard libraries, and you're bound to find a way to create an interface in Xamarin or Uno today that meets your needs.
If you are going to create an application today with Blazor I would look at the following options in the order listed until you land on a solution that works for your application:
- Electron + Mobile Bindings
You absolutely can find a way to port your application to Blazor, but if you land on option three you are on the bleeding edge and in unsupported territory.
If we were to try to port the YouTubeDownloader application to Blazor today I would land on option three.