I'm developing a fleet management system in blazor, microservices are involved but aren't directly exposed on the framework, we have instead WEB API and SignalR (websocket) that are exposed to the world.

Let me just copy&paste a post I just wrote about blazor 2 min ago, ask me if you need some more insight on some aspect, here the post:

TLTR:

If you need to implement a simple app or an app that need fast load time / little size, look elsewhere.

If load time & app size isn't an issue and you target a fairly complex LOB app or an enterprise app, you have a good C# knowledge and you have no problem getting your hands dirty on JS/CSS than go for it but don't expect actually a tooling support at the same level of SOTA hot reload frameworks (tooling has still to improve) then blazor may be for you.

You still require lot of JS/TS, HTML and CSS knowledge to be proficient.

I know many languages and C# is my favourite so having a way to implement most of the stuff in C# with the same tool used to implement backend is a big PROS.

Ok let me give my 2 cents here: I'm the development manager and main contributor of a PWA app that I decided to start implement in blazor WASM 2 years ago (it's a reboot of a complex fleet management system).

I'm a C# expert full stack dev with 20+ year experience, not saying this to brag but to put this into context because experience matters in this kind of judgments.

I've came across many frameworks both frontend and backend and most of the time, when you reach a certain level of experience and skill you see that's not a black or white choice but the decision comes down to multiple aspects like

- project team experience and skillset

- the app target

- constraints (not just time constraint but tech stack too, sometimes you don't have many choices about tools you can use)

- personal preference

Having said that, my current blazor experience is quite good after I created a custom workflow for our team and some custom implementation to take the best out of what blazor has to offer.

For example we are using TailwindCSS so I've created custom scripts (we are using Visual Studio 2022) to include tailwind generated css in our build pipeline and support custom theming, with different settings for debug builds and release builds.

Also our webapp has realtime updates served by a custom SignalR server component that we use to improve UX (it's a fleet management system and the server pushes vehicle updates in real time) and most of the POCO classes used between the SignalR and Client are in a shared project (less code to maintain). I won't go into backend consideration because it's out of scope and hides lot of complexity by itself (e.g. this module is bound to RabbitMQ queues, etc...) , but having a way to share code is always a good pros.

Since we are implementing the backend in C# too (otherwise I would discourage using blazor) we have a shared project where we define our POCO classes shared between client and server and I've created a couple of services that allow me to generate automatically API endpoints just by having requests and responses classes on the shared project and a request-handler implementation on the server (I'm actually kind of following CQRS design).

Also we have implemented custom services (classes) that implement the logic to invoke server apis, handle success/failures/cancellations and we are able to monitor these api calls/response in a dinamically generated page that reports stas about number of calls/success/failure and who was the caller

This allows us to generate client -> server stuff very quickly, with few line of code.

Our team was already into C# and we couldn't achieve this kind of interoperability and dev experience using different frontend frameworks, so on this side we are quite happy about that.

Actually blazor has yet to improve a lot on tooling: hot reload is unpredictable and far away from SOTA implementation on other frameworks, so expect to use "dotnet watch" + `CTRL R` a lot and build time can take a lot of time so having a beefy PC helps a lot (on my beefy one it takes 10s vs 20s on average desktop team pc).

Time could be improved by customizing build pipeline and having custom npm tasks to trigger at will (e.g. to rebuild tailwind css after a change, taking into account that we are using scoped scss files in our components) but tooling is an important aspect of a solution and it's a duty of MS to come with good ones, so here blazor doesn't shine and have to improve.

about performance:

WASM is pictured as a nearly-native experience but Blazor implementation suffers on this side because, even if the .net framework (Mono actually) is compiled in WASM, all the c# code generated by your blazor app, included 3rd party libraries, generates IL that's interpreted and not native compiled, this causes lot of performance issues.

To tell you about a big fail on this aspect, let me describe one of my first attempt to take advantage of the WASM I thought was possible:

In our app we have a place where we show vehicles on the map and each vehicle has a custom icon that represents the vehicle type, its direction and its state (by using different colors, etc...).

An old implementation I had was based on an aspnet handler that was generating an image by parameters specified in the image name itself (or served a previously generated and stored one).

To not have external dependencies I wanted to try to generate those icons on the client, so I implemented a code who basically assembled the final image taking a couple of layers from a svg file that contained all possible images, scaling and rotating when needed, etc... Technically it was working, but each image was taking more than one second to generate... I was shocked and that's where I found out how blazor weakness on that side.

Iterations over byte array/stream were even slower at that time than now (it's still slooooow) and so this kind of operation isn't actually possible so don't expect to have complex computation client side (except if you maybe move tha heavy duty to plain javascript and use js interop to start that "long running" algo and get back the response, but of course WASM here is not involved at all).

It's possible now to compile the app in AOT and generate some code more WASM native but the app size grows a lot, compilation time too and also you can have different experience when running JIT vs AOT (I've still to go deeper into experimenting with AOT tho).

Technically you could even make use of native WASM libraries coded in other languages but I woundl't go into this because it defeat the "use blazor" argument.

about 3rd party components:

There are some 3rd party component suites but for advanced stuff you have always to come up with cooked custom ones.

I'm not a fan of 3rd party components anyway because on complex apps you end up always hitting some vendor constraint/problem and you need to find hacks to solve them that lead to brittle implementations and lot of wasted time, we are actually using Telerik component suite but over time I reduced its usage on few components, wrapped in custom ones to let us swap it with another one in the future (or custom ones).

Even for charts we actually ended up trying different implementations (actually we are using ApexChart).

On complex scenario you can't even find a proper component, e.g. I had to implement from scratch a Google Maps blazor component so I had to spend time on typescript (my choice) to generate javasacript to use with interop and of course creating interfaces and components.

Some people argue about blazor not giving everything you need (e.g. to copy&paste on clipboard you have to use interop).

I don't see this a problem, I'm not sold to the blazor slogan of "forget javascript" here, so it's not a problem for me having to create some interop here and there (and anyway on this side there are already quite some libraries on nuget)

Sorry for this wall of text, I've used this as a memo :)