I'm building quite a massive Blazor app - probably one of the most ambitious projects in Blazor there is and I still love it. There is a lot of things that you need to keep in mind while you develop, a lot of things to do a little bit differently, and quite a few limitations around interacting with DOM but I think that the advantages of using modern C# are making the development experience simply unbeatable. I wish there was more mature tooling and working Hot Reload and debugging - this is absolutely the most annoying thing about Blazor but this is a small price to pay for the other benefits of the framework.
On a side note, I started my Career by watching tons of courses on PluralSight (~8 years ago) from you, Julie Lerman and Scott Allen (RIP). So thank you! 💙
One advantage of the new Blazor template is that you can run the .Client app using server side rendering by changing the rendering mode of the client MainLayout component. Essentially, the .Client app becomes a RCL. While developing you get faster initial loading, decent hot reloading and fast debugging.
Great video and really good to get the opinion of someone who uses a JS framework but also C#. As someone who does about 20% front end and 80% backend I just find Blazor so much easier. I have used Angular at work and just find it a steep learning curve. Yes I could get better at it but with Blazor I can build very complex applications using my current C# knowledge.
I get that. But I find learning a simpler JS framework to be more productive. I'm personally invested in Vue since it doesn't require the boilerplate of something like Angular. But, ultimately, if you're productive with Blazor, no reason to switch.
I fully agree with "use JS when it's appropriate, WAMS won't make you happy". BUT the latest Blazor can now (.net 8) be used just like the classic Razor - and then use normal JS like it's intended to be. I think that use case is very valid, because the component model of Blazor is much better than the plain Razor model. Makes programing much better encapsulated.
Good vid, thanks. Small suggestion for future iterations if i may....I would find this a lot easier to digest if it had direct comparison demos. Show a few key concepts side by side in something like vue to help people see the particular advantage or disadvantage you are discussing. More work I know, but I think it would help depolarize the conversation and allow people unfamiliar with one of the two options to understand your reasoning.
From my experience, blazor has a niche use and if you don't fall into it, it's a mess. However if you do, it's a blessing. If you create am internal app with 50 users, blazor server is just so nice - keeping everybody up do date is easy, no time wasted on creating endpoints, just do the thing. Another use case is internal PWA - app that gets installed once and then users just keep it opened. Initial download time and startup time become irrelevant. Libraries around using sqlite are just so magic compared to JS, you can create some really nice things. I would happily trade the time I spend tracing "undefined is not a function", or wondering if hot reload did work or do I have a typo, for couple restarts here and there. At least I knwk what I am waiting for. Would I use Blazor for an app that is used by the public on a phone connection? Probably not. In every other case, I find it really nice
@@swildermuth well, personally I find I spend less time restarting the app with Blazor (it's pretty fast to restart) than I waste trying to do things in JS. I am far from proficient with JS - just having LINQ in Blazor is enough argument for me. Apps that I create like that don't need flashy UI, so Tailwind not being as easy to use is not a problem - what counts is the app doing the thing it needs to do. For me, and many C# devs, it's much easier to achieve in C#. Because let's be honest, most of the work is filtering a list, and uploading a form, maybe store some cache in SQLIte for offline support (which you can do with EF Core in Blazor WA :)) If your app does more than that, probably use Vue. Out of all the JS frameworks this one is my favourite
I use it with the MudBlazor component library. Has a lot of ready to use powerful components and a lot of this nasty CSS crap is abstracted away. I would need to spend at least 2 years to get familiar with TS (would never use plain JS anymore) and some modern TS framework (Vue, React, ...). That is a big investment - and most likely the next project uses another JS framework. The binding in Blazor works great. With the new mixed render modes now supported performance got better. I agree that the tooling in VS and VS Code is B.A.D. Hot Reload does not work reliably at all. Overall IMHO any UI development is way too much effort and time consuming today. For building line of business applications something as productive as LightSwitch would be great - but MS killed it ... for some stupid reasons. The situation today is: LowCode is a death trap as way too often one get's stuck. The DIY approach (I do it all by myself) most projects use today has a terrible productivity and is way to error prone. There way too many competing frameworks. SW development must get much more mature and consolidated. Today we reinvent the wheel all day long.
I really wanted to make Blazor my new goto for web apps (I currently use Razor Pages with mostly page handlers and JS), but a lot of my apps are used in a factory environment on tablets where wifi is spotty in some areas so I didn't want to have to deal with issues where SignalR would lose its connection briefly and bring down the apps. So really, the reliance on SignalR is the show-stopper for me.
Blazor is a broad term and offers multiple strategies. Static SSR, interactive Server and WASM. You don't have to use SignalR, just use static or WASM (or mix it up). However, it is no different than websockets, long polling or SSE. If you need real time communication in a bad network environment, it will be the same issue for another. In a factory, use WASM or Static SSR if SignalR and its fallback mode with stateful reconnect doesn't work out.
Actually, if you go full on WebAsembly, you can pretty much create an app that can be "installed" on those tablets, use SqLite for local storage etc - it can be quite resilient.
Very nice review of Blazor , will you do a review of Htmx and Aspnet Core. Server side rendering vs spa, what you would use for different kind of solutions
Htmx + AlpineJS is a great way to bring some rich client-side UI experiences to an existing MVC app or even an app that will only have one very interactive page. Best of all worlds in my opinion. I architected an app that way about 2 years ago and it was awesome.
You can use HTMX like a SPA. It depends on how related your pages are across the domain. What's nice about that is that you can do hard splits on your pages depending on how closely related the pages are.
I prefer Blazor over React, it has the support of the Dotnet framework and it tells. Blazor is also a compiled language so expect issues with hot-reloading. I see a "possible" better JS framework in Blazor then i do in React, i havent tested the limitations.
The more i look into Blazor, the more i feel those who love it do so because they really are backend specialists trying to go full stack without learning the skills needed. The server version... wtf, new webforms. The Wasm feels like such an ugly fat hack. Just make your services API based and stateless, and use modern javascript like Vue for the client. Add someone to the team with competencies to teach the others. The client will be much faster, and you can have specialists in the team (no frontend specialist will touch Blazor) If you have not tried it, then i strongly recommend that you try to get into a position where you can work side by side with a highly skilled frontend developer and see the difference they can make when they truly understand the stack and think in reusable components.
Wow the courage to ask "Might I be Wrong?" very rare these days. Like you I have been allover the ever changing web stack. I like blazor because I build editors that expect users to spend a lot of time in the client. However I do not think that my dll are beiung recompiled to wasm. it all works, but maybe it could work better. Yes there some dark magic here
i really like the comparing to forms .. it very nice to make all the mvvm code in c# and only have the gui part as html with binding to the vm . we do internal apps where we move a away forms to web. also nice to be able to make serverside since we have no heavy traffic
Im a seasoned c# dev mostly delving in the backend/api stuff. My understanding of js and its frameworks are very weak (UI has always been my weak point), and Blazor seems to be a good fit for me until I get myself comfortable with js. That said, I tend to agree that Blazor is not there yet. But for now, it is a good stop gap solution for me until I get comfortable with js frameworks.
Might be me but what kind of turns me off on Blazor is the dependency on the sever. Might be nice for some stuff but i find my svelte stuff plenty fast for what i might need. And generllly i'll do the front end ui in svelte, and use messages to the pack end via some message. Then may server routines are C# for doing the heavy lifting for the app, them seems to me as the best mix... Could be wrong but i feel as i get the best of both worlds and good enough performance as a whole...
I long moved from C# to TypeScript and don't see myself coming back. I do my desktop apps using Node with Express. Blazer seems to be for those who can't move on. I'm reminded of people who did tooling so Basic programmers would write web servers and apps without learning all that asynchronous stuff. DIdn't go well.
Could not disagree more. I moved my web app from JS to TypeScript circa 2016 which was nice for some semblance of type-safety. When Blazor WASM did finally hit, I was happy to throw away TS in favor of actual C# -> WASM in the client. No transpiling, npm, version mismatches, or other clunky build steps necessary. TS is for those who can't/won't move on, but stick with it boomer! :)
I just looked into it a week or so ago... I'd say tooling is NOT good... Significantly worse experience than workflows with react or other dev. I've always been a skeptic, but I really don't get blazer server is for, and blazor wasm seems less than optimal. I also think razor as a templating language is not great in 2024
It's just an opinion. The rolling experience continues to be painful. And how wasm works has decidedly checked in the last few years. A lot less friction that earlier editions. Debugging is still annoying IMHO.
I don't understand this comment. Yes - I had Microsoft phones, loved them, and feel Microsoft and the phone carriers dropped the ball with them. I especially won't buy Microsoft hardware ever again. However, most Microsoft software frameworks (OLE, COM, .NET, WinForms, WPF, etc.) have been around a long time and are still supported today. Microsoft has cleverly intertwined the MVC, Web Pages, and Blazor frameworks together. WIll they drop all three? What's the replacement?
My favourite part is when you put your glasses down... it's like the suspense moment!
Haha it's like "It's about to get real..."
Mine is when he puts it on
I'm building quite a massive Blazor app - probably one of the most ambitious projects in Blazor there is and I still love it.
There is a lot of things that you need to keep in mind while you develop, a lot of things to do a little bit differently, and quite a few limitations around interacting with DOM but I think that the advantages of using modern C# are making the development experience simply unbeatable.
I wish there was more mature tooling and working Hot Reload and debugging - this is absolutely the most annoying thing about Blazor but this is a small price to pay for the other benefits of the framework.
Awesome and glad it's working out for you. Is there a code splitting option I'm missing? Crucial for large scale projects
@@swildermuthLazy Loading is there for Blazor
Yeah well hot reload doesn’t work that well with razor apps either.
On a side note, I started my Career by watching tons of courses on PluralSight (~8 years ago) from you, Julie Lerman and Scott Allen (RIP). So thank you! 💙
One advantage of the new Blazor template is that you can run the .Client app using server side rendering by changing the rendering mode of the client MainLayout component. Essentially, the .Client app becomes a RCL. While developing you get faster initial loading, decent hot reloading and fast debugging.
Essentially like next/nuxt
I love Blazor and it only going to get better.
Great video and really good to get the opinion of someone who uses a JS framework but also C#. As someone who does about 20% front end and 80% backend I just find Blazor so much easier. I have used Angular at work and just find it a steep learning curve. Yes I could get better at it but with Blazor I can build very complex applications using my current C# knowledge.
I get that. But I find learning a simpler JS framework to be more productive. I'm personally invested in Vue since it doesn't require the boilerplate of something like Angular. But, ultimately, if you're productive with Blazor, no reason to switch.
'I'm going to save it to a folder, not some magical place.' hahaha ~10:08
; )
I fully agree with "use JS when it's appropriate, WAMS won't make you happy".
BUT the latest Blazor can now (.net 8) be used just like the classic Razor - and then use normal JS like it's intended to be. I think that use case is very valid, because the component model of Blazor is much better than the plain Razor model.
Makes programing much better encapsulated.
Good vid, thanks. Small suggestion for future iterations if i may....I would find this a lot easier to digest if it had direct comparison demos. Show a few key concepts side by side in something like vue to help people see the particular advantage or disadvantage you are discussing. More work I know, but I think it would help depolarize the conversation and allow people unfamiliar with one of the two options to understand your reasoning.
Much appreciated, Sean. We really enjoy your objective takes on tech. Very validating.
Glad to hear it.
From my experience, blazor has a niche use and if you don't fall into it, it's a mess.
However if you do, it's a blessing. If you create am internal app with 50 users, blazor server is just so nice - keeping everybody up do date is easy, no time wasted on creating endpoints, just do the thing.
Another use case is internal PWA - app that gets installed once and then users just keep it opened. Initial download time and startup time become irrelevant. Libraries around using sqlite are just so magic compared to JS, you can create some really nice things.
I would happily trade the time I spend tracing "undefined is not a function", or wondering if hot reload did work or do I have a typo, for couple restarts here and there. At least I knwk what I am waiting for.
Would I use Blazor for an app that is used by the public on a phone connection? Probably not.
In every other case, I find it really nice
Why is a private PWA more beneficial vs. Vite + PWA?
@@swildermuth well, personally I find I spend less time restarting the app with Blazor (it's pretty fast to restart) than I waste trying to do things in JS.
I am far from proficient with JS - just having LINQ in Blazor is enough argument for me. Apps that I create like that don't need flashy UI, so Tailwind not being as easy to use is not a problem - what counts is the app doing the thing it needs to do.
For me, and many C# devs, it's much easier to achieve in C#. Because let's be honest, most of the work is filtering a list, and uploading a form, maybe store some cache in SQLIte for offline support (which you can do with EF Core in Blazor WA :))
If your app does more than that, probably use Vue. Out of all the JS frameworks this one is my favourite
I use it with the MudBlazor component library. Has a lot of ready to use powerful components and a lot of this nasty CSS crap is abstracted away. I would need to spend at least 2 years to get familiar with TS (would never use plain JS anymore) and some modern TS framework (Vue, React, ...). That is a big investment - and most likely the next project uses another JS framework. The binding in Blazor works great. With the new mixed render modes now supported performance got better. I agree that the tooling in VS and VS Code is B.A.D. Hot Reload does not work reliably at all. Overall IMHO any UI development is way too much effort and time consuming today. For building line of business applications something as productive as LightSwitch would be great - but MS killed it ... for some stupid reasons. The situation today is: LowCode is a death trap as way too often one get's stuck. The DIY approach (I do it all by myself) most projects use today has a terrible productivity and is way to error prone. There way too many competing frameworks. SW development must get much more mature and consolidated. Today we reinvent the wheel all day long.
As long as it's working for you, no need to change.
What do you think of the Xomega platform?
@@XomegaNet I don't have any exposure to that. What is it?
I really wanted to make Blazor my new goto for web apps (I currently use Razor Pages with mostly page handlers and JS), but a lot of my apps are used in a factory environment on tablets where wifi is spotty in some areas so I didn't want to have to deal with issues where SignalR would lose its connection briefly and bring down the apps. So really, the reliance on SignalR is the show-stopper for me.
That makes sense, it's not always the right fit.
Blazor is a broad term and offers multiple strategies. Static SSR, interactive Server and WASM. You don't have to use SignalR, just use static or WASM (or mix it up).
However, it is no different than websockets, long polling or SSE. If you need real time communication in a bad network environment, it will be the same issue for another. In a factory, use WASM or Static SSR if SignalR and its fallback mode with stateful reconnect doesn't work out.
Actually, if you go full on WebAsembly, you can pretty much create an app that can be "installed" on those tablets, use SqLite for local storage etc - it can be quite resilient.
For that issue, the solution in most modern frameworks is to use PWA, which you can actually use alongside Blazor.
Why not use Blazor WASM in that case?
Blazor's use case is probably geared towards the more highend webapps, than your run of the mill webpage.
Great tempo and teaching style. Content about wasm on the server side as a compile target would be great.
I'll add it to the list.
Very nice review of Blazor , will you do a review of Htmx and Aspnet Core. Server side rendering vs spa, what you would use for different kind of solutions
Htmx + AlpineJS is a great way to bring some rich client-side UI experiences to an existing MVC app or even an app that will only have one very interactive page. Best of all worlds in my opinion. I architected an app that way about 2 years ago and it was awesome.
I'll add it to the list
You can use HTMX like a SPA. It depends on how related your pages are across the domain. What's nice about that is that you can do hard splits on your pages depending on how closely related the pages are.
I prefer Blazor over React, it has the support of the Dotnet framework and it tells. Blazor is also a compiled language so expect issues with hot-reloading. I see a "possible" better JS framework in Blazor then i do in React, i havent tested the limitations.
I think Vue is awesome, but if it is working for you...no need to change.
The more i look into Blazor, the more i feel those who love it do so because they really are backend specialists trying to go full stack without learning the skills needed.
The server version... wtf, new webforms. The Wasm feels like such an ugly fat hack. Just make your services API based and stateless, and use modern javascript like Vue for the client. Add someone to the team with competencies to teach the others. The client will be much faster, and you can have specialists in the team (no frontend specialist will touch Blazor)
If you have not tried it, then i strongly recommend that you try to get into a position where you can work side by side with a highly skilled frontend developer and see the difference they can make when they truly understand the stack and think in reusable components.
Wow the courage to ask "Might I be Wrong?" very rare these days. Like you I have been allover the ever changing web stack. I like blazor because I build editors that expect users to spend a lot of time in the client. However I do not think that my dll are beiung recompiled to wasm. it all works, but maybe it could work better. Yes there some dark magic here
I appreciate it.
i really like the comparing to forms .. it very nice to make all the mvvm code in c# and only have the gui part as html with binding to the vm . we do internal apps where we move a away forms to web. also nice to be able to make serverside since we have no heavy traffic
Im a seasoned c# dev mostly delving in the backend/api stuff. My understanding of js and its frameworks are very weak (UI has always been my weak point), and Blazor seems to be a good fit for me until I get myself comfortable with js. That said, I tend to agree that Blazor is not there yet. But for now, it is a good stop gap solution for me until I get comfortable with js frameworks.
Not a bad strategy, but I am not sure that Blazor will help you get up to speed with js/ts.
Just FYI Shawn, typo in Title. Very cool video though, thanks man.
Oops, you caught me! Thanks for the heads up.
Might be me but what kind of turns me off on Blazor is the dependency on the sever. Might be nice for some stuff but i find my svelte stuff plenty fast for what i might need. And generllly i'll do the front end ui in svelte, and use messages to the pack end via some message. Then may server routines are C# for doing the heavy lifting for the app, them seems to me as the best mix... Could be wrong but i feel as i get the best of both worlds and good enough performance as a whole...
Blazor WASM has no requirements on the server.
I long moved from C# to TypeScript and don't see myself coming back. I do my desktop apps using Node with Express.
Blazer seems to be for those who can't move on. I'm reminded of people who did tooling so Basic programmers would write web servers and apps without learning all that asynchronous stuff. DIdn't go well.
I am not sure that's fair to those developers, but for C# only shops (think the new version of WebForms) - it's a viable solution IMHO
Could not disagree more. I moved my web app from JS to TypeScript circa 2016 which was nice for some semblance of type-safety. When Blazor WASM did finally hit, I was happy to throw away TS in favor of actual C# -> WASM in the client. No transpiling, npm, version mismatches, or other clunky build steps necessary. TS is for those who can't/won't move on, but stick with it boomer! :)
I just looked into it a week or so ago... I'd say tooling is NOT good... Significantly worse experience than workflows with react or other dev.
I've always been a skeptic, but I really don't get blazer server is for, and blazor wasm seems less than optimal.
I also think razor as a templating language is not great in 2024
Development tools are a religion...
wasm released 1 year after server side, not hard to find unless you just want to suggest it is not a solid option to suit your pre decided opinion!
It's just an opinion. The rolling experience continues to be painful. And how wasm works has decidedly checked in the last few years. A lot less friction that earlier editions. Debugging is still annoying IMHO.
Hi shawn I may be wrong but I think blazor will have the same fate as windows phone for exactly the same reasons that windows phone failed
I agree. I think it'll be around for another couple of years and then fade away... unless they can make it much better than it is now.
WASM isn't at the stage necessary for something like Blazor to kick off outside of corporate environments.
Think web forms more than windows phone, I expect. Loyal following, long lived.
I don't understand this comment.
Yes - I had Microsoft phones, loved them, and feel Microsoft and the phone carriers dropped the ball with them. I especially won't buy Microsoft hardware ever again.
However, most Microsoft software frameworks (OLE, COM, .NET, WinForms, WPF, etc.) have been around a long time and are still supported today.
Microsoft has cleverly intertwined the MVC, Web Pages, and Blazor frameworks together. WIll they drop all three? What's the replacement?