restarting the application to see css or html change is a nightmare .. hot reloading is so slow and keeps breaking ... it was a very bad experience for me. I'm talking about developing a WASM . I think non of these issues exists in the blazor server, but it is not what we need !
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.
I’m picking up web dev after about 15 years of not coding. Blazor is what I’ve been learning and it’s awesome. I’m avoiding JavaScript for time being as I have stuff I need to get done.
All in on Blazor WASM for several years now and never looked back. After spending years toiling with the latest JavaScript toolset, Angular, Vue, and the ever changing client side landscape our teams are far more productive leveraging the .Net ecosystem on both client and server. Tailwind + Blazor component model + the stability of .Net library ecosystem is hard to beat
@mq9032 We’ve been use prerendering which loads page and static content quickly and provides SEO. Net 8 has also introduced SSR, Server-Side Rendering, and transitions to WASM. Both are viable options.
I wish I’d discovered Blazor earlier! Moving from JavaScript through Node, Express, TypeScript, React, and React SSR felt like a constant juggle of libraries, packages, and compatibility issues. Each JS project needed a mountain of dependencies, which we could only hope would work well together across versions. And then there’s always that one person at work pushing to experiment with Bun, adding to the chaos. Remember when we used to think of React as a slow and clunky choice? Now, it’s evolved massively, much like Blazor.
Wow- I remember watching you on Pluralsight many YEARS ago and loved your videos. Had no idea you had a YT channel! Your Pluralsight reputation is enough to earn a sub from me...
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! 💙
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.
Excellent analysis Shawn. A common thread I find is that the "older" C# devs really like it because they can do alot without touching JS/TS. One thing I found extremely helpful in larger enterprise grade app dev efforts is the ability to share class libraries. Can't do that with Angular or React. It's just a time saver and really helpful at buildtime.
Easier to share libs in C# for sure. Though Angular and React (and Vue) can share libraries via NPM packages (or there are ways to do this in Next and Nuxt). But I get your point.
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 think Blazor is the way to go for all. The question remains is which to use, SSR or CSR or Auto, this what will differ from project to another. I think as well there is no problem at all with bridging between JavaScript and the assembly code. It cannot be easier. I used it heavily in both Interactive Server Mode and WASM. I also got a quite enough experience with Angular and React. I can confidently say that everyone should consider Blazor, even those who are living in JavaScript/TypeScript world.
"I think Blazor is the way to go for all." - All never works everywhere. Different solutions for different problems. When I hear this, I feel like it's a press release. There are pros and cons to every ecosystem, including Blazor/MSFT and the entire JS/TS ecosystem. There is no one way.
Didn't the publish folder contain both the compressed and uncompressed files? Then the size is much smaller than 20 MB. I see that you create a separate component class from which the component/view inherits from. You could achieve the same with code-behind using a partial class. There is a refactoring that extracts @code block to a code-behind file. And if you want to test the components, like interactions and what is rendered, you can use a library like bUnit (together with favorite unit testing framework) that essentially mocks the view.
that's great and all, but better than what? better than what blazor was before? seems most anything is like that, things improve over time. Real question is how competitive is it with other things, is it "better" than those other things.
Totally Fully agree, have developed MFC, Win Forms, WPF and meanwhile Web only for decades and see Blazor in the niche you see it. Thx for digging deeper and verifying that.
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.
Curious. Given the two approaches, Blazor vis Java/Type Script and Rest. What is (ballpark) the total developer time spent on each approach. Is one faster then the other. Thoughts?
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.
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.
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.
Use Blazor with MudBlazor, Bolero and use the Elm(ish) pattern. Once you have understood the functional approach, you get results quickly. I made an in-house web app running with Blazor Server (WASM is out of question, our company PCs all run Sophos which analyses all binaries once they come in which slows the application to a crawl) and the customer wanted one component of that application as a client-side app, exchanging the server-based functions with some simple file I/O. I managed to slap that component into a separate Blazor WASM application and use Electron to make the local application for the customer.
If that works for you, YEAH! This video is about Blazor WASM. I don't care for the non-standard communication between server/client but I understand why people like it.
I'm by no means a Blazor fanboy (I flip flop between Blazor and Svelte for my own projects) but re: 12:40 I'm interested to know why you consider learning Blazor to almost be lesser of a task/outcome compared to Javascript in the realm of web frontends? If Blazor is able to do everything you need, why is javascript even necessary? I've found recently that I'm not actually learning JS anymore, I'm learning React/Svelte/Angular and they just happen to use javascript. Ultimately the user doesn't care if the experience is good enough.
Visual Studio support is still not so great due to incomplete hot reload feature, but if you can digest few weak spots it can do nice job. It is perfect for building internal tools (thinking about enterprise companies) or smaller businesses. I've been into programming since late 90s and doing mostly system engineering, HATED doing any web coding. But with Blazor it's awesome. Coming from mostly low level C programming, I am one of those who believe web should fully embrace web assembly. This is why I see Blazor as a step in the right direction. It's far from perfect, but for simple and quick stuff it's good enough. And I underline this "good enough". I just hope MS keeps it alive longer than some previous frameworks :)
Yeah you can blame the visual studio code team for that, we had a decent hot reload for xamarin back in the day that the VS team got and when they implemented it the vscode team went to the upper managers and complained about studio stealing their functionality, so it got removed, then when the outcry was too loud they brought it back, but it never worked since then and half the functionality was missing, it still doesn't work great even for xaml hot reload.
I have been using blazor (hybrid & server mostly) for cross platform dev. I don't see an issue with using blazor server for your secure componentry then use hybrid for the other components and maybe a local js framework for any dynamic dom stuff, it actually works pretty well as then you can get rid of any heavyweight JS framework crap, have it use a component from the server until it is loaded locally and the user doesn't even realise it is now running locally. TBH I like that I can inject a service directly into a component, and I don't have to have JS repeating the definition of my architecture as well as a backend definition in C# keeps things simpler to update in the future as you just update the one model, the one component etc. Please note: I have been doing web dev for large and small scale operations for years and this is the first framework other than htmx that I actually think will be useful on a longer term basis
Your points are all valid, and building an application using WASM is really new compared to the other frameworks. However, my rethink is: Why are we building web applications from the client side? Historically, there is a reason for this: server-side resources were limited and time-consuming to scale. Hence, we could scale quickly by pushing the application to the client and minimizing the server-side resources used. Enter cloud resources and server-side dynamic scaling. With the server-side having resources, do we need the complexity and all the work to get the application to live in a browser as the application development platform? For horizontal applications (e.g. social media), but for enterprise applications that are all converted to web applications to solve a distribution and maintenance problem? IMO, these applications are much more stable, cost-effective, and, most importantly, reliable (all web applications have an unmanaged dependency on the browser and often the JavaScript libraries). I'm critical that we consider all the requirements and the changing tech for each development project. Yet, even as developers, where change is always constant, we like to continue doing it the same way.
Interactibility. Even Blazor Server is doing things client-side. (e.g. making the SignalR calls). If you think back to the client-rendering days, we had to write snippets to make the user feel like they were interacting with the server. That's where REST came in. But if you travel back to ASP.NET Web Forms, the nightmare of hiding the server interaction bit us hard. I don't disagree with most of your sentiments, but these same arguments have been being made since pre-2000. I do love your quixotic attempt though ; )
Cloud resources are massively overpriced for what you get (speaking as someone who has had a client on a 30+ S3 instance scale out azure webapp with scale up sql), there is also the latency up and down, the fact that under load you are looking at instances per visitor, which may drag on resources when you have 40k people hitting the site each day. if something doesn't need to be done on the server, do it on the client, it's less expensive to you and it should run faster. Cloud hosts are also NOT as reliable as a properly managed webserver, a website I made in 2015 is still up and going with no-one touching it since then on a server at my old employer's. I have had numerous instances where Azure fails, in one instance their whole data center went down in central US due to a lightning storm and it took 5 days to come back up with no offer or option of hosting the sites anywhere else in the meantime. All that being said there are ways and means, if I run a JS framework that resizes, crops my images for responsive scales, I am NOT going to make every visitor's system use that framework to do that, I'll change it to do it once server side for the various crops and scales and store the output in a blob as webp then use the dom to decide which image to use based on the browser size, this is all largely automated these days. But if the user wants to re-sort a list or move bits and pieces around on the screen just for them, then doing it on their system makes more sense.
spot on. This is doing the same thing in a different way with no benefit other than it's in c#. It's not that it's bad it's just tedious and new, most of that stuff is just boilerplate code you can write faster in react or some other framework. So yea there's no compelling reason to use or learn it other than you already know c# and you want to spit out some webstuff without having to retool for the more established frameworks
Blazor is definitely a great way to quickly build a utilitarian front end. I've used it for this purpose since scaling and threading are such a pain with WinForms. I enjoyed WPF, but I would get lost in the details sometimes. None of it was fast, but I loved the level of control.
@@SimpMcSimpy Hello SimpMcSimpy, what is the logic to switching winforms app to blazor at your company? I am currently using winforms for all my tooling apps at work and I wonder what is gained from switching to blazor in that case?
Ah Wiinforms, where binding is but an idea, and WPF where binding something complex is super-simple, but binding something simple is ridiculously complex.
I've coded in Blazor wasm at work for 2 years and I can see the attraction coming from a svelte + typescript full stack enthusiast. My issue with Blazor has been SEO applications, mobile performance, high demand of Javascript/Typescript libraries integrated; binding data between C# and Javascript which was the point of Blazor to avoid javascript/typescript. SvelteKit is very similar to Blazor with syntax and gets the benefits of performance and one universal language installing libraries. I make sure my code is written in typescript, not javascript on either Blazor or Svelte-kit.
Ummm, how the hell is your SEO taking a hit? Just from latency? Or are you trying to force Blazor data into a JS framework for the SEO? I managed to get onto first page natural google results for an Application I used to support (formerly it was pg5) without touching any of those JS packages and I can use Blazor to do exactly what I did previously. Mobile performance is quite good on my old Samsung S3, but then I am using cross-platform and server/hybrid mostly, not forcing everything into WASM which obviously relies more on local resources. But I would be checking your logic, making sure any loops are optimised, minimising file I/O etc. etc.
@@slipoch6635I'm going based on benchmarks compared to the 110+ different front end frameworks. The size of a Blazor WASM page is over 1MB. Google search "js Interactive Results" by krausest and you will see Blazor dead last with page size download and speed. You using a Samsung S3 is a small sample size and vague to point out because internet connection speed is also something to consider.
@@slipoch6635 Blazor wasm by design has over 1MB a page size whereas the majority of js frameworks are under a few kilobytes. This is coming from someone who wants Blazor wasm to succeed because .net has a faster backend than JS backend but blazor frontend is lacking in performance. It's ideal for interior applications that do not require SEO
@@slipoch6635 I wanna be respectful @swildermuth @slipoch6635. Blazor wasm pages have huge pages size to download. It has nothing to do with loops or minimizing files but how c# wasm is optimised. Even rust wasm frameworks like leptos or dioxus have similar issues but is faster for being a system level language.
It's 2024 and hot-reloading is sketchy and Blazor has no answer for rolling zero-downtime deployments(unless this changed very recently). They iterate too slow at one release per year; it will never compete with React and other frameworks at that rate for public facing apps that need a premium UX and DX with continuous deployment. You can't get any community contribution momentum behind an "OSS" project when contributions won't release for up to a year.. Or that at any point during said year a PM will just bump something to the NEXT year and it won't release until the END of that year! I think you are spot on that it's a good option to consider for internal, B2B, and other "workhorse" apps. It should be clear now, in 2024, that it's just not moving fast enough to ever close the gap to become something even MS would use for a project like Loop(as an example).
I need this tool, with a limited team i need to produce client-server app that runs on browsers, is a dedicated android app and is a dedicated iphone app. I simply dont have the time or manpower to write 3 different front ends. Maui and Blazor bridge this gap by using the same code for all 3. It does require some tinkering and adaptations, cookies are a good expample, but if you manage to build those abstractions so that you can use them on all 3 environments this is a great solution. We are still developing it, it ends up working, this will be an awesome tool. Loading sizes and time are an overblown issue.
No, it means you don't to learn new language or employ people just for web. Even an average C# coder can now quickly build a web application. I've been doing it for my company (internal tools) and I love it!
It's because the drawbacks (having a constant SignalR connection for server side or loading the runtime in the browser for client side Blazor) aren't that much of a showstopper for internal applications. We use both versions and I wouldn't dream of using a JS framework as there's just way more utility of having a common code base on the front and back end.
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.
Typescript exists and it does a really good job especially at fullstack while also being great for frontend and backend individually. I'm a Java guy and I also tried finding solutions to use my lovely Java in browser but the language is simply not built for that and the frontend world has so many cool techniques and patterns that are hard or ugly to implement in C# or Java. I ended up sort of giving up Java this year and I'm now sort of migrating myself to typescript & bun (Actually I've done typescript stuff for a few years but never really forced myself to adhere to good practices like never any). We've become so much more productive in typescript while also having the typesafety I loved in Java. And yes C# has become a little more modern than Java but it's still dated...
I hear that. I don't enjoy Node dev so I'm biased towards C# backend - and JS/TS on the front-end. But I understand why many want the same language on both sides.
@@danroth27 My bad, that's totally true. I should have been more specific. My research was more into lazy loading from a single project... Was trying to see if there was anyway I could build a convention based framework that just automatically lazy loaded components per route without manually specifying. Explored generating multiple DLLs per project but no luck so far. PS: I'm a big fan of the great work you do on Blazor 🙌🏽🙌🏽🙌🏽
I have dabbled in web development my entire career, but never really fully engaged as a full time web developer. Therefore, I am ignorant in a lot of things regarding modern web development. The biggest web application I ever wrote was back in 2004 which used java applets and Nexaweb (which I don't think exists anymore). Anyway, I have never liked HTML, CSS, and JS so always tried to avoid learning them well and looked for alternatives, like java applets, GWT, Silverlight, etc. Therefore, Blazor is wonderful in my naive opinion. I learned C# in 2010 when Xamarin came out so that I could do cross platform mobile apps. C# is by far my favorite language so getting to use C# for both backend and front end is very important to me. Every time I try to learn modern web technologies, like JS, TS, Vue, React, Node, etc, I just get overwhelmed with all of the tooling. It seems there are so many little tools and commands that you have to run to get anything done. Like, what is vite and why is it needed? Being able to click Run or Build in VS is so much easier while using NuGet for all of my dependencies.
One of the things that gets me is how many of the JS tools and systems like NPM etc. require systems access and pass it over to the package it is installing.
I've been using Blazor wasm for about 3.5 years now, and have been able to build some pretty interesting projects. I like it a lot, but am not quite a Blazor evangelist. The biggest problem by far is the tooling which is painful to deal with. Hot reload just doesn't work. So anytime you need to make even a minor change to the markup, you have to stop/restart, wait for the build to finish, the browser to launch, the debugger to attach, etc. It can be pretty tedious.
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.
Not having hot reloading as a frontender is a horrible experience. Having to compile the app over and over again drives med mad. Blazor should only be used in apps where user experience is somehow not important.
For me, as someone who has years of experience with Angular and React, I feel like switching to Blazor brings little value. I care as much about using C# for the front-end as I do about using JavaScript for the back-end. Maybe because I dislike the idea of front-end frameworks that hinge entirely on the back-end technology in use. Instead, I’d much rather see a brand-new, web-tailored language replace JavaScript, with fresh frameworks built from the ground up on that foundation.
Thank you Shawn! For many years you have been on my radar as v. informative and v. interesting... love fact you seem to be fan of Vue + Tailwind - you clearly actually DO substantial real-world dev. (so much trash published by people who seemingly just think about real world dev, but rarely if ever actually do it). haha. Don't get me started on some of the MS Patterns and Practices stuff (I mean wow!). 100% agree (with my admittedly v. limited experience with Blazor) that you are correct with the summary (if I got it right?) i.e. " Is it worth it? Probably not (assuming you are comfy with js/ts and e.g. Vue). Unless you have some v. specific requirements that make WASM a real contender for the functionality you need. " Pls do shout if that is NOT a good paraphrasing of your topline? Also totally hear you with the clunky tooling e.g. need to restart the app (vs what we now come to expect i.e. ~immediate ~perfect hot reloading dev experience for frontend). I do wonder 1. if you were a fan of Knockout before Vue (do I remember some old blog posts about KO)? 2. if you prefer Vue (3) Composition API (over Options) 3. if you tend to use Pinia or similar in Vue3? FYI I'm pretty firmly 1 = Yes, 2 = Yes 3 = No Apologies if you've totally covered all of that on a blog/other vids (don't have much time to research/hone these days). ;( Much appreciated!
1. Yes, Knockout -> AngularJS -> Angular -> Vue 2. Composition Syntax is so much easier than debugging the Options Syntax. 3. Yes. (Having stores that are testable business logic is key here). Same story I've been telling for 15+ years (WPF, Angular, etc.)
I'm actually intrigued with the whole .NET maui blazor hybrid concept. Because I think html css is the best UI language ever and the power of C# for controlling managing the logic is excellent, the only ballbreaker is the xaml, but I suppose that binding/mapping needs to happen somewhere. What are your thoughts on .NET MAUI Blazor hybrid apps
@swildermuth yeah, essentially blazor components inside a "webview" component but in a cross platform app. Under the leadership of James montemagno (on UA-cam)
@@swildermuth maybe I'm not doing it justice, but yes that was my initial thought too, however I would like to see yourself have a go and your thoughts on it, if you get a chance, because the idea is that you have one way to create a ui for all platforms (inc desktop in a single codebase In a highly productive language like HTML
The development speed is high with Blazor, which is very important cost-wise. I experienced how slow the development process with React can be and the amount of garbage you need to write to satisfy the framework. However, AI assistant coding tools can change the narrative, and JavaScript wins because there are cheaper/younger developers in the market.
Please do a 10 thousand feet view of Blazor (both server and client side) -- just basic description of what the different parts are , how they come together, how they talk to each other --- with the simplest possible project that can demo it. How to think and reason about Blazor. Would be a great great illuminator. Blazor is too big and fuzzy --- and horribly confusing.
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
@@Qrzychu92 Exactly! It's not JavaScript that is the biggest draw. I use mostly "Vite + React + TypeScript" for work and even some personal projects. However, anything non-web, Blazor Hybrid is what I would choose in a heartbeat. That is not what this video is talking about though. I do agree though I would just rather work in C# although I consider myself proficient in both.
The biggest lie about Blazor is people calling is a "JavaScript Killer". I wish we wouldn't do that. JS is a tool in our toolkit the same as any other tool. Use it where necessary, use it when you want, use it as you'd use any other tool. JSInterop is massively powerful, and even more powerful if your CSP isn't hyper-strict. You can inject tiny payloads of JS into any page that needs it, and clean up the DOM as components are disposed.
Kind of. I understand what you mean. Blazor isn't a replacement for JS, it's more than just another use-case. It's an additional render engine and routing pipeline that can be used as a part of the AspNetCore ecosphere. You can use MVC, Razor Pages, WebForms, Static HTML, MinimalAPI, WebAPI, Blazor Web App, and React, all in the same project if you like. They are all available to you as tools within your toolkit. Weapons within your arsenal. Choose your own analogy. As an example, if you want to remain within the bounds of PCI-DSS SAQ-A when building a checkout, then regardless of whatever render engine you use, you will have to write good old-fashioned JavaScript to interop with the drop in forms. The SAQ-A is a 19 page document with 22 questions. If you try to roll your own, and create your own checkout forms, because "We don't need JS now that we have Blazor! Why should I even bother learning JS anymore!?", then you need the SAQ-A-EP form, which is a 46 page document, with over 190 questions, and a quarterly external audit with an on-site assessment that can cost tens of thousands per annum.
I personally just dont like the though of GUI being integrated with your business logic which to me is what Microsoft's MVC does. Pick a language / framework that works best for your data logic. Pick a language / framework for you business logic. Pick a language for your Gui logic. If you make your language determine what you pick for any solely on "I don't want to have to learn / understand multiple languages" you are doing the application wrong. Personally my goto is Angular / typescript frontend , c# serverside , and database i'm starting to like Postgresql but Tsql is still VERY good imo.
The goal of MVC was to avoid the mix of GUI and business logic, but lots of companies missed the memo. I am with you, MVC/REST/MinimalAPIs are the way I prefer to write interactivity with a client - though I don't want to throw the baby out with the bathwater when it comes to some benefits of a hybrid model of server and client rendering. But just rendering.
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.
I think you're on the money here. Blazor (to me) fits into a space where you have C# full-stack (used to be WinForms or WPF) that need to move to web-based and have no time/interest in the JS ecosystem.
"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." I suggest you actually try Blazor Interactive Server for yourself... It has nothing to do with WebForms... WASM is still a novelty, but it has its uses. Think for example running a very CPU intensive algorithm... Or even running a desktop-quality game in a browser. You can run compiled code from a browser. Although, I agree too many people focus on WASM when talking about Blazor. They are two different things. WASM is an open standard, it's not reserved to Blazor. And honestly from the little Vue I have done (a little bit, not a lot), Razor pages do exactly the same thing, most of the time easier... Scoped styles, reusable components, two way databindings, etc all are a core part of Blazor too. And if you want to use API calls, just have at it! You can build a SSR application, a separate API layer, and use controllers if you want, you don't HAVE to use SignalR... But that kind of defeats the purpose of Blazor... I know plenty of JS, but I just hate it. Up until Blazor I HAD to use either JS or TS. I was making due. Now I can actually write the entire application in C# with near-zero JS and none of its limitations.
@@HMan2828 For C#-only devs, the WASM feels very similar to building in JS-SPAs. At least, that's how i'd use it. Though, I've been in JS/TS for so long, I'd likely not use it as I like how that ecosystem works.
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.
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 don't want to sound arrogant or sarcastic here, but this video very clearly sums up all the problems with modern javascript: ua-cam.com/video/Uo3cL4nrGOk/v-deo.html. Now if we consider that time = money then Blazor does exactly what it is supposed to do - increase my productivity by reducing the daily javascript build/maintenance hell that we all live in. Does that mean it is better than or more viable than javascript? I don't know, I'm not that smart or educated, I think of myself as an average programmer. But I know that it makes my job much easier, fun and it allows me to focus on what matters - building a product instead of constantly doing plumbing fixes. We went from Knockout to React to Vue and now the latest flavor of the month is Svelte. Every one of them was hailed as "game changer" and, in the end, they all end up being... just another JS framework.
That's not how I see it. The tooling/build for JS is, frankly, more mature than VS's Blazor WASM story. It's failings probably are hamstrung by the JS->WASM bridge deficienties. But if it is working for you, all power to you!
For developers that don't know / don't want learn frontend (html / css etc) then Avalonia UI is a better tech stack. With design preview integration to VS and Rider it becomes a much better developer experience without having the need to stop / start the app for each xaml change.
That's another way. But learning XAML isn't a piece of cake. There is a real learning curve; so if you are starting from scratch and building a web app, why not learn something that has a bigger community and usefulness in other use-cases?
The main thing I get from this video is that front-end web developers and back-end web developers are flexing two very different skill sets and expecting one developer to have true mastery on both sides might not be realistic.
respectfuly, this is a terrible take, small businesses couldn't be as successful as they are were this true. expect more of yourself, you can do it too.
While, yes, that's true. Lots of companies have needs for full-stack (small teams, internal apps, etc.) and this is an easy way to accomplish that. Not every app needs to be fast and scalable.
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! :)
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 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
Everyone knows that JS (even TS) becomes a mess when talking about large-scaling apps. This is something that JS devs are complaining about all the years.
The "for years" is an interesting inclusion. This had been true for years, but in the last 5 years or so (coinciding with TS's adoption), large scale JS isn't as much of a mess as it once was. Bad architecture is bad, no matter the language.
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
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?
Blazor is just another cheap attempt to avoid Javascript. Just replace the damn thing with something modern and strongly typed and stop creating these stupid frameworks or workarounds like typescript.
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've been using Blazor recently, and honestly it's the only thing that's made web development enjoyable for me at last
That's encouraging. Did you enjoy web development in the past, i.e. before React etc. took over?
@@crtglowgames Not really, javascript always felt like an hack to me
restarting the application to see css or html change is a nightmare .. hot reloading is so slow and keeps breaking ... it was a very bad experience for me. I'm talking about developing a WASM . I think non of these issues exists in the blazor server, but it is not what we need !
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.
Hot reload is a joke in all latest Microsoft products
Surprised to see so many people having issues with Hot Reload while it always works for me.
I’m picking up web dev after about 15 years of not coding. Blazor is what I’ve been learning and it’s awesome. I’m avoiding JavaScript for time being as I have stuff I need to get done.
All in on Blazor WASM for several years now and never looked back. After spending years toiling with the latest JavaScript toolset, Angular, Vue, and the ever changing client side landscape our teams are far more productive leveraging the .Net ecosystem on both client and server. Tailwind + Blazor component model + the stability of .Net library ecosystem is hard to beat
How do you deal with long loading when you access the page for the first time?
@mq9032 We’ve been use prerendering which loads page and static content quickly and provides SEO. Net 8 has also introduced SSR, Server-Side Rendering, and transitions to WASM. Both are viable options.
@@mq9032 If you use a blazor hybrid component it runs off the server until the component is downloaded then switches over seamlessly.
I wish I’d discovered Blazor earlier! Moving from JavaScript through Node, Express, TypeScript, React, and React SSR felt like a constant juggle of libraries, packages, and compatibility issues. Each JS project needed a mountain of dependencies, which we could only hope would work well together across versions. And then there’s always that one person at work pushing to experiment with Bun, adding to the chaos.
Remember when we used to think of React as a slow and clunky choice? Now, it’s evolved massively, much like Blazor.
My anxiety about React are more the programming model. It feels icky to mix JS/Markup. Not a probably for lots of people, but I don't enjoy it.
@@swildermuth Blazor mixes CS and markup. What's the difference?
Wow- I remember watching you on Pluralsight many YEARS ago and loved your videos. Had no idea you had a YT channel! Your Pluralsight reputation is enough to earn a sub from me...
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! 💙
I am honored to have been a part of your journey!
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
; )
Excellent analysis Shawn. A common thread I find is that the "older" C# devs really like it because they can do alot without touching JS/TS. One thing I found extremely helpful in larger enterprise grade app dev efforts is the ability to share class libraries. Can't do that with Angular or React. It's just a time saver and really helpful at buildtime.
Easier to share libs in C# for sure. Though Angular and React (and Vue) can share libraries via NPM packages (or there are ways to do this in Next and Nuxt). But I get your point.
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?
@@swildermuth It's is a low-code platform for .NET developers that helps you generate apps using Blazor or other technologies.
I think Blazor is the way to go for all. The question remains is which to use, SSR or CSR or Auto, this what will differ from project to another. I think as well there is no problem at all with bridging between JavaScript and the assembly code. It cannot be easier. I used it heavily in both Interactive Server Mode and WASM. I also got a quite enough experience with Angular and React. I can confidently say that everyone should consider Blazor, even those who are living in JavaScript/TypeScript world.
"I think Blazor is the way to go for all." - All never works everywhere. Different solutions for different problems. When I hear this, I feel like it's a press release. There are pros and cons to every ecosystem, including Blazor/MSFT and the entire JS/TS ecosystem. There is no one way.
Much appreciated, Sean. We really enjoy your objective takes on tech. Very validating.
Glad to hear it.
Didn't the publish folder contain both the compressed and uncompressed files? Then the size is much smaller than 20 MB.
I see that you create a separate component class from which the component/view inherits from. You could achieve the same with code-behind using a partial class. There is a refactoring that extracts @code block to a code-behind file. And if you want to test the components, like interactions and what is rendered, you can use a library like bUnit (together with favorite unit testing framework) that essentially mocks the view.
Didn't think about partial. That makes a ton of sense.
Out of interest, what are you gripes with server side rendering? The apps I have built are the most responsive web apps that I have ever seen, ever.
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.
I love Blazor and it only going to get better.
More power to you!
that's great and all, but better than what? better than what blazor was before? seems most anything is like that, things improve over time. Real question is how competitive is it with other things, is it "better" than those other things.
Totally Fully agree, have developed MFC, Win Forms, WPF and meanwhile Web only for decades and see Blazor in the niche you see it. Thx for digging deeper and verifying that.
Thanks!
This video answered the biggest questions I had with blazor. Whether it could be an alternative to JS frameworks.
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.
Curious. Given the two approaches, Blazor vis Java/Type Script and Rest. What is (ballpark) the total developer time spent on each approach. Is one faster then the other. Thoughts?
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.
It does, though the magic of the @ code {} I could live without.
I am using VueJS and REST-API and all running in a Golang Project. I completely moved everything from C# to Golang.
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
can you make a video or share a link about how to do it ?
@@androidsavior I haven't done anything like this, so I can't really make a video. But, maybe, someday.
@@androidsavior I will put an example on GitHub in the next few days and then post the link here
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?
Use Blazor with MudBlazor, Bolero and use the Elm(ish) pattern. Once you have understood the functional approach, you get results quickly. I made an in-house web app running with Blazor Server (WASM is out of question, our company PCs all run Sophos which analyses all binaries once they come in which slows the application to a crawl) and the customer wanted one component of that application as a client-side app, exchanging the server-based functions with some simple file I/O.
I managed to slap that component into a separate Blazor WASM application and use Electron to make the local application for the customer.
If that works for you, YEAH! This video is about Blazor WASM. I don't care for the non-standard communication between server/client but I understand why people like it.
I'm by no means a Blazor fanboy (I flip flop between Blazor and Svelte for my own projects) but re: 12:40 I'm interested to know why you consider learning Blazor to almost be lesser of a task/outcome compared to Javascript in the realm of web frontends? If Blazor is able to do everything you need, why is javascript even necessary? I've found recently that I'm not actually learning JS anymore, I'm learning React/Svelte/Angular and they just happen to use javascript. Ultimately the user doesn't care if the experience is good enough.
Visual Studio support is still not so great due to incomplete hot reload feature, but if you can digest few weak spots it can do nice job.
It is perfect for building internal tools (thinking about enterprise companies) or smaller businesses.
I've been into programming since late 90s and doing mostly system engineering, HATED doing any web coding. But with Blazor it's awesome.
Coming from mostly low level C programming, I am one of those who believe web should fully embrace web assembly.
This is why I see Blazor as a step in the right direction. It's far from perfect, but for simple and quick stuff it's good enough. And I underline this "good enough".
I just hope MS keeps it alive longer than some previous frameworks :)
That's where I am at with it too.
Yeah you can blame the visual studio code team for that, we had a decent hot reload for xamarin back in the day that the VS team got and when they implemented it the vscode team went to the upper managers and complained about studio stealing their functionality, so it got removed, then when the outcry was too loud they brought it back, but it never worked since then and half the functionality was missing, it still doesn't work great even for xaml hot reload.
We use blazer for an small application. The push back from outside the team, People who did not even work on the product was large.
Not an uncommon response. We tend to get bogged down with Dogma of what is 'best practice' when that isn't real.
I have been using blazor (hybrid & server mostly) for cross platform dev. I don't see an issue with using blazor server for your secure componentry then use hybrid for the other components and maybe a local js framework for any dynamic dom stuff, it actually works pretty well as then you can get rid of any heavyweight JS framework crap, have it use a component from the server until it is loaded locally and the user doesn't even realise it is now running locally.
TBH I like that I can inject a service directly into a component, and I don't have to have JS repeating the definition of my architecture as well as a backend definition in C# keeps things simpler to update in the future as you just update the one model, the one component etc.
Please note: I have been doing web dev for large and small scale operations for years and this is the first framework other than htmx that I actually think will be useful on a longer term basis
Your points are all valid, and building an application using WASM is really new compared to the other frameworks. However, my rethink is: Why are we building web applications from the client side? Historically, there is a reason for this: server-side resources were limited and time-consuming to scale. Hence, we could scale quickly by pushing the application to the client and minimizing the server-side resources used. Enter cloud resources and server-side dynamic scaling. With the server-side having resources, do we need the complexity and all the work to get the application to live in a browser as the application development platform? For horizontal applications (e.g. social media), but for enterprise applications that are all converted to web applications to solve a distribution and maintenance problem? IMO, these applications are much more stable, cost-effective, and, most importantly, reliable (all web applications have an unmanaged dependency on the browser and often the JavaScript libraries). I'm critical that we consider all the requirements and the changing tech for each development project. Yet, even as developers, where change is always constant, we like to continue doing it the same way.
Interactibility. Even Blazor Server is doing things client-side. (e.g. making the SignalR calls). If you think back to the client-rendering days, we had to write snippets to make the user feel like they were interacting with the server. That's where REST came in. But if you travel back to ASP.NET Web Forms, the nightmare of hiding the server interaction bit us hard. I don't disagree with most of your sentiments, but these same arguments have been being made since pre-2000. I do love your quixotic attempt though ; )
Cloud resources are massively overpriced for what you get (speaking as someone who has had a client on a 30+ S3 instance scale out azure webapp with scale up sql), there is also the latency up and down, the fact that under load you are looking at instances per visitor, which may drag on resources when you have 40k people hitting the site each day. if something doesn't need to be done on the server, do it on the client, it's less expensive to you and it should run faster. Cloud hosts are also NOT as reliable as a properly managed webserver, a website I made in 2015 is still up and going with no-one touching it since then on a server at my old employer's. I have had numerous instances where Azure fails, in one instance their whole data center went down in central US due to a lightning storm and it took 5 days to come back up with no offer or option of hosting the sites anywhere else in the meantime.
All that being said there are ways and means, if I run a JS framework that resizes, crops my images for responsive scales, I am NOT going to make every visitor's system use that framework to do that, I'll change it to do it once server side for the various crops and scales and store the output in a blob as webp then use the dom to decide which image to use based on the browser size, this is all largely automated these days. But if the user wants to re-sort a list or move bits and pieces around on the screen just for them, then doing it on their system makes more sense.
Blazor WASM is as old as Blazor Server. It shipped with version 1.0.
But the quality of Blazor WASM has changed substantially. It used to need to download the entirety of the WASM Fx.
spot on. This is doing the same thing in a different way with no benefit other than it's in c#. It's not that it's bad it's just tedious and new, most of that stuff is just boilerplate code you can write faster in react or some other framework. So yea there's no compelling reason to use or learn it other than you already know c# and you want to spit out some webstuff without having to retool for the more established frameworks
Blazor is definitely a great way to quickly build a utilitarian front end. I've used it for this purpose since scaling and threading are such a pain with WinForms. I enjoyed WPF, but I would get lost in the details sometimes. None of it was fast, but I loved the level of control.
In my company I am replacing all old internal Win Forms tools with Blazor.
@@SimpMcSimpy Hello SimpMcSimpy, what is the logic to switching winforms app to blazor at your company? I am currently using winforms for all my tooling apps at work and I wonder what is gained from switching to blazor in that case?
Ah Wiinforms, where binding is but an idea, and WPF where binding something complex is super-simple, but binding something simple is ridiculously complex.
@@slipoch6635 hahahaha I know for sure you've been there done that based on this comment. Hilarious!
I've coded in Blazor wasm at work for 2 years and I can see the attraction coming from a svelte + typescript full stack enthusiast. My issue with Blazor has been SEO applications, mobile performance, high demand of Javascript/Typescript libraries integrated; binding data between C# and Javascript which was the point of Blazor to avoid javascript/typescript. SvelteKit is very similar to Blazor with syntax and gets the benefits of performance and one universal language installing libraries. I make sure my code is written in typescript, not javascript on either Blazor or Svelte-kit.
I totally agree with your sentiment.
Ummm, how the hell is your SEO taking a hit? Just from latency? Or are you trying to force Blazor data into a JS framework for the SEO?
I managed to get onto first page natural google results for an Application I used to support (formerly it was pg5) without touching any of those JS packages and I can use Blazor to do exactly what I did previously. Mobile performance is quite good on my old Samsung S3, but then I am using cross-platform and server/hybrid mostly, not forcing everything into WASM which obviously relies more on local resources. But I would be checking your logic, making sure any loops are optimised, minimising file I/O etc. etc.
@@slipoch6635I'm going based on benchmarks compared to the 110+ different front end frameworks. The size of a Blazor WASM page is over 1MB. Google search "js Interactive Results" by krausest and you will see Blazor dead last with page size download and speed. You using a Samsung S3 is a small sample size and vague to point out because internet connection speed is also something to consider.
@@slipoch6635 Blazor wasm by design has over 1MB a page size whereas the majority of js frameworks are under a few kilobytes. This is coming from someone who wants Blazor wasm to succeed because .net has a faster backend than JS backend but blazor frontend is lacking in performance. It's ideal for interior applications that do not require SEO
@@slipoch6635 I wanna be respectful @swildermuth @slipoch6635. Blazor wasm pages have huge pages size to download. It has nothing to do with loops or minimizing files but how c# wasm is optimised. Even rust wasm frameworks like leptos or dioxus have similar issues but is faster for being a system level language.
It's 2024 and hot-reloading is sketchy and Blazor has no answer for rolling zero-downtime deployments(unless this changed very recently).
They iterate too slow at one release per year; it will never compete with React and other frameworks at that rate for public facing apps that need a premium UX and DX with continuous deployment. You can't get any community contribution momentum behind an "OSS" project when contributions won't release for up to a year.. Or that at any point during said year a PM will just bump something to the NEXT year and it won't release until the END of that year!
I think you are spot on that it's a good option to consider for internal, B2B, and other "workhorse" apps. It should be clear now, in 2024, that it's just not moving fast enough to ever close the gap to become something even MS would use for a project like Loop(as an example).
It wipes the floor with react, react is super overrated, try Blazor you'll never go back to React, EVER.
I need this tool, with a limited team i need to produce client-server app that runs on browsers, is a dedicated android app and is a dedicated iphone app. I simply dont have the time or manpower to write 3 different front ends. Maui and Blazor bridge this gap by using the same code for all 3. It does require some tinkering and adaptations, cookies are a good expample, but if you manage to build those abstractions so that you can use them on all 3 environments this is a great solution.
We are still developing it, it ends up working, this will be an awesome tool. Loading sizes and time are an overblown issue.
When you marry this with Maui, that's a different question. Glad it is working for you. You're the perfect use-case IMO.
I agree 100% with you. And when you repeatedly hear: "it's good for internal organization apps"...means that's a mess!
No, it means you don't to learn new language or employ people just for web. Even an average C# coder can now quickly build a web application.
I've been doing it for my company (internal tools) and I love it!
@@SimpMcSimpy Does it play well with third-party UI components?
It's because the drawbacks (having a constant SignalR connection for server side or loading the runtime in the browser for client side Blazor) aren't that much of a showstopper for internal applications.
We use both versions and I wouldn't dream of using a JS framework as there's just way more utility of having a common code base on the front and back end.
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.
Typescript exists and it does a really good job especially at fullstack while also being great for frontend and backend individually. I'm a Java guy and I also tried finding solutions to use my lovely Java in browser but the language is simply not built for that and the frontend world has so many cool techniques and patterns that are hard or ugly to implement in C# or Java. I ended up sort of giving up Java this year and I'm now sort of migrating myself to typescript & bun (Actually I've done typescript stuff for a few years but never really forced myself to adhere to good practices like never any). We've become so much more productive in typescript while also having the typesafety I loved in Java. And yes C# has become a little more modern than Java but it's still dated...
I hear that. I don't enjoy Node dev so I'm biased towards C# backend - and JS/TS on the front-end. But I understand why many want the same language on both sides.
Is there a way to code-split it based on routes to make it lighter?
@@muhammedadel9673 not that I know of
I went down this rabbit hole sometime earlier. Currently not possible as a single dll is generated
You can use lazy loading to load parts of the app based on the route.
@@danroth27 My bad, that's totally true. I should have been more specific. My research was more into lazy loading from a single project... Was trying to see if there was anyway I could build a convention based framework that just automatically lazy loaded components per route without manually specifying. Explored generating multiple DLLs per project but no luck so far.
PS: I'm a big fan of the great work you do on Blazor 🙌🏽🙌🏽🙌🏽
Blazor is great for the "admin" part of a website. Also just use server rendering instead of wasm.
I have dabbled in web development my entire career, but never really fully engaged as a full time web developer. Therefore, I am ignorant in a lot of things regarding modern web development. The biggest web application I ever wrote was back in 2004 which used java applets and Nexaweb (which I don't think exists anymore). Anyway, I have never liked HTML, CSS, and JS so always tried to avoid learning them well and looked for alternatives, like java applets, GWT, Silverlight, etc. Therefore, Blazor is wonderful in my naive opinion. I learned C# in 2010 when Xamarin came out so that I could do cross platform mobile apps. C# is by far my favorite language so getting to use C# for both backend and front end is very important to me. Every time I try to learn modern web technologies, like JS, TS, Vue, React, Node, etc, I just get overwhelmed with all of the tooling. It seems there are so many little tools and commands that you have to run to get anything done. Like, what is vite and why is it needed? Being able to click Run or Build in VS is so much easier while using NuGet for all of my dependencies.
One of the things that gets me is how many of the JS tools and systems like NPM etc. require systems access and pass it over to the package it is installing.
Blazor's use case is probably geared towards the more highend webapps, than your run of the mill webpage.
Or Enterprise/internal apps instead of websites.
I've been using Blazor wasm for about 3.5 years now, and have been able to build some pretty interesting projects. I like it a lot, but am not quite a Blazor evangelist. The biggest problem by far is the tooling which is painful to deal with. Hot reload just doesn't work. So anytime you need to make even a minor change to the markup, you have to stop/restart, wait for the build to finish, the browser to launch, the debugger to attach, etc. It can be pretty tedious.
quite insightful.
Thanks.
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.
Not having hot reloading as a frontender is a horrible experience. Having to compile the app over and over again drives med mad. Blazor should only be used in apps where user experience is somehow not important.
@@paragateosloBlazor does have hot-reload, unless you expect it to work when changing internals or something.
@@c1d3r-lf5ug well only slightly. Its highly unstable to the point of simple css prop changes ofte doesnt register.
@@paragateoslo Yea it is not ideal.
For me, as someone who has years of experience with Angular and React, I feel like switching to Blazor brings little value. I care as much about using C# for the front-end as I do about using JavaScript for the back-end. Maybe because I dislike the idea of front-end frameworks that hinge entirely on the back-end technology in use. Instead, I’d much rather see a brand-new, web-tailored language replace JavaScript, with fresh frameworks built from the ground up on that foundation.
I get that. But if Blazor works for some, I think that's fine. We don't need one solution for all.
Thank you Shawn! For many years you have been on my radar as v. informative and v. interesting... love fact you seem to be fan of Vue + Tailwind - you clearly actually DO substantial real-world dev. (so much trash published by people who seemingly just think about real world dev, but rarely if ever actually do it). haha. Don't get me started on some of the MS Patterns and Practices stuff (I mean wow!).
100% agree (with my admittedly v. limited experience with Blazor) that you are correct with the summary (if I got it right?) i.e.
"
Is it worth it?
Probably not (assuming you are comfy with js/ts and e.g. Vue).
Unless you have some v. specific requirements that make WASM a real contender for the functionality you need.
"
Pls do shout if that is NOT a good paraphrasing of your topline?
Also totally hear you with the clunky tooling e.g. need to restart the app (vs what we now come to expect i.e. ~immediate ~perfect hot reloading dev experience for frontend).
I do wonder
1. if you were a fan of Knockout before Vue (do I remember some old blog posts about KO)?
2. if you prefer Vue (3) Composition API (over Options)
3. if you tend to use Pinia or similar in Vue3?
FYI I'm pretty firmly 1 = Yes, 2 = Yes 3 = No
Apologies if you've totally covered all of that on a blog/other vids (don't have much time to research/hone these days). ;(
Much appreciated!
1. Yes, Knockout -> AngularJS -> Angular -> Vue
2. Composition Syntax is so much easier than debugging the Options Syntax.
3. Yes. (Having stores that are testable business logic is key here). Same story I've been telling for 15+ years (WPF, Angular, etc.)
I'm actually intrigued with the whole .NET maui blazor hybrid concept. Because I think html css is the best UI language ever and the power of C# for controlling managing the logic is excellent, the only ballbreaker is the xaml, but I suppose that binding/mapping needs to happen somewhere. What are your thoughts on .NET MAUI Blazor hybrid apps
Haven't used it. Is it HTML Based like Blazor WASM?
@swildermuth yeah, essentially blazor components inside a "webview" component but in a cross platform app. Under the leadership of James montemagno (on UA-cam)
Oh and it's an official. Net maui thing, not a 3rd party Extension
@@UmmarFarooqMahroof "Inside a WebView component", I get nervous.
@@swildermuth maybe I'm not doing it justice, but yes that was my initial thought too, however I would like to see yourself have a go and your thoughts on it, if you get a chance, because the idea is that you have one way to create a ui for all platforms (inc desktop in a single codebase In a highly productive language like HTML
The development speed is high with Blazor, which is very important cost-wise. I experienced how slow the development process with React can be and the amount of garbage you need to write to satisfy the framework. However, AI assistant coding tools can change the narrative, and JavaScript wins because there are cheaper/younger developers in the market.
cheaper/younger developer who don't understand why a loop they wrote takes so long when they have a file i/o op inside it.
blazor is the killer of js and all its funny frameworks :)
I doubt it.
Please do a 10 thousand feet view of Blazor (both server and client side) -- just basic description of what the different parts are , how they come together, how they talk to each other --- with the simplest possible project that can demo it. How to think and reason about Blazor. Would be a great great illuminator. Blazor is too big and fuzzy --- and horribly confusing.
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
@@Qrzychu92 Exactly! It's not JavaScript that is the biggest draw. I use mostly "Vite + React + TypeScript" for work and even some personal projects. However, anything non-web, Blazor Hybrid is what I would choose in a heartbeat. That is not what this video is talking about though. I do agree though I would just rather work in C# although I consider myself proficient in both.
Just FYI Shawn, typo in Title. Very cool video though, thanks man.
Oops, you caught me! Thanks for the heads up.
When it comes to front end nothing beats JavaScript
The biggest lie about Blazor is people calling is a "JavaScript Killer". I wish we wouldn't do that. JS is a tool in our toolkit the same as any other tool. Use it where necessary, use it when you want, use it as you'd use any other tool. JSInterop is massively powerful, and even more powerful if your CSP isn't hyper-strict. You can inject tiny payloads of JS into any page that needs it, and clean up the DOM as components are disposed.
Exactly. Blazor is a different use-case.
Kind of. I understand what you mean. Blazor isn't a replacement for JS, it's more than just another use-case. It's an additional render engine and routing pipeline that can be used as a part of the AspNetCore ecosphere. You can use MVC, Razor Pages, WebForms, Static HTML, MinimalAPI, WebAPI, Blazor Web App, and React, all in the same project if you like. They are all available to you as tools within your toolkit. Weapons within your arsenal. Choose your own analogy.
As an example, if you want to remain within the bounds of PCI-DSS SAQ-A when building a checkout, then regardless of whatever render engine you use, you will have to write good old-fashioned JavaScript to interop with the drop in forms. The SAQ-A is a 19 page document with 22 questions. If you try to roll your own, and create your own checkout forms, because "We don't need JS now that we have Blazor! Why should I even bother learning JS anymore!?", then you need the SAQ-A-EP form, which is a 46 page document, with over 190 questions, and a quarterly external audit with an on-site assessment that can cost tens of thousands per annum.
I personally just dont like the though of GUI being integrated with your business logic which to me is what Microsoft's MVC does. Pick a language / framework that works best for your data logic. Pick a language / framework for you business logic. Pick a language for your Gui logic. If you make your language determine what you pick for any solely on "I don't want to have to learn / understand multiple languages" you are doing the application wrong.
Personally my goto is Angular / typescript frontend , c# serverside , and database i'm starting to like Postgresql but Tsql is still VERY good imo.
The goal of MVC was to avoid the mix of GUI and business logic, but lots of companies missed the memo. I am with you, MVC/REST/MinimalAPIs are the way I prefer to write interactivity with a client - though I don't want to throw the baby out with the bathwater when it comes to some benefits of a hybrid model of server and client rendering. But just rendering.
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.
I think you're on the money here. Blazor (to me) fits into a space where you have C# full-stack (used to be WinForms or WPF) that need to move to web-based and have no time/interest in the JS ecosystem.
"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."
I suggest you actually try Blazor Interactive Server for yourself... It has nothing to do with WebForms... WASM is still a novelty, but it has its uses. Think for example running a very CPU intensive algorithm... Or even running a desktop-quality game in a browser. You can run compiled code from a browser. Although, I agree too many people focus on WASM when talking about Blazor. They are two different things. WASM is an open standard, it's not reserved to Blazor. And honestly from the little Vue I have done (a little bit, not a lot), Razor pages do exactly the same thing, most of the time easier... Scoped styles, reusable components, two way databindings, etc all are a core part of Blazor too. And if you want to use API calls, just have at it! You can build a SSR application, a separate API layer, and use controllers if you want, you don't HAVE to use SignalR... But that kind of defeats the purpose of Blazor...
I know plenty of JS, but I just hate it. Up until Blazor I HAD to use either JS or TS. I was making due. Now I can actually write the entire application in C# with near-zero JS and none of its limitations.
@@HMan2828 For C#-only devs, the WASM feels very similar to building in JS-SPAs. At least, that's how i'd use it. Though, I've been in JS/TS for so long, I'd likely not use it as I like how that ecosystem works.
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.
Blazor rocks - so much less work than angular
Sure, but Angular (until recently) was so much boilerplate. Which is why I ended in Vue-land.
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 don't want to sound arrogant or sarcastic here, but this video very clearly sums up all the problems with modern javascript: ua-cam.com/video/Uo3cL4nrGOk/v-deo.html. Now if we consider that time = money then Blazor does exactly what it is supposed to do - increase my productivity by reducing the daily javascript build/maintenance hell that we all live in. Does that mean it is better than or more viable than javascript? I don't know, I'm not that smart or educated, I think of myself as an average programmer. But I know that it makes my job much easier, fun and it allows me to focus on what matters - building a product instead of constantly doing plumbing fixes. We went from Knockout to React to Vue and now the latest flavor of the month is Svelte. Every one of them was hailed as "game changer" and, in the end, they all end up being... just another JS framework.
That's not how I see it. The tooling/build for JS is, frankly, more mature than VS's Blazor WASM story. It's failings probably are hamstrung by the JS->WASM bridge deficienties. But if it is working for you, all power to you!
What do you mean by js->wasm bridge deficiencies? Can you give me a concrete example?
@@MarkoMijuskovic en.wikipedia.org/wiki/WebAssembly#Limitations
@@swildermuth Honestly don't see why this is a problem...
@@minnedanhieux1040 Not being able to manipulate the DOM seems like a decently sized hole.
Development tools are a religion...
May your debugger go with you.
@@swildermuth And also with you
Performance is an issue
Runtime or startup?
Interesting interview: Daniel Roth & Nick Chapsas (ua-cam.com/video/2uLGXe95kTo/v-deo.html&ab_channel=NickChapsas)
For developers that don't know / don't want learn frontend (html / css etc) then Avalonia UI is a better tech stack. With design preview integration to VS and Rider it becomes a much better developer experience without having the need to stop / start the app for each xaml change.
That's another way. But learning XAML isn't a piece of cake. There is a real learning curve; so if you are starting from scratch and building a web app, why not learn something that has a bigger community and usefulness in other use-cases?
The main thing I get from this video is that front-end web developers and back-end web developers are flexing two very different skill sets and expecting one developer to have true mastery on both sides might not be realistic.
respectfuly, this is a terrible take, small businesses couldn't be as successful as they are were this true. expect more of yourself, you can do it too.
* if you want to
While, yes, that's true. Lots of companies have needs for full-stack (small teams, internal apps, etc.) and this is an easy way to accomplish that. Not every app needs to be fast and scalable.
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! :)
@@keyser456 Why go back to C# when you go just go back to Lisp, the great grandparent of TS? None of this new-fangled C-derived languages
@@BobFrTube You clearly haven't used Blazor WASM or you'd have moved away from TS yourself by now. Luddites gonna be Luddites though!
@@keyser456 You make many incorrect assumptions. I write peer apps, not clients.
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 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
As long as it works.
Everyone knows that JS (even TS) becomes a mess when talking about large-scaling apps. This is something that JS devs are complaining about all the years.
The "for years" is an interesting inclusion. This had been true for years, but in the last 5 years or so (coinciding with TS's adoption), large scale JS isn't as much of a mess as it once was. Bad architecture is bad, no matter the language.
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
I think it's fine. Sure, it's not a mustache language, but I am not sure v-for is much better than @foreach.
maybe you should take some lessons how to use it :)
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?
Say's some random guy on youtube...
Blazor is just another cheap attempt to avoid Javascript. Just replace the damn thing with something modern and strongly typed and stop creating these stupid frameworks or workarounds like typescript.
I can't agree (especially around TypeScript) but if JS works well enough for you, glad it works!
no it isn't