π In this post, we'll address some common Blazor questions. Specifically, the "what?", but more importantly the "why?". Why should I care about Bla...
For further actions, you may consider blocking this person and/or reporting abuse
Nice writeup π, I think The only issue with
Blazoris initial load speed. Other features are fine.Thank you @shaijut - Depending on the hosting model, initial loading speed can vary - that is true. With Blazor Wasm it's very similar to the initial page load speed of other SPAs, such as Angular and React. However, there are optimizations being built out to provide "assembly trimming", pre-rendering, compression, etc. It's only going to get better With Blazor Server, it's much faster. If this is the only issue you have, I'll take that as a success. π¬
Have there been any more recent work on performance? I know it's been a WIP but I've never seen anything really benchmark as slow as Blazor WASM. Some WASM technology is starting to comparable to JavaScript for DOM rendering so I've been wondering if improvements been made.
Source: github.com/krausest/js-framework-b...
Current Results: krausest.github.io/js-framework-be...
Rust WASM is 4th(albeit with no framework abstraction, fastest Rust framework is like 30th), Blazor is 2nd to last.
Not that I have any attachment to Rust just that I've heard hype but everything I've seen suggests completely the opposite.
I was trying to profile the realworld demo about 6 months ago:
blazor-conduit.netlify.app/
And I got one of the highest scores I'd seen a 99. But then I realized it was because it took so long on the loading screen Chrome Lighthouse that it was done loading right at the start. Things have gotten better since then and I'm getting actual scores in the 30s.
While that is the official listing on codebase.show/projects/realworld I assume there are probably issues with it. Those 2 are just the place that people commonly go to look at JavaScript frameworks. Are there any better performance comparisons?
Both of the sample apps you link to were written more than a year ago and are not using current versions or even RTM versions of the framework.
Letβs update them to .NET 5 and perhaps even take a look at the numbers in a current .NET 6 preview to see how they perform
I agree with Jeff Fritz, these are dated but to your point Ryan - we should do a better job of actively benchmarking the performance of things like DOM rendering, initial payload, and all of the metrics that Lighthouse offers (first contentful paint, time to interactive, total blocking time, speed index, etc.). I'll ask around, and can only assume that this is something that Steve Sanderson already has on his radar. Thank you
It in no way shape or form even competes with load speed, first render, etc on those frameworks unless you have an incredibly poorly engineered TradSPA(tm).
But don't take my word for it, here's a near-hello-world James Newton-King put together on the latest recently for serialization testing that takes 8-13s to first contentful paint on a fast connection with low latency, even with brotli compression:
grpcblazorperf.azurewebsites.net/
For ref: That's 60s on fast 3g, with a whopping 23mb into cache (literally as much as youtube's landing page).
The other thing to note is that there's typically an ~1s gap between the completion of dotnet.wasm download and the actual page render, so the first render after a massive download is another 800-1000ms.
Our performance budget is application-related downloads need to be < 200ms on a 1mbps connection, and first contentful paint should be shortly after that (500ms).
Server side rendering: I can't share how I feel about "just throw a fleet of servers at it and it gets way faster," on this site. We're doing 1M requests/s with dotnet core apis on an EKS setup with just a few small nodes and an Angular application that meet our perf budget. All I see at build/etc is Blazor, blazor, blazor, but it's not a realistic option for anything at this point in time compared to tech that's already standard in the dotnet community.
This issue is mitigated in .NET 6
What about cost? That doesn't get mentioned much in Blazor articles but when I checked, Blazor server requires SignalR for every single person who views your site (not just clicks buttons), which means you have to have capacity not just for how many people take action at the same time, but how many people actually visit your site at the same time.
According to Azure SignalR pricing, 1 unit can serve 1000 connections and costs approx $50/month. This charge is in addition to your web application plan which is also going to be a minimum of around $50/month. That is $100/month for 1000 visitors and an additional $50 per block of 1000 visitors.
As a startup, that seems like an expensive proposition. Can you speak to the real world cost of running a blazor server app? I love the tech, and it's great, but I'm concerned it may not be cost effective outside of an intranet site. Am I understanding the cost model correctly?
Hi Wes, this is a great point to bring up - I touched base with Daniel Roth on this. Here is what he said:
The choice is yours, and I can tell you that I'll be using Wasm over the server-side option. But I may still choose to add SignalR functionality for other aspects of my apps.
Blazer is awesome and glad it's brought a client side option to C# developers (F# devs have had some options for awhile with Fable).
I wish that the focus on Blazer didn't pull so much attention away from classic server side HTML generation with Razor. I feel like Tag Helpers and View Components won't get many enhancements now that everything is pushing Blazor as the solution.
The ASPNET team looks to the community for direction and the community is hyped on Blazor π€·ββοΈ
This is an interesting observation. At the end of the day, the Razor view engine is shared - yes, that is true. But the way I see it, improvements made to it for Blazor will also be applied to other use cases where it is prevalent.
I would love for the Blazor component model and server-side rendering process to made available for traditional server-rendered HTML.
Web Forms did a lot of things that needed corrected once the web became a more robust platform, but it did have a really rich component model which MVC never got.
I feel like Tag Helpers and View Components could be expanded to do things like content projection and better composition. Since Blazor's rich component model already has these, it would be really cool to see them made available to apps that don't intend to ship all the Blazor bits to the browser.
Blazor is a potential disrupter due to the power of C# and things like WASM, Security, LINQ, EF, Newtonsoft, Azure, VSCode and VS2022. Isomorphic from top to bottom. TypeScript falls inline as well.
The best eco system anywhere. My original Blazor skepticism has vaporized with just 2 days of use of VS2022.
I still am nervous about getting dumped like MSFT has done before, this time, hopefully; they are settling in on a single architecture for good. Their last repair work is to unify the desktop after 15 years of horrible direction.
Quality write-up, thanks.
Wow, great piece about Blazor.
Thank you very much Michael!
Reduced Blazor WebAssembly download size with runtime relinking in a new feature in .NET 6 Preview 5
Nice article. The snippet of code for counter app looks similar way svelte components are written.
Indeed, lots of the available SPA frameworks today are fairly consistent with how their templates handle binding.
Awesome article. Thank you!
I enjoyed using Blazor and it is a nice alternative to have alongside React and Vue.
Thank you so much for your kind words. I happy you enjoyed it.
Exelent, thank you
You're very welcome, thank you Emilio.
Nice and clear π
Thank you, much appreciated.
Silver light...
With that statement you probably think GitHub is bad since Microsoft develop Source Safe decades ago and now maintains GitHub?
Blazor was born from the work of Steve Sandersson.
Yes, Ollie - "SilverLight"? What about it, Blazor is not that - it's a come misconception. I even called attention to that in this article. As Fredrik alludes to, Blazor is different.
Server Template
Missing a Blazor vb.net Server template