Running Blazor in production, lessons learned - Jimmy Engström - NDC London 2023

Your experience with blazor seems not to be related to blazor, but rather with the shift on going to singel page applications.

Why Blazor is great for me: I used WebForms since it was available (and i still like it, but it's legacy now). We still have large WebForms Apps. Blazor mixes in very easy. The transition will take many years - but it's very smooth. Existing stuff is redone in Blazor when they needed to be touched anyway, new stuff is done in Blazor - it just works :-)
Now I am in a management position. Blazor was an easy choice.

Blazor is the future

Blazor is dead in 3 years. It is simply a mess, weird magic tags that produce stupid HTML.
Just the idea that everything requires a constant connection to the server, imagine the resource cost.

How does Blazor server handle things like drag and drop? Does it download some JS that it runs in the browser? Or do people still use some JS when using Blazor server pages? Seems like overkill to go back to the server for DOM manipulation when a little JS will do the job. I currently use vanilla JS, Razor, lots of AJAX to make the pages feel "live". Thinking of switching...but was surprised when he said mixing and matching razor and blazor wasn't a good idea b/c connections get dropped.

Great presentation. Thanks a lot Jimmy. I bought your book.it's amazing. As a dot bet senior developer, Blazor was my dream, I will never use any other frameworks for my new projects. Blazor is the best framework i have ever worked on.

I was interested on Blazor as an escape of the JS nightmares, but "unfortunately" (for good or bad), Blazor is going towards the same approaches. Honestly, the more you think, the more server side rendering makes sense for a good deal of web apps. That is why things like HTMX with Razor Pages look like a better option that I am more interesting on trying these days

Thank you for nice talk. However, I don't think that WASM footprint was compared properly. In my opinion, Blazor WASM example given is really abstract one. You did compare it with Facebook saying that Blazor is just 1MB vs 16MB on social network's side. Facebook is pretty heavy application by itself, so no doubts it has high payload. In such case, would be nice to see comparison with something similar created in Blazor WASM(in terms of complexity) and not just by comparing some abstract application.

After 30 minutes of just listening to how Blazor works and nothing about any lessons learned in production I stopper watching.

Im sure blazor has its uses, but ill pass for the moment. Actually working with javascript and other frontend tech has given me huge insights into programming. Skipping that would have been detrimental for me.

Unfortunately, like with other autogen frontend stuff, i feel like this just puts a huge wizard of oz curtain in front of what you are trying to accomplish ( like linq to sql ) and leaves room for bad code and ineffiency.

Always found front end tools a mess. Weird errors, difficult to debug. Nothing is obvious, too much magic.
Blazor is front end development for back end developers.

Be careful with just throwing everything into components. There is a small overhead for each component. So if you have a 1000 component on a site, it will slow it down. I've been there myself.

I've used blazor a couple of places in production :)

I think Blazor Server is not production ready. A very simple reason: If you deploy an application on Docker (Kubernetes or Swarm or whatever) all the users got disconnected. For this simple detail it is not ready.
There is no standard solution for this, and it is a huge problem.

"Paul-Sebastian Manole" Yes. Dev experience maybe is not so good but I think the future on WASM and from all languages biggest abilities to shoot on Blazor

What I can't stand is the slow iterative feedback. Blazor feels like developing for Webforms compared to Vite + any JS frontend lib.

Blazor is \o/ - such productivity