What Web Framework Should I Use For My C# Project?
2024 ж. 3 Қаң.
10 152 Рет қаралды
What is the best choice for a web framework for my C# project? Should I stick with MVC and Angular? Should I just use an API and then use React for the front-end? Is Blazor a viable choice now? What about Vue? These are the questions we will answer in today's episode of Dev Questions.
Website: www.iamtimcorey.com/
Ask Your Question: suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: signup.iamtimcorey.com/
Just what I needed. Some good Blazor reinforcement. I have a website/app idea that I am working on. I started as a c# console app to create the base algorithm of what the project will be doing, and it is allowing me to port that code directly over. I was hesitant to know if it was the right path, but based on this video, I am on the right path.
I am glad it was helpful.
Been using Blazor WASM in production for about a year now, best choice ever.
Thanks for sharing!
Thank you Tim 💌
You are welcome.
If you like C#, and are comfortable with .NET, use Blazor, Blazor or Blazor.
Which flavour? WASM? SSR? Static pages? How do you secure it? Cookie authentication doesn’t work over websockets, storing token information in protected storage is a massive security hole. Unless you really know what you are doing (or don’t need auth) then don’t add blazor to your site.
@benjamininkorea7016 - Yep, pretty much.
@OldSpudHead - which flavor? It is all one project. You get to choose how each component gets rendered. You don't need to choose one technology. As for your thoughts on authentication, I would recommend you go back and review them. Blazor can absolutely be secured with authentication, even over WebSockets. As for storing token information in protected storage, did you miss that word next to storage? Protected. As in it is protected. Yes, there have been ill-informed articles that have spouted that cookie authentication is the only way to protect your token (by the way, Blazor uses cookie authentication by default for the entire project). However, the risk of using session storage is minimal.
@@IAmTimCorey I got given a site to review. I copied the encrypted local storage to another machine and was in the site with full privileges. The documentation is shockingly lacking and people are making poor choices when it comes to securing their site.
@@MiningForPies lol define "massive security hole."
I’m looking forward to buying your blazor course. Hopefully next month after another project completes.
Great!
at my latest job as techlead/architect 2 years ago i went for mvc + vue for the first architecture because they only had very very bad legacy applications with .net and angular with tons of custom boilerplate and even hand modified node modules, which meant they couldnt even do npm install.. and i only had a few days to create something that just worked.. so mvc it was, the old reliable + vue for the component libraries and style. then soon after i created architectures for API + vue/react/angular SPA and always just gave the teams the choice to pick whatever they wanted according to their needs and competence. i still support the other architectures because you never know what project you might have to develop, and i like to always have some code ready (routing, component libraries, auth, docker support..).. blazor is surely one of the techs i want to explore, who knows.. at the moment im mostly thinking about mobile and distributed databases, which are real needs of my company
Thanks for sharing!
Hi Tim, great video! In a blazor server app you would create controllers inside that project or you would create another web api project so that can be used from other applications too? Thanks in advance.
I find that APIs are often useful, but they aren't always worth the added complexity. I have an application in production right now that does not use an API. That was the right call for that application. It all depends on the situation.
@@IAmTimCorey Thank you for response. But my question was different, if I want to call the api even from different applications, should I do a different project with the api? Because maybe calling a blazor server app that contains controllers too could delay the response or I am wrong?
I would recommend against mixing the API UI with the Blazor UI. They should be separate projects.
Perfect, thank you.
MVC + HTMX (hypermedia app) is the best overall if your main client is a web pages (best latency, dev experience and cost)
I'm glad that works for you. I definitely don't see it that way, but that's the great thing with having options. You get to choose what works best for you.
Hello Tim. If a Blazor app is on an on-premise web farm, are sticky sessions required due to using web sockets? Is there a proven, performant way to not use sticky sessions with Blazor that you have/would use? Using sticky sessions has a bad rep in some circles. Personally, I think it is okay to use them but want to know if there are options. I enjoy your talks while walking my dog, thanks.
With Blazor Web Apps in .NET 8, I don't believe that sticky sessions are necessary. The SignalR connection is not trying to live for the entire length of the session. It is only a short-lived call. If you use Server components, the connection will live as long as that component is actively on the page. If you use Auto components, the connection will only last as long as it takes to download the WebAssembly version of the component in the background.
@IAmTimCorey, I have a question! I've been following your videos for a long time, and recently, I've been considering learning artificial intelligence. However, I've spent over 10 years working with .NET, and I'm comfortable with C# and Azure. Since Blazor has good exposure, and many enterprise-level applications still use it, should I stick with Blazor or explore python for artificial intelligence or machine learning or data science? Also, what are your thoughts on artificial intelligence in .NET, its scope, and where .NET might integrate artificial intelligence? I'm quite confused about what to focus on and specialize in for 2024 - 2025. I understand it's a complex question, but I'd greatly appreciate your insights
So everyone is using AI in everything. So in one way, AI is really hot. However, that's not really "working with AI". That's just consuming an AI's output and wiring it up. Even setting up your own AI in Azure is just a matter of using a few menus. If you truly want to get into AI development, you could use C# but Python is the leading language for the field. However, the language is just a TINY part of what you need to know. You really need an advanced understanding of high-level math and statistics. Data science is more about the math than it is about the programming. Personally, I would lean into Blazor, since it gives you an easier path to expanding your skills in a way that is more marketable. You can always experiment with AI consumption, which will add even more skills that will be valuable without needing to spend lots of time adding those new skills.
@@IAmTimCorey Thank you so much for your precious inputs ☺
Hi Tim - this was really helpful! Only question that I have is the server load with Blazor Server with the connection always being on and some comments I have seen around the ability to easily scale with Blazor Server compared with Razor MVC. Have you head any horror stories of massive Azure bills popping up when moving from Razor MVC to Blazor Server or is this 'fake news'? Appreciate you probably want a hybrid of Blazor Server and Blazor Webassembly but still curious if you have heard of anyone being surprised by the compute cost of a Blazor Server built app?
No, it won't cause massive Azure bills. The SignalR connection always being connected when a user is on the site does mean a bit more load for the servers, but one reasonably-sized server can handle 10,000+ connections at once (that is 10,000 concurrent users, not just 10,000 per day). That's not going to be a problem in almost any scenario. And if it is a problem, you use the Azure SignalR Service to help you scale beyond that. It will be more expensive to do so, but at that point, more expense should be expected.
after using both blazor and react, I definitely prefer react or js for the frontend
Good to know.
Great vid! I’d recommend dropping the 30 second intro since people will just skip past it and it will lower view duration
What if someone is new to the series? I guess the intro would make sense then
I generally recommend to not recommend to other people on what they should with their own content.
@@TurntableTV If someone prefers not to grow, ignoring advice is a good idea. Just giving constructive criticism ;)
We are working to improve the intro this year. It just takes time to complete.
Do you still recommend Blazor if the website will be load balanced? I thought Blazor requires SignalR and that doesn't play well with load balancers...
I would recommend Blazor WebAssembly in that case (and almost every case). The app only downloads once to the browser and then calls web API's to get/save data. Those could probably be load balanced okay, though you might have to fiddle if you require authentication. Blazor server with SignalR is a big fail if your web application is expected to run on mobile. Users need to refresh the web page every time they open their mobile browser because the SignalR connection is always dropped.
I think that perspective is probably based off of outdated information. If you used Blazor Server, which relies on a constant WebSocket connection for the life of the session, you would need to use sticky sessions on your load balancer (a pretty common requirement for a number of reasons). That's it. Also, you can offload your SignalR connections to Azure and load-balance them as well so there isn't really a problem there either. However, all of that is really immaterial when it comes to the new Blazor Web Apps in .NET 8. With them, the typical scenario would be to set up your base application to default to SSR pages (server-side rendered). That means they are loading with the least overhead and the fastest speed. Then, your individual components can use SignalR, but only when they are on the page, and only if you don't use Auto. The preference is to use Auto, which means the component will get rendered on the server (SSR), then wired up with SignalR, then download the component files in the background, then load the WebAssembly version (from then on out). That means that SignalR is only used for a very short burst of time per component. You wouldn't even need to use sticky sessions. It would work great with a load balancer.
@IAmTimCorey, please, where can I buy this T-shirt?
Coming soon.
My main question is, when should you use Blazor Server and when should you use Blazor WASM?
What's your opinion on using HTMX with Razor pages or MVC for client-side rendering?
I didn't know what HTMX is. Now i have learned about it. It reminds me the knockoutjs and jquery-ajax-unobtrusive i think it is called... Very old days of dotnet and mvc. I don't like this approach to be honest.
So far, I'm not thinking that HTMX is the way to go for C#-based web development. I'll be keeping my eye on it, though.
@@IAmTimCorey In what way does C# hinder the functionality of HTMX? I'm a little bit baffled and disappointed by this reaction, as HTMX has no ties with whatever language you use for your web framework. I'd much prefer you tell your viewers or students that you have little to no experience with HTMX than just discourage the usage of a library outright. I always tell my students that if they think a library is helpful to them, they should try it out and do some research for themselves.
@timohermans - It feels like you are putting words in my mouth. I never said C# hinders the functionality of HTMX. What I said was that "I'm not thinking that HTMX is the way to go for C#-based web development". The reason I think that is because I don't see a compelling case for why adding another technology to an existing C# web application adds enough value over what we already have to justify the addition of another dependency. What can you do with HTMX that you cannot do with a Blazor Web App that you feel justifies adding that dependency? I'm not opposed to people trying things out, nor am I discouraging it. However, I was asked my opinion on using it in a C# environment. I gave my opinion.
@@timohermans today i heard about this thing. yet another trend? anyway i said my opinion. it looks very similar to what we had years ago (knockoutjs, jquery-ajax-unobtrusive
I love blazor and feel it could be very useful for enterprise applications. However, my biggest concern is there seems to be no way to push updates without disconnecting the user.
If you are only using Blazor Server, yes, that's true. However, if you are using Auto to switch to Blazor WebAssembly, that won't really be a problem.
@@IAmTimCorey I get that and auto is the way to go... But what happens when they are on a server only page? End goal is to have seamless updates to the user correct?
There's is no best. All depends on need.
Yep, that's why I never say "only use this".
I'll say it: only use Blazor
Is Blazor suitable for API project?
No, use API for an API.
C# + HTMX. that's what I'm using and I'm getting things done much more quickly than ever before. We should collectively be on a mission to try to go back to when things worked on the frontend without this shitty pletora of frameworks we have nowadays. No blazor, no razor no JS frameworks. Plain C# + HTMX.
Why doesn't Blazor SSR work for you then? You are adding a new technology to do what your existing tools can do without switching languages. Plus, you can add the client-side interactivity you want on a per-component basis if you want to go further instead of needing to change your entire infrastructure with C#+HTMX. By the way, you use what is best for you. I'm not trying to convince you otherwise. I'm just curious about your thought process.
For the majority of cases in the web app development the adoption of a new framework isn't essential. HTMX, combined with a basic understanding of HTML and a backend language like C# + minimal API, suffices for these scenarios. This approach capitalizes on the strengths of backend development and also allows for more flexibility in hiring, as it can accommodate developers with expertise in various backend languages, like python, Java, Go, Kotlin, C++ etc.. Of course I'm a C# developer therefore I advocate for C# as a backend language :). But I also advocate for a more streamlined and versatile development approach that relies on fundamental web development skills and versatile backend capabilities. Don't get me wrong, I appreciate the principles underlying Blazor, but I don't believe it would justify a transition for the majority of people. For me, adopting these technologies for the sole purpose of adding basic interactivity to a web application doesn't seem to be a worthwhile trade-off.
I am exploring the combo Blazor SSR (no interactivity at all) + minimal api (serving SSR Blazor components) + HTMX + Alpine (specific client-side behaviors) As you pointed, things are done much more quickly and really reduce complexity of an application. On top of it you can take full advantage of the native web platform. I found out the interactive part of blazor (specially WASM) being not only expensive, but also times more complex (basically you are putting a bunch of adapters to bridge WASM with DOM and other native APIs) and behind of JS/TS alternatives for majority of apps. I would not be investing in blazor "interactive" anymore
So many projects use about 7 frameworks when they probably only need a web api and the rest could be built in vanilla js/html/css in far less time.
I generally agree, although once you involve an API, you are probably going to benefit from Blazor over trying to use vanilla JavaScript.
In my experience, it's not either/or. I can still use all my old code-- js, html, css, in a Blazor project. If someone on my team wants to pump out pages using only the legacy trinity, there's literally no obstacle to doing that. For example, I still use some .js code that's more than 10 years old for converting mic input to .mp3 format on the client side. Literally just put the .js file in my static assets folder and drop a reference to it, and it works out of the box. But the power of C# for both back and front end cannot be denied.
this episode could have been a podcast. Maybe a few fade-ins or something in the next video. There is no benefit in "watching" the video
It is a podcast. This is the Dev Questions podcast. Some people like to watch it, but it is also on all major podcast platforms.
Blazer + HTMX = endgame
Why do you need HTMX if you have Blazor?
@@IAmTimCorey if you don't want a 24/7 socket connection to update stuff. Use just SSR blazor and HTMX for updates without a page flip.
Angular. Sorry ))
For a C# project? That is a LOT of extra overhead in order to get almost exactly the same features as Blazor (actually less, since Angular only does client-side applications).
I recall when microsoft evangelists used to push silverlight as much as they push blazor now
I'm curious - do you expect no one to ever be excited about any Microsoft technology from then on? Because you could say that about anything. If you are trying to say that Silverlight and Blazor are in any way similar, that would be very incorrect. One was a closed-source, proprietary technology that was dependent on browser plug-ins to operate and the other is an open-source technology built upon web standards that requires no additional support to operate. See the difference? I did a video on the Silverlight myth here: kzhead.info/sun/qKxsqpSimGmnmX0/bejne.htmlsi=nOvNyy8Ro0lM-GZS
If you go to a farm and ask a farmer: "Do you consume your own produce?" And if he or she answers no, would you buy produce from them? Guess where I am going with this.
I hear that a lot, but it is a rather poor take on software development. First, as of the time of this comment, .NET 8 and the new Blazor changes have been out for almost exactly 2 months. 2 months. How many enterprise applications do you see built in 2 months that are capable of planet-scale capacities? Second, changing the technology for an application that already exists is almost never done and when it is done, it is a MAJOR undertaking. That's why they don't rewrite Visual Studio even though it badly needs it. And this isn't a Microsoft-only thing. Go into most businesses that have been around for a while and you will find that they are still using the .NET Framework even though just upgrading to .NET would make their application run better. The reason is because upgrades are really expensive and they aren't easy to justify to the people paying the bills. By the way, there are LOTS of farmers that don't directly consume their own produce. Wheat farmers don't usually hold back bags of wheat and grind it themselves. Sorghum farmers don't typically hold back some for their usage. In fact, most large farmers end up just selling their crops rather than living directly off of what they produce (I live in big farm country).
@@IAmTimCorey man of many talents. Farming included ;) BTW. Your videos helped me in many occasions. Thank you so much!
But i live in a third world country i barely see blazor on job post.
Couple things here. First, we are talking about for new development. We aren't talking about what to choose for existing web applications because that choice has already been made. Blazor being the best choice for most C# front-end web projects is only because of the .NET 8 update, which has been out for only two months. Before that, Blazor Server/WebAssembly was a good choice if you wanted a SPA and didn't mind certain drawbacks. Now, it is much more broadly applicable. That means that it will be more useful for companies moving forward. Second, even before .NET 8, Blazor was a very fast-growing web UI in the C# community. I believe on the Stack Overflow survey, 1/3 of all C# web developers used Blazor. That's a LOT. So some of the web jobs you see for ASP.NET Core will include Blazor even if they don't specifically list it on the job description. Third, every technology is going to be more or less represented in a specific area. You will have to figure out what works well in your area. The only thing I would caution is to not just chase the most popular item, since that will include the biggest pool of potential employees and thus the most competition for a role and the least incentive for the companies to pay competitive wages.
Something different about you... new haircut? No that can't be it. Hmmm.
Probably just the lighting. Couldn't be anything else.
@@IAmTimCoreyLol, definitely first time I'm noticing the shirt. Think I'll wait for the signature Sue Storm edition. Should probably have a for loop that outputs "Practice" x3 too.
Not sure I can legally use the Sue Storm name in a paid product.
The problem is in Blazor's performance.
In .NET 8? Or are you thinking about previous versions of Blazor?
prio 1 is whatever your company is using prio 2 is just react thats it. it does not sound as smart, its not as easy to argue, but its 100% true. you know it, i know it, everybody knows it.
Couple of problems with this logic. First, your company had to make a choice in the beginning. This video is about making that choice. Yes, once you are locked in, you are locked in. However, applications don't just appear. Someone had to make a choice in the beginning. As for your second priority of "just React", that's a REALLY bad take. If you are a C# shop, and you have a bunch of C# code written for your applications and now you want to add a web front-end, being locked into "React is the only way" like a zombie is almost certainly the wrong choice. How many technologies do you need to add in order to add React? Keeping things REALLY simple, you need to add npm, ESLint (or similar), JavaScript (that's a whole new language to learn), React (that's a whole new framework to learn), VS Code (because you were probably using Visual Studio before), a bunch of libraries for React, and a bunch of additional JavaScript libraries. All of that overhead for CRUD on the web. Compare that to adding Blazor. You need to add Blazor. That's it. You are already using NuGet and Visual Studio. You reuse your skills in C#. You reuse your existing libraries. Don't make bad decisions just because you think the result is popular. You end up spending a lot of time and money on something that could have been done simpler and more effectively.
@@IAmTimCoreyThis might be the best comment I've ever seen you post. 100% agreement.