A production build of the hello world example for Blazor takes 5 seconds to launch. Half-baked, rickety sad excuse of a technology built in a crunch and never rebuilt correctly.

The simple yet surprising reason why it's so fucking slow is that Microsoft couldn't figure out a way to compile C# to webassembly while also beating others to market so they compiled the runtime to webassembly instead. The Fucking IL interpreter.

can you share some details about your test setup? because i just tried to reproduce it and couldn't.

on the contrary: i had two seconds from "started compilation" to "fully running app in freshly opened browser" - of which compilation took at least 1.5 seconds.

tested on a completely virgin blazor webapp on dotnet 8

@tosensei > "of which compilation took at least 1.5 seconds"

That's been our experience, so far. We've fully adopted Blazor WASM for our internal (web) applications (first Angular, then React). No regrets on performance (yet).

Hardest part about Blazor (or probably any web based framework) has been security.

wait, do neither of you get a several seconds long loading screen before your app starts?

Maybe I had something set up wrong

@PaperTrail hardest part is convincing the POs to use it in a new project, since the team hasn't got any big-application experience with it yet.

and what i'm most curious to experiment with is app development. basically just chuck it into a MAUI webview, add some bindings, and bob's your uncle.

@lorentz no, no loading screen. that's why i asked about your test setup.

especially what version you're using, blazor has come a loooong way, and has become very versatile. server-side-blazor for example uses no WASM at all - the code runs in the backend and the frontend is just a "thin client" handling user input and executing DOM manipulation.

and the new hybrid approach in dotnet 8 is pure nerd porn...

@tosensei > "just chuck it into a MAUI webview, add some bindings"

That's kind of what my boss wants to do with migrating our mobile Xamarin apps. Use the MAUI bits to interact with the hardware events and Blazor to do the rest. Again, the security is biting us in the arse.

@tosensei @PaperTrail I generate a new project with `dotnet new blazorwasm`, run it with `dotnet run --configuration Release`, then open it in a browser, and after the page opens it spends about two seconds on a loading screen before it shows me the app.

It's 2 seconds now because I apparently didn't set production mode correctly earlier, that's also why I specified the exact commands here, in case you can point out an option I'm not using.

2 seconds would ordinarily not be bad, but this particular app has to be interactive quickly, and I know the delay isn't inherent to webassembly because Yew manages just fine.

@PaperTrail can't really see how any of this is less secure than doing the basically same thing with ionic or anything.

@lorentz i believe i can kinda reproduce that behavior. but for me, it's still clearly below 1s startup time.

if you still need faster startup - might server side or hybrid be a solution?

@tosensei Not really, and it'll likely have to stay well below 1s even when the client is under heavy load, so yew it is, unless I stumble into an optimization that solves all my problems.

@lorentz you can look into trimming the binaries when publishing the app. can shave off quite a bit of unused code - but i'm not an expert on that; never had such tight startup constraints.

@tosensei > "can't really see how any of this is less secure than doing the basically same thing with ionic or anything"

It's not. We've containerized our Blazor apps and getting the hosting environment (Nomad) to 'play nice' with the network has been an uphill battle.

We have the same issue with our .net services and would have the same security issues even if the app was written in Angular, React, etc.

Security is hard.

@lorentz > "it'll likely have to stay well below 1s"

I assume your performance tests were against/on a 'real' web server and not running the app in Visual Studio on your local machine? Its still a good starting point, but don't dismiss Blazor.

That said, use the right tool for the job. If users are impacted by ~1 second response time, then Blazor might not be the right tool. In fact, if users are complaining about ~1 second response time *in a web browser*...then we must work for the same users :)