Why We Chose Blazor WASM for our SPA
Update 13th July 2021:
I am lucky enough to have spoke on the ASP.Net Core Community Standup where I share more information. Check it out here: ASP.NET Community Standup — Building with Blazor: Powered4.tv — YouTube
Powered4.tv is the UKs #1 video-on-demand site for independent wresting content, we feature hundreds of hours of content and over 50 channels.
We started in 2020 as a small team of 4 people, comprising of 2 .NET engineers and 2 business people. This was a side-project, meaning that everybody had limited time [due to working full time and having lives 😋].
Developer Productivity
Me [Steve Richard Peirce] and Josh Dadak are both .NET engineers who largely focus on distributed backend systems, this is our happy place! Choosing frontend tech was hard, so we decided to prioritise based on our own developer productivity.
Given our limited time each month and lack of day-to-day frontend dev work, we wanted our frontend tech to have structure, possibly an opinionated framework that would land us in the pit of success. We wanted to build MVPs and find market fit, not spend hours choosing between libraries, and configuring WebPack.
Our first choice was actually Next.js — this is a framework built on top of React.js which offers loads of great features, including out of the box TypeScript support, server side rendering, and much more.
But What About Blazor?
Before going with Next.js we thought about Blazor — this is .NET’s solution for Single Page Applications (SPAs) which is part of ASP.Net Core.
Blazor was appealing to us as it let’s you write SPAs with C# using all of the tooling we know and love (e.g. Visual Studio, Rider, or VS Code) and our familiar .NET libraries.
However, having followed Blazors progress I had concerns over its limitations and maturity — I expected it would be okay for an internal business application but perhaps not ready for a public facing site…
…still, it would be rude not to give it a try — after all; we are active members of the .NET community! 🙈
Aside: Hosting Models
There are 2 hosting models for Blazor on the web; Server and WASM (short for WebAssembly).You can find lots of talks and posts explaining the difference between the WASM and Server hosting models — we were mostly interested in WASM to keep costs lower by reducing load on our servers. There is significant download and performance differences, so be sure to read about both options.
Love At First Component ♥
So we did it — we tried Blazor WASM…
After creating our first projects with dotnet new and being greeted with a basic working app, we were able to experiment and learn quickly. With prior experience in React.js, Blazor’s component model was very familiar and intuitive.
We found it was easy to add pages/components, and quickly became familiar with Blazor’s paradigms. We loved being able to use C# to write a web app!
Configuring dependencies is a breeze — they are configured exactly the same way as we are used to in a standard .NET application using Microsoft.Extensions.DependencyInjection. Missing some functionality? Easy, just pull in your favourite Nuget package!
Overall we felt super productive and fell in love with developing in Blazor.
Trail-Blazors
So back in 2020 [net3.1] we decided to go full steam ahead with Blazor WASM.
We knew that there were some big pain points that were going to cause us issues, but looking at the community excitement, the investment, and the upcoming Blazor Roadmap, we were super excited for the future of Blazor and made a decision that any pain points will be resolved [hopefully].
Worst case? We would port across to Next.js 🙈
The Pain Points — June 2021 Review
So after about a year of developing Powered4.tv in Blazor, what were our pain points and have they been resolved?
In short, yes!
Well, largely!
There have been so many improvements this post will never do justice, but here is a brief summary of some that excited me.
Pre-Rendering
Pre-rendering is when the server renders the HTML server side, this is great for Search Engine Optimisation and providing a great customer experience.
Back when we started you needed to *botch* server-side pre-rendering (e.g. my article Server Side Render Blazor Client Side App (WASM) | by Steve Peirce | Medium) — but this left a weird page flash which was not a nice experience for customers — everybody commented on it.
Fortunately, this has been resolved since .NET 6 preview 2 where we are able to preserve our pre-rendered state avoiding the loading flash. Check this out on Powered4.tv.
Performance
Performance in Blazor WASM has always been slow when compared to a JavaScript app — we find start-up the biggest issue. Once the app has loaded it’s generally super fast for general use (e.g. navigating between pages). Right now you won’t get great scores in Lighthouse, but we cross fingers for the future.
We have seen continued improvements to the IL interpreter with notable gains upgrading from net3.1 to net5.0, and some gains upgrading to net6.0 previews.
There are now various perf tweaks available such as lazy loading dlls and js.
.Net 6 Preview 4 introduced AOT compilation — that means we can compile our code directly to WebAssembly instead of dlls being interpreted promising significant perf gains (in exchange for a slightly larger download).
Look out for a future post where we turn AOT on and compare differences in performance and download sizes!
Other
- Css/JS was difficult to manage — lucky for us .Net 5 introduced CSS Isolation and JS Isolation
- Some “basic functionality” missing — such as setting
<head>elements including<title>and<meta>tags dynamically. Fortunately libraries such as Toolbelt.Blazor.HeadElement make it really easy. - Dev feedback loop was quite slow — when making a change to a component or style you would have to wait for the app to restart before seeing a change. As of .Net 6 Preview 3 our prayers have been answered with Hot Reload. Hot Reload will update the running application with your UI changes whilst keeping application state, and it’s ridiculously fast!!!
- Testing has matured over the last year. With libraries such as BUnit , Verify and Playwright, we can match the same testing strategies that any modern UI developer would expect.
- Download Size — The smallest Blazor App is always going to be bigger than the smallest JS App. However, our site is an on-demand streaming site so we decided a slightly larger download is acceptable. Over the last year download sizes have reduced, and continued work with IL Linker that does tree-shaking to remove unused code from downloaded binaries.
- Much more…
The Future Is Native Apps
Powered4.tv is currently a Progressive Web App (PWA) — we can install the website onto a Phone/Tablet/Laptop straight from the browser. Installing a PWA adds a shortcut to Home/Start, and let’s you open the app without the browser — very nice.
But what if we wanted the app in the App Store for exposure/reviews/etc? Well we could bundle it up with the help of PWABuilder [Other tools are available].
Apps running like this are still just Blazor running in the web browser — it is good, but can we do better?
What if we could get the native device performance? If we could replace some controls with native UI? If we could easily hook into the native APIs for each device?
That’s where we’re hoping .NET MAUI can help us [coming in .NET 6] — where we get exactly that! We will be able to package our existing code into a native app to be submitted to the Apple, Google Play and Windows stores.
Checkout ASP.Net Community Standup from 8th June 2021 to see it in action!
Summary: Was Blazor the correct choice?
1 year on and we are super happy with our choice. There are still a few rough edges here and there, but the rate of improvement is amazing.
New previews of .Net6 are coming out each month; with each new update I am more productive, and impressed with new features and performance improvements.
I urge you to try it out if you haven’t already!
