Yes, this is one of the first times where I had that reaction of "Wow, Microsoft really found a great thing here, I hope they continue investing in it" and they *did*! Usually when I get excited about something like this they end up abandoning it (like XNA Game Studio, for example).
More Blazor jobs are appearing in the UK market. I'm transitioning my company over to it from razor pages and mvc. The new 'united' version of Blazor solves the issues we've encountered, looking forward to it.
Hi, do you need a blazor dev? I am currently looking for a remote opportunity to work with blazor, perhaps even part-time or project-based I live in Buenos Aires, Argentina
@@oddikaro8236 It makes certain tasks much easier, eliminating 'bridging' code between C# and JS. Complex data editing forms are much simpler to program in Blazor.
"Stream Rendering" is another great feature coming in dotnet 8 Blazor. It allows the pages to render with the placeholder content while the long running async tasks are running. When the tasks are completed , the new content can be streamed to the client on the same response connection and then patched by blazor into the DOM. How cool is that !! With the goods of both server and client side rendering, I think Blazor is moving towards right direction to become a full stack web development framework.
We use Blazor WASM (.NET7) in production and while it was frustrating not being able to use a lot of the JavaScript features right off the bat without interop at first, but as I've learned more about coding the client side in C# (I was not a .NET developer before working in Blazor, I came from Vue, React, Angular) I am now in love with leveraging the power of Visual Studio, C#, and the suite of great Microsoft tooling for devs. State management and event handling throughout the application is so nice.
We went with it for our latest project in my team, mostly only by the fact that it's very friendly for pure back-end developers, we have a lot of people in the team that haven't worked in React which some of our older applications use and it's super easy for them to learn the front-end parts of Blazor and get developing so much faster.
Thank you, Tim, for your videos. Right now, we are migrating the front-end of our solutions to Blazor WebAssembly and Blazor MAUI for their simplicity and versatility.
Blazor looks amazing (I loathe and despise Javascript, but I love C#, so Blazor is right up my street), but I've struggled to find good resources to help pick it up. Most of it seems aimed at absolute beginners but once you get past a hello world page, or a page with a counter on it, there seems to be a gulf to how to put that into practice - proper learning resources that really show you how to use it at the scale of a realistic website. (How to organise stuff, tooling with R#, that kind of thing).
I have a playlist on this channel for the Suggestion App. We use Blazor to build a full web application that is actually in production today at suggestions.iamtimcorey.com I also have a course on Blazor Server and I'm developing a new course for the new parts of Blazor in .NET 8.
@@IAmTimCorey- My friend, that is NOT a "full web application". It's one step above Hello World! I could write that in a day or so. NOT anything LIKE a full on production application. Total bullshit.
I have 3 projects currently running with Blazor. They work perfectly. It allowed me to be able to develop Fullstack in Net Core in a much easier and more productive way. And each update grows in potentiality.
I wrote my first major web app for our college in early 2018. It had a .NET Core back end and an Angular front end. As soon as Blazor was released, I rewrote the whole thing and ditched the Javascript side of things as quickly as I could! Been using Blazor to build pretty much every web app since, and until something better comes along, I don't see myself switching away. I just like having everything written in a single language. I don't like having to switch between C# and Javascript (or Typescript). It just makes maintenance more complicated. Having said that, I built that web app in my very early days of developing full apps, and used a horribly, unnecessarily complicated multi-layered project structure which has also resulted in an app that's still horrible to maintain, so I'm just waiting for a bit of breathing space in work to redevelop it using the knowledge I've gained in the past 4 or 5 years to make it a lot simpler. But you know what businesses can be like - if it's working, there's no incentive to change things just to make *my* life easier...
We started a very big project in .NET 7, we invested a lot of time in research to choose the web part, blazor was our preference, but still due to the lack of good components and doubts about its future we opted for React, but if you doubt me I I preferred Blazor. I participate in another project, this one is less important, but it is being done in Blazor Server and it is going very well and we have another project, another company that is already in production, also in Blazor Server and for now everything is working very well. .
We had the same issue. Our UI guy and the client agreed on totally different UI which no third-party component libraries would match the outcome, so had to write our own components in order to match the UI/UX and the project we are doing is insanely big in Blazor Server.
The SignalR tech and the ability for the web application to 'transition from online to offline' capability is making me reconsider. 'Always online' is problematic and I am happy to see movement towards addressing this. Having a 'JavaScript Shop' is pretty nice too as so many solutions are available at your fingertips.
After the bit of an rocky start with alot of stuff being "preview" and constant breaking changes, the blazor development has really stepped up the game. I'm so glad i pushed my workplace into the direction of "this new emerging technology called blazor" back in the day instead of becoming yet another node+vue/react/svelte/angular/... shop. Life is so much easier now. Thanks for the video. Eagerly waiting to update all of our Blazor apps to .NET 8 -time and using all the new cool features.
I haven't used blazor, but I will be starting a new job that uses it for newer applications, so this is good information to hear. I much prefer coding things with C# over JavaScript, so I'm excited to try it out.
I use Blazor for some personal projects. I occasionally need to use the JS interop for things Blazor doesn't support but I presume such occasions will become less frequent as Blazor becomes more feature rich.
I think that will be the case, but I also thing that the interop will always be important since there is such a large set of JavaScript libraries that are available.
@@Feronom i would say it's pretty easy to use. the conversions happen pretty much automatically by the interop in both directions. the only thing i found slightly awkward is needing to have the JS functions i want to call, defined or referenced in the Layout. i think there is even a (compiler?) warning in Visual Studio if you put it in the content (a page component). maybe it has something to do with it being an SPA
In enterprise software ive found that you cant build a Blazor site using only C# for most serious projects. So far there has always been reasons that I have to reluctantly use javascript in the Blazor project as well. Most recently because a 3rd party plugins the comp I work for uses, can only be used with Javascript. Javascript is just still too ubiquitous on the web to get away from. That being said, I hope Blazor gets more adoption and get extended as a tool and libraries. Its amazing to work with for someone with C# exp!
It depends on if you use the control libraries or not, but I also don't see an issue occasionally dropping into JavaScript when necessary. It allows us to utilize the extremely large marketplace of existing libraries while mostly sticking with C#.
It's interesting to see a lot of the larger community talking about server side rendering and/or failure at being "full stack". It plays right into Blazor's hands. The biggest problem MSFT faces is that many developers, even dotnet developers, refuse to see dotnet as a web front end environment. Of course, the rise of SPA frameworks had a lot to do with this. For me, I've also raised an eyebrow at SPA. Client side code made sense to me, when it made sense. It's the classic "It depends" but there were many times I felt like some reasons for client side code was merely "because I want it that way" over an actual engineering decision. I appreciate that you said "Every tool has a purpose, and not every tool fits a job." Well said and I advise everyone watching to take this approach when considering your choices.
Yeah, making the right choice for the right situation is incredibly important. It is also the reason why experience in the industry is important. After you've been burned a few times, you learn to make better choices. The thing I like about Blazor in .NET 8 is that it will allow you to mix and match what you need on a per-page basis rather than on a per-site basis. That means I can do server-side rendering (SSR) for the static pages, and just bring in the SPA-like features on pages where interaction is needed.
What I really misses about Blazor are UI Components. JavaScript has a rich set of DatePicket, DateTable and so on but this is not the case for blazor. And I miss great tutorials to start with blazor. When you read about Blazor it's always about the rendering. Ok I got it. But what's next? I'm used to get my data over Ajax from my WebApi. In Blazor I can get it directly from DbContext (EF). What if I want to continue with the WebApi? What is best practice there? Another big issue I found is the behaviour for submitting a form back to the server. It offers a DataAnnotation and ... but how can I write my own UI Components? The Edit form is for demo purposes only. And I don't want to use DataAnnotations but FluentValidation instead. Maybe I have a case where I want to show the user what he filled is invalid but in the same way save it in the database because I don't want the data loss.
yeah. i totally recognize those problems, but i found solutions to them. hopefully these rough edges will get worked out at some point. i also missed UI components. but Microsoft did actually make some UI Components called "Fluent UI Web Components" (i found out by reading their reactions on their blog as many complained). which are basically the controls used in MS Teams. but i think they are still working on a DatePicker (it has a git repo and the developers are on the Discord server mentioned in the microsoft documentation). for date i went with the builtin InputDate Form control, which translates to the browser's standard date picker, and i bound it to a nullable DateOnly value. and i guess there are also lots of third part controls. i also encountered the same problem as you with the default behavior of form validation. you can actually change that by subscribing to the Form's OnSubmit event (which is always triggered) and not registering to the OnValidSubmit event (which causes validation). i use this to do custom validation. in my custom validation i manually get the DataAnnotations validation results with Validator.TryValidateObject and do my own validations (you could also save to the database). then afterwards with the result, i set the validation messages using the EditContext's ValidationMessageStore. i havent used FluentValdation though, as i try to avoid third party stuff. hopefully this helps
I was s heavily invested in Silverlight back in the day, but I have t admit, Blazer needs to catch fire very soon or it will fall through the cracks....2023 was meant t be the year Blazor took off!!!
If you read through the comments, I think you will find that it has taken off. Trying to identify what has "taken off" really does depend on the area as well as how they are advertising. Don't forget that an ASP.NET Core job could be building Blazor or MVC or it could be MVC now but switching over to Blazor.
I really like blazor, I'm migrating several applications to blazor server. And I'm developing a new project this year here in mexico related to financial system, I hope to launch in production at the end of the year. Thanks Tim for your tips.
At my job, I replaced a hybrid Windows Service and Xamarin enterprise application with a Blazor Server-Side (SignalR) single code base solution using MudBlazor, Dapper and I loved the experience. The beta testers all like it better than the old pure Mobile app and having to deal with deploying, etc.
Something people don't talk about is just how much time you need to dedicate to maintenance of Vue, React, Svelte. Every week something new comes out and the old thing just gets dropped completely. And if you have security scanner you have to update when a venerability comes out. Angular is much better here but still not even close to dotnet. I worked with React on a project for a few years now and the amount of work we spent on switching from classes to functions, updating libraries that switched to hooks, dealing with React script, changing enzyme to RTL... is insane. It's like every week you have to do something. Also recommendation on what is best practice changes constantly and you constantly need to make decisions on code reviews should you allow a new style because everyone is recommending it.
@@FilipCordas In the dotnet area you have also the evolving aspect of the language. Some simple examples: check if something is null can be done in a lot of ways; to create an empty string can be done as far as I know in two different ways
@@PeteStyla Sure I know a lot of ways to check for null in c# (f# doesn't have null) but all ways are backwards compatible and are garantied they will never be dropped so your code will run on new versions of dotnet. The big issue with dotnet was when they added multiplatform support and some windows dependent features didn't work but that issue doesn't exist with projects started after 2013 or so. I updated from all versions since core 1 and didn't have many issues unless something specific that was easily resolved. But you can also stay on older versions since you still get security updates for almost everything people still use web forms from 20 years ago and you usually update quickly.
I have been Blazor since it was 6 months old. Its improving. More and more companies are going full cross-platform from WinForms either with Blazor or Avalonia.
My personal idea is Microsoft should more focus on improving Blazor to compete with other SPA frameworks rather than making it another MVC/PHP kinda thing. Doing so, it can fills the gap between frontend and backend developers and all the developers can work as fullstack developers. Blazor WA already have great features such as interacting with native assemblies, JS interoperability...etc. In the other hand, sometimes Blazor server side gives more headache due to bi-directional communications are blocking by firewalls and API gateways of some enterprise architectures. Hope this wont end as another Silverlight.
It feels things change faster and faster, so the only thing the devs have time working on is upgrading frameworks and implementing new features instead of having a stable framework that doesnt change all the time. As a developer the product owner only sees what the product does, not how the inner working are. So you seldom get the time to "improve code" without it coming with some new fantastic feature.
Just updating to the latest version of .NET will almost certainly make your app run faster with no additional changes. That alone is usually a good enough value to justify the upgrade time.
From our experience, Syncfusion's tech (unresponsive) and sales support (unreasonable) were poor, so we switched to Telerik UI for Blazor and never looked back. However, the Syncfusion Blazor UI components themselves were fine.
Been using Blazor since Jan 2020. Was going to start with .NET 5 also but had to start with 3.1 as our deployment was on version 3.1. I regret not pushing for an update to 5.0 but on the other hand I got alot of knowledge about how Blazor works and creating ALOT of components myself as alot components simply did not exist like a simple radiobutton. I had to create my own which eventually became almost the same code as MS used when we finally upgraded our stack to .NET 6 and suddently I had a lot of naming conflicts with my components and they were called the same as the MS ones like the RadioButton component.
I like typescript, but not having to configure vite, and TS.configs and managing packages makes blazor really enjoyable for me. And Blazor hybrid is wicked smooth and easy with MAUI! I am more inclined to Blazor than Vue and React at this point, however lots of things only have js/ts clients and SDKs though so that often influences my decision to use a JS framework. Note I only have experience with Blazor wasm/hybrid so haven't experienced the ssr dx
I'm glad to hear to MS keep on doing Blazor improvements, as I've been working with that for some years. Blazor does have some inherent problems though. Server side rendering doesn't scale great on more complex pages and it is easily eating up server resources, and does require that connection to be solid. And client side Blazor (wasm) quickly gets very big if your project is more complex - so it has a very slow first load time. So the lure of C# on the web is nice, but I am not sure it will survive the test of time really. The 4 or 5 or however many load modes now coming is just a way to work around those core issues, not something a developer really wants to deal with.
All valid issues but for the client wasm slightly over estimated in general due to user error, as in most folks don't pay any attention at all to the compiler options, you can squeeze stuff mightily and drop stuff that is only theoretically ever called. Decorating your methods with proper attributes also helps the compiler quite a bit.
I think the biggest confusion with WASM is on who is to blame for large client-side projects. Sure, WASM will be slightly larger than a JavaScript framework at the beginning because of the runtime. However, that's a minor difference and it doesn't grow with time. The only thing that grows is your code. So, the more you want to do on the front-end, the larger your app gets. That will be true no matter what language you choose. As for Blazor Server eating up server resources, that again isn't really a Blazor issue. If your application is eating resources, debug and fix it. A Blazor Server project is no different than an MVC project or Razor Pages project when it comes to server-side except for the very small connection via SignalR. That connection doesn't eat resources when the app gets bigger. What would eat resources is if you either had an enormous number of connected clients (10,000+ at a time) or if you are transferring enormous amounts of data to the client all the time (selecting all rows of a table instead of limiting on the server, etc.) The transition from Server to WASM at runtime will eliminate the slower load times and the need for constant connection, but it will still come down to writing good, efficient code.
Avalonia is also something to look at, especially if you're a wpf developer. It's a framework that let's you create multi platform apps incl webassembly.
Avalonia is great but has a huge drawback for any complex application. There are no UI frameworks that support it (Telerik, DevExpress, Syncfusion, etc.). Complex software generally requires one of these UI libraries.
@oddikaro8236 and does Blazor have the same drawbacks? I'm genuinely asking because I'm new to Blazor. In my applications, I never have had any real need for the third party frameworks you mentioned. If I needed a particular control, I just went on and created it myself.
@@chewingal2324 W.R.T. UI controls Blazor has support from big UI libraries (DevExpress, Syncfusion, etc.) and it also has open-sourced ones like MudBlazor and Radzen. So, in that regard it is really nice.
i haven't experienced a faster idea to concept framework than blazor server. i prefer blazor wasm, or another backend/frontend split, when moving from PoC to a fully production app, but blazor is ... blazingly fast.
I am using blazor since 2020 with blazor wasm... Lot more updations are available in each version and waiting for the blazor unified... In my opinion, blazor unified will remove the load issue, that is the only problem that we faced for our projects... Hope for the best....❤❤
Yes, you can do that just like you would with any other site. Since the connection stays open with SignalR, you don't even need to worry about switching servers between calls. With that being said, I haven't done this myself so there may be something I'm missing but as far as I know, you should be set.
There are really good topics you touch on. Personally, I really think it's cool to be able to do something in javascript, but I just think it takes a really long time to get from A to Z to have something finished when it's not backend and frontend on the same platform. that's why I've switched from Nextjs to Kaste over Blazor Web.
Everyone speak about blazor feature but no one speaks about that signalR Connectivity, the signalR connections is it limited to some number? or azure signalr service may need to pay just to establish connectivity?
You can have thousands of concurrent connections with SignalR. How many depends on the resources of your server (RAM, mostly, I believe). My rule of thumb is to start thinking about offloading work to the Azure SignalR Service after I'm consistently getting 10,000+ connections at a time. Not per day, at one time. A decent server could probably go over 20,000 without an issue, but I like to have margin.
We in progress of porting the huge desktop app to web. Tried blazor. The performance test showed 6 times performance degradation. And it was simple algo..so, maybe it works for simple web pages... not for heave CAD apps. We continue researching.
Doing heavy CAD work in the browser is going to be extremely hard. There's a reason why CAD machines are typically more powerful than "normal" desktops. Think of the browser as either an under-powered computer or a thin client. If you do most of the work on the server, the browser can act as a thin client, just displaying the work the server did. The way to do that in C# would probably be Razor Pages or MVC. If you want to do a lot of work on the client (such as interacting with the drawing or creating drawings), the browser is an under-powered machine. The browser itself is an app running on a user's machine (of unknown specs). That app doesn't provide full access to the CPU, RAM, or video card. It translates your request through layers before sending it to the OS and then the hardware. There are a LOT of things in between your request and the hardware, and each of these slows you down. There are some things you can do to improve performance, but at the end of the day, a web app does not have access to nearly as many resources as a desktop app.
The ability to switch modes between Server and WebAssembly sounds like exactly what I’ve wished for for Blazor-but for a different purpose than you described. My dream is to be able to build a Blazor app that works in WebAssembly mode when an internet connection is unavailable (so it can work offline/as a PWA), but can switch to Server mode when online. Basically getting all the benefits of Server when online (like directly talk to DB, no API) but still be able to work offline. As far as we know would the runtime “mode switching” enable this kind of thing? Or will it be too limited/intended mainly for simple things like speeding up startup as was mentioned?
It can be daunting at first, but now I’m getting into it I love the component based page setup (which I guess is more Razor than Blazor), and still miss my session state from webforms and a lot of stuff that seemed more straightforward there, but I’m gonna stick with it, MS usually knows what they’re doing for developers.
Genuine question, I love blazor and the easy way to build sites with it in c#. But I can't use it in production because both server and webassembly have one big issue... Webassembly has an initial loading time to download the JavaScript, putting a lot of end users off. Blazor server helps this, but if you switch tabs and reopen the site, the signal-R needs to reconnect... I'm really looking forward to the new feature to switch from Server side to Webassembly in .Net8!
Yep, that's going to be a huge feature. I also like the ability to do server-side rendering for pages that don't need interactivity. That will slim down the app even more.
This is the reason i didn't use Blazor till now , if this problem is going to be solved that would be amazing i will start learning and working on it seriously
Thank you Tim for this nice video. I have been using Blazor for almost 1 year moving from MVC. However, there are somethings that I don't like in blazor such as could not accessing the DOM. I always feel like a prisoner. Do you think that Microsot will allow accessing the DOM in Blazor?
Blazor WebAssembly has no DOM access because WebAssembly has no DOM access. That's outside of Microsoft's control. However, usually you will find that there are ways around the need for direct DOM access.
Yes, they are, although they don't have the .NET 8 stuff. I did update them for .NET 6/7. I am considering doing a new course for Blazor in .NET 8, though, since so much will change.
According to the videos I have seen, the auto mode will only switch to Web Assembly on the next load of the website (basically browser cached the WASM version during the initial server-side app).
Dammm, I missed the July sales thing, ;( i wanted to get the C# prove it bundle to polish up holes in my understanding, I finished 3 of your courses and random yt videos, My .NET education has been you (thank you so much), kudvenkat, raw coding and nick chapsas, and the books by Mark J Price. Now I am at a good place and was hoping to go through the bundle so I don't feel like all the time I dont know something. I wish next time you put up a sale it's done like at the end or beginning of month, when ppl usually get monthly cheque. And still hoping for region based pricing ;( some other platforms already do this, When you get $2000 a month on a expensive to live poor country as a junior developer, its kind of hard, but definitely still worth it but I am still hoping for region based pricing. Lastly, very cool video, really needed this, was literally wondering about where blazor is heading, especially in new projects as ms did not have a good track record before, but I think can trust now with the new approach with .NET core etc.
thanks for your video, I have a question, if you are a c# person and want to improve your resume for better options in market, would you learn blasor or go for JS frameworks ?
Hello Tim, Great video as usual. :-) Is there an AI that can assist with CSS/html layout allowing you to add the blazor code behind it? (I suspect something like bootstrap templates.) If so, what AI do you advise and can you do a video on implementation? Thanks
A little yes, a little no. Yes, they are still supporting WinForms, which was developed 20 years ago, but that's because that is what companies still wanted. No because we are talking about Blazor, a brand new UI that came out in just the past few years.
If the render mode can be changed at runtime, I wonder if we could finally get rid of the "trying to reconnect" problem in Blazor Server apps that are idle for x amount of minutes. They really give a bad user experience.
This concept is in regard to Blazor WebAssembly. I believe the .NET runtime that downloads (once) is around 1MB now. Any code you create will be added on top of that now. That's common for a WebAssembly application. 1MB sounds like a lot, but on the modern web it really isn't. For example, if you went to www.youtube.com and watched how much data is loaded, it will initially load about 12MB and then will load another 16MB (for a total of 28MB) in the background. That is just on the homepage on my desktop. I just loaded ESPN and it was 15MB. Stack Overflow is super-efficient (and has few images) and it is 3.7MB. The transfer rates will be about a third of those numbers (compression, etc.) Beyond that, you need to think of a Blazor WASM app as an application, not a website. Those are two different concepts. This is only considering straight Blazor WebAssembly. If you use the new Blazor Web App, you can pick which parts are WASM and which are Server or SSR. You can get the most performances possible while using the least resources possible. Finally, when it comes to long load times and long startup times, that again is going to come down to how you program your app. If your app is massive and has lots of blocking calls, yes, it could take a long time to load. If you develop it right, you will only have small, reasonable wait times.
It is definitely an option. What it comes down to is preference. You can be a full stack developer in a number of languages. The question is do you want to. Personally, I like JavaScript but I don't want to spend my career neck deep in it every day.
My company reverted 2 major apps when they realized that Blazor has no future and are to difficult to use if you require anything else than a demo application with a simple button and a dropdown.
Sounds like they made a mistake because of poor information. Blazor has a very bright future and it is one of the easiest frameworks to use, even for complicated tasks.
Hello Tim, Very nice video but i would like you to do the same after the .NET 8 release. What do you believe about the new template "Blazor Web App". Does Microsoft promote it over Blazor WebAssembly template? what is the future of Blazor (WebAssembly) from Microsoft POV.
I'll cover .NET 8 when it gets closer to release (November). The Blazor Web App template allows you to pick what parts of Blazor you want, including WebAssembly or Server. You can also choose SSR and then add Server or WebAssembly to just the pages/components that need it. Basically, instead of being forced into one box or another on creation, you can choose what fits best as you go and change that as needed. That's a great thing. WebAssembly is a big part of that.
@@IAmTimCorey My point is that companies have already invested in Blazor WASM. Changing to something else / changing to another architecture isn't that simple. Again, this new thing look promising, and from hobbyist perspective i like it... but i am a bit skeptical about Blazor WASM future.
It shouldn't be back to square one. You should still be able to use the "old" thing in production. Businesses don't just use the latest and greatest thing.
No. First, it is designed around web standards, not proprietary technology. Second, Silverlight is remembered for the wrong things: th-cam.com/video/uH3z0ja7qfE/w-d-xo.htmlsi=pmIJ278UZ3VV_PHJ
Surface designer? Do you mean a WYSIWYG designer? If so, that's not going to happen, nor does it need to. That's not how the web is developed. When you try to do WYSIWYG designers on the web, you get sites that are decent but not great. They typically are overly-verbose, hard to use for people using screen readers, and not great on all screen sizes. They have their place, but it isn't in custom development.
I'm a frontend / javascript developer, working in a company that uses awful, ancient, bloated, messy spaghetti code, no documentation, no code standards, a mix of .NET, jQuery, kendoJS, etc... There's been some talk about new tech and rebuilding the whole thing from scratch... But since the backend is all .NET and most engineers here are C# programmers, it might end up being Blazor. Even though it's new to me, the current one is so awful that I'm willing to learn it rather than keep hacking and complicating this monstrosity we're currently using. Questions: is there something Blazor can't do that modern JS frameworks like React can? Can you recommend learning materials suitable for JS developers for learning Blazor / C# ?
Blazor is really powerful, and the limitations are shrinking away. For instance, right now Blazor Server needs to be always connected (SignalR connection to the server). That doesn't work for all environments. Blazor WebAssembly is offline capable (PWA) and is fully client-side like React, but the initial page load can be heavy (don't test it in development, though - that will be really slow because of debugging - test it after you deploy it). These limitations can be concerning for some applications, but with .NET 8 (coming in mid-November 2023), Blazor is going to eliminate most of these downsides. We will have the ability to switch from Blazor Server to Blazor WebAssembly so we get the fast page load and then the offline-capable fully client-side project after it is downloaded in the background. We will also get fully server-side rendered Blazor (SSR) for those pages that don't need client-side interactivity. To top all of that off, you can still easily integrate any JavaScript library into your Blazor app, so you don't miss out on the rich ecosystem of tools, libraries, and frameworks that are available in JavaScript.
I think there are so many intuitive approaches & dev experience they could/should still adapt over from Remix/React. Coming from the other side, I see where they took inspiration from, but am slightly annoyed with their 'alternate' interpretations of what is in essence, the same thing (razor code vs TSX/JSX and their library) - there's no need to recreate the wheel from what is already very refined (and with good reason).
None. You can make anything you want with it without attribution, etc. I don't believe you can take the Blazor source code and claim it as your own, but that's about it. Microsoft provides you the tools to build Blazor apps for free (Visual Studio 2022 Community Edition, Visual Studio for Mac, or VSCode). You can then sell that app or create a SaaS out of it and make tons of money off of it without restrictions. Basically, you can build a business for free using their tools and technology. Once your company makes $1,000,000/year or more, you will need to purchase a Visual Studio license, though.
Am I the only one who has issues debugging my Blazor Webassembly projects in visual studio community 2022 after updating from version 17.4.* to 17.6.*? If im not the only one I just think its funny that Microsoft wants people to start using Blazor, while making it impossible for people to debug their projects for weeks.
Well, I met with Blazor in MVC trying to create an uber super complicated form. It was very easy comparing jquery stuff. I already used Angular before and I knew how component-based development runs. I litteraly loved Blazor! It made me faster than I expected. In the future I am planing to learn maui+blazor hybrid app to be full+full stack developer :D. You are helping so much. Thank you for your videos.
Ok, so I am on the hook. Anybody running an OpenSource Blazor Project I could contribute? Really would like to do something hands-on - but not alone in isolation. Anyone?
Tim - is a course due which will take us through learning this from scratch? (or at least from an olde Web Forms developer’s perspective) - or are you waiting for some stability in features yet?
I have the Blazor Server From Start to Finish course that covers Blazor Server only: www.iamtimcorey.com/courses/blazor-server-from-start-to-finish/ As for the other flavors, not yet but I will be adding courses for them.
It depends on what you are trying to say. Blazor WebAssembly does operate like Angular in that all of the source code runs on the client. However, if you are saying that should be the only way to do things, that's not correct. There are downsides to client-side applications. For example, you cannot do direct data access securely. You need to run through an API, which increases latency and requires an extra spot in your web server (2 sites instead of 1). You also have the issue of initial load time. There is a reason why server-side web development is still king on the web. WordPress, for example, is server-side rendered using PHP. The power and speed the server offers and the reduced bandwidth usage really makes an impact. The key is to look at technologies as tools to be put in the toolbox rather than trying to find the "one right way", since there is no one right way for every situation. Every solution has trade-offs. They might be acceptable for one situation, but they won't be for another.
@@IAmTimCorey you are right, but i mean: why every click sent to server and re receive action result as example: when i need to showing alert or confirm message i must return to server to this action executed, or i must create java script linked file to invoke this action locally
Blazor is DOA. I wouldn't waste time becoming a Blazor expert. Only a few Microsoft shops will use it. It's like WPA and WFF. It doesn't make anything easier. More importantly, there's no compelling reason to use it. Widely adopted frameworks already exist that fill the need for this tool. It just complicates things. Those of us who code close to the metal know that this is a one-off developed for a few corporate clients.
OK, there is a LOT to unpack here. Basically, this sounds like a sheltered perspective, where this advice works for your limited experience in one or maybe two businesses. So let's break it down. "Only a few Microsoft shops will use (Blazor)" - Nope. It is rather popular. Microsoft is a business. They make decisions based upon where they want to be and what their customers want (a combination of both). That is why, for example, WinForms is still around and is, in fact, being improved at a much faster rate than WPF. The customer base really wanted WinForms because that is what they were used to. Microsoft tried to push WPF, then UWP, then WinUI, but two out of the three of those are deprecated and WPF is taking a lesser role. So when it comes to Blazor, Microsoft isn't just adding it as an option. They are positioning it as the primary option. Look at .NET 8. They have expanded Blazor so much that half of the new announcements for .NET 8 are about Blazor. That's because Microsoft has seen the adoption from the industry and because they know they have a winner on their hands. "It doesn't make anything easier" - I would recommend you actually use Blazor. I did a course where I built web applications in all five web project types (Blazor Server, Blazor WebAssembly, Razor Pages, MVC, and API). Blazor is by far the easiest to get up and running. Now with .NET 8, we get Blazor Server-Side Rendered, which basically replaces the need for MVC and Razor Pages. But not only does it just replace them, it also has the ability to turn on the client-side rendering for specific controls as needed. That means that you can have a powerful, fast site that can also perform client-side interactivity when it needs to (and it can "fake" it on its own as well by doing partial page refreshes). "there's no compelling reason to use it" - Again, no. If you are building a C# back-end, and you want to add a front-end client-side web application to it, now you can directly call your back-end libraries with a client-side C# application. The alternative (your widely adopted frameworks), which would be Angular, React, or Vue, means you need to now build a separate UI in a JavaScript framework, you need to add npm (instead of continuing to use NuGet), you need to add a build process beyond what you are doing for your back-end, and your developers need to context-switch between languages. "those of us who code close to the metal" - I don't know if you even know what that means. First, web applications aren't "close to the metal". They are, by definition, and application running inside another application across the web. That's about as far away from the "metal" as possible. The closest you can get "to the metal" would be a server-side rendered web application, since it relies on the server to create the page before transmitting it, making it as efficient as possible. That's what Blazor will do in .NET 8 and none of the JavaScript frameworks can do that. But let's talk performance. If you really want performance, you don't want to use a client-side application. They are objectively slow. The efficiency comes from the fact that each client is doing their own work (instead of the server doing the work for everyone). If you want efficiency while still having a rich client-side interaction, use Blazor Server since it is server-side rendered and then uses a small web socket connection back to the server to get just the updates it needs. All of the work gets done on the server, so you have that server-side speed but the client experiences the rich interactivity. "a one-off developed for a few corporate clients" - I would recommend that you take another look. For example, the Stack Overflow survey for 2023 listed ASP.NET Core developers at 18% with Blazor Developers at 5%. That seems small, but there are two things to note here - first, you can't do Blazor without ASP.NET Core, so based upon those numbers, 1 out of 3 C# web developers use Blazor. Second, Blazor is a newer technology. Companies always hold off on adopting a new, untested technology for a bit. That is especially true in the C# space, where people are still using the .NET Framework. So, with an overall 5% adoption rate and approximately 1 out of 3 C# developers using it professionally, that indicates that Blazor definitely isn't just for a few corporate clients.
The difference is that Google created Angular and Meta created React. Microsoft didn't create Vue. They created Blazor. Which makes sense because that's their language and their way of doing things. Besides, that wouldn't solve anything to just take over Vue. Vue is a third way to use JavaScript to create a rich, client-side application. Blazor is the best way to create a rich, client-side application using C# (a language a lot of us are already using for back-end development).
Not sure what shops you are talking to, but a lot definitely are. That’s why Microsoft is investing so heavily into it. They base those decisions on the numbers.
Nope. I covered the Silverlight myth in this video: th-cam.com/video/uH3z0ja7qfE/w-d-xo.htmlsi=9rLjGgjF-YZ9AEqZ What you are doing is comparing apples to oranges. What do UWP and Silverlight have in common? They are proprietary technology that only works if the underlying system supports it. Silverlight relied on the browsers to support the plug-in. UWP relies on a specific version of Windows. What is different about Blazor? With Blazor, there is nothing proprietary needed. It is open-source software built on web standards. As for MAUI, it too is not dead. Microsoft just started developing it recently. They are still working on the major bug fixes for .NET 8. I can understand being cautious about products, but there's a difference between being cautious and making poor decisions.
@@IAmTimCorey In 3 yrs there won’t be any Blazor or Maui. Just like SL and Xamarin. I said the same thing for SL 3 yrs before it died. I even had a bet with a weak software engineering manager. And I won :) The current reality and the foreseeable future is html, css and js. Everything else is only internal enterprise garbage.
Did you actually watch the above video? Because you are still comparing apples to oranges. Also, Xamarin isn't dead - they renamed it .NET MAUI when they merged it with .NET 6. That's like saying that .NET 5 is dead. Technically, that's true, but it is because .NET 6 and .NET 7 replaced it. As for the fact that "everything else is only internal enterprise garbage", do you know how much software development goes into internal enterprise software? A LOT! That's like saying all housing construction is single family homes except for those apartment buildings.
@@hero3616 You support your argument on bets and gut feelings? You are relying on past experience , which is understandable, but kind of weak as an argument.
Not filler. An answer to a question. A course on .NET 8 would be premature, since it isn't done yet and there will be major breaking changes over the next few months.
Remember 1 thing, Javascript is the BOSS of Client Side Applications. Blazor is nowhere near that. I am writing this comment once again after 5-6 years on another Blazor video.
JavaScript is the most common tool for client-side interactivity for sure. However, that doesn't mean that there isn't room for other options. That's like saying you love your screwdriver, so there is no need for other tools in the toolbox. If you are a C# developer, using the same language to get similar results compared to using a different language is a big deal.
Always think about this question: "What is Microsoft trying to sell?" - Here, the answer is Web Services. Cloud server hosting. Because $$$ for subscriptions.
So their devious plan is to give you free Visual Studio, a free programming language, free resources such as NuGet packages to make development faster, and a free web application project type that makes developing easier to create powerful applications. They then make that programming language cross-platform so that you can deploy to cheap or free Linux web servers. Then they give you the ability to deploy to any web platform you want for free. Oh, and you can use GitHub (which Microsoft owns) to house your code for free (publicly or privately) and to deploy your code anywhere you want for free. Then they give you free (for life) resource on Azure if you want to go that route. All so that you might consider using their paid web services, which are priced competitively in the market? How exactly is that bad for you? Does it hurt you in some way? Do you expect them to operate as a charity? I mean, let's turn that around. Let's ask the question "Why do you show up to work?" My guess is because of the $$$$. Makes you think, huh?
Wait, so a pickup truck hauls materials? You mean like a tractor trailer? We already have that. Do you see the comparison? Let's just say you have a desktop application. You built a WinForms application (it feels like that would be your choice). Now you need to get it into the hands of your users. How do you do that? Well, you probably package it into an MSI file. But then you need to figure out how to get it to your user. So, you create a website to download it from. Cool. Now your users download your installer, run it, and...they don't have the right permissions. Your MSI needs admin permissions to run. But let's say you figure that out. Cool. Now you find a bug in your application. How do you get the bug fix to your users? You publish a new MSI file and you ask then to download it. Or maybe, you write some additional code or use a library to allow your application to be updated remotely. Now you need to host those updates on the server as well, but you have a working, installable application that can be updated. You could do all of that, or you could use a Blazor WebAssembly application and add a couple files (a manifest and a service worker). Done. Now your web application can also be installed by clicking a button from the web browser. It will stay updated automatically. Oh, and it deploys to Windows, Mac, Linux, iOS, Android, and basically anything else that supports browsers. You get a desktop icon and everything. That's way more than your WinForms app can do and with a MUCH easier distribution system (and without the permissions issues you had).
Avoid MAUI at all costs. You've been warned. Nothing is going to run everything, everywhere. Not. Gonna. Happen. If you do, I have a bridge I'd like to sell you. Cheap!
I'm wondering if you have just stopped interacting on the Internet for the past ten years. First, MAUI already runs in most places (Windows and Mac desktop, iOS, and Android). However, this isn't new technology (it is built upon Xamarin, which has been used for years). It also isn't the only technology that does this. Just in the C# realm there is Uno and Avalonia. They have been around for years and they even operate on more platforms (Linux and the Web). Outside of C#, there are a number of technologies that also do this (mostly in the JavaScript family). I built a cross-platform desktop and mobile app and had it published to the app stores a decade ago. So again, this is a really bad take.
Using Blazor since 2018... seeing how many changes and improvements have been made so far is amazing.
It is really impressive.
My company transisitioned all apps to blazor. All internal apps. I love it. Also, I am starting to see more blazor jobs.
Awesome! Thanks for sharing.
I get job requests through LinkedIn at least twice a week because of my blazor experience.
Thats amazing! I was hired to do Blazor at my current job. Seems like it is picking up. Exciting times!!
Did you use new blazor 8? Is it good enough for public apps?
I'm in New Zealand and also seeing more jobs being advertised. So glad I jump into learning Blazor 2 years ago.
The speed of the development of Blazor is going up is absolutely insane.
It really is incredible.
Yes, this is one of the first times where I had that reaction of "Wow, Microsoft really found a great thing here, I hope they continue investing in it" and they *did*! Usually when I get excited about something like this they end up abandoning it (like XNA Game Studio, for example).
More Blazor jobs are appearing in the UK market. I'm transitioning my company over to it from razor pages and mvc. The new 'united' version of Blazor solves the issues we've encountered, looking forward to it.
Great!
Hi, do you need a blazor dev? I am currently looking for a remote opportunity to work with blazor, perhaps even part-time or project-based I live in Buenos Aires, Argentina
Why moving from Razor Pages and MVC to Blazor?
@@oddikaro8236 It makes certain tasks much easier, eliminating 'bridging' code between C# and JS. Complex data editing forms are much simpler to program in Blazor.
You are using net 8 preview?
"Stream Rendering" is another great feature coming in dotnet 8 Blazor. It allows the pages to render with the placeholder content while the long running async tasks are running. When the tasks are completed , the new content can be streamed to the client on the same response connection and then patched by blazor into the DOM. How cool is that !! With the goods of both server and client side rendering, I think Blazor is moving towards right direction to become a full stack web development framework.
That is really cool.
Is that something like hydration?
We use Blazor WASM (.NET7) in production and while it was frustrating not being able to use a lot of the JavaScript features right off the bat without interop at first, but as I've learned more about coding the client side in C# (I was not a .NET developer before working in Blazor, I came from Vue, React, Angular) I am now in love with leveraging the power of Visual Studio, C#, and the suite of great Microsoft tooling for devs. State management and event handling throughout the application is so nice.
We went with it for our latest project in my team, mostly only by the fact that it's very friendly for pure back-end developers, we have a lot of people in the team that haven't worked in React which some of our older applications use and it's super easy for them to learn the front-end parts of Blazor and get developing so much faster.
Thank you, Tim, for your videos. Right now, we are migrating the front-end of our solutions to Blazor WebAssembly and Blazor MAUI for their simplicity and versatility.
Awesome!
Blazor looks amazing (I loathe and despise Javascript, but I love C#, so Blazor is right up my street), but I've struggled to find good resources to help pick it up. Most of it seems aimed at absolute beginners but once you get past a hello world page, or a page with a counter on it, there seems to be a gulf to how to put that into practice - proper learning resources that really show you how to use it at the scale of a realistic website. (How to organise stuff, tooling with R#, that kind of thing).
I have a playlist on this channel for the Suggestion App. We use Blazor to build a full web application that is actually in production today at suggestions.iamtimcorey.com I also have a course on Blazor Server and I'm developing a new course for the new parts of Blazor in .NET 8.
@@IAmTimCorey- My friend, that is NOT a "full web application". It's one step above Hello World! I could write that in a day or so. NOT anything LIKE a full on production application. Total bullshit.
I have 3 projects currently running with Blazor. They work perfectly. It allowed me to be able to develop Fullstack in Net Core in a much easier and more productive way. And each update grows in potentiality.
Awesome! Thanks for sharing.
Can I see those projects? Im currently learning to develop web apps with blazon
never liked MVC, first time I tried Blazor I was hooked, great, fast platform to develop. Finally something great again!
I'm pretty much in the same boat.
I wrote my first major web app for our college in early 2018. It had a .NET Core back end and an Angular front end. As soon as Blazor was released, I rewrote the whole thing and ditched the Javascript side of things as quickly as I could! Been using Blazor to build pretty much every web app since, and until something better comes along, I don't see myself switching away. I just like having everything written in a single language. I don't like having to switch between C# and Javascript (or Typescript). It just makes maintenance more complicated.
Having said that, I built that web app in my very early days of developing full apps, and used a horribly, unnecessarily complicated multi-layered project structure which has also resulted in an app that's still horrible to maintain, so I'm just waiting for a bit of breathing space in work to redevelop it using the knowledge I've gained in the past 4 or 5 years to make it a lot simpler. But you know what businesses can be like - if it's working, there's no incentive to change things just to make *my* life easier...
Thanks for sharing!
I'm thrilled to hear this! I absolutely love Blazor!
Great!
We started a very big project in .NET 7, we invested a lot of time in research to choose the web part, blazor was our preference, but still due to the lack of good components and doubts about its future we opted for React, but if you doubt me I I preferred Blazor. I participate in another project, this one is less important, but it is being done in Blazor Server and it is going very well and we have another project, another company that is already in production, also in Blazor Server and for now everything is working very well. .
We had the same issue. Our UI guy and the client agreed on totally different UI which no third-party component libraries would match the outcome, so had to write our own components in order to match the UI/UX and the project we are doing is insanely big in Blazor Server.
Great!
The SignalR tech and the ability for the web application to 'transition from online to offline' capability is making me reconsider. 'Always online' is problematic and I am happy to see movement towards addressing this. Having a 'JavaScript Shop' is pretty nice too as so many solutions are available at your fingertips.
I'm glad you are going to enjoy those new features.
After the bit of an rocky start with alot of stuff being "preview" and constant breaking changes, the blazor development has really stepped up the game. I'm so glad i pushed my workplace into the direction of "this new emerging technology called blazor" back in the day instead of becoming yet another node+vue/react/svelte/angular/... shop. Life is so much easier now.
Thanks for the video. Eagerly waiting to update all of our Blazor apps to .NET 8 -time and using all the new cool features.
You are welcome.
My company has started building all new front ends with blazor and migrating old angular js stuff over, i’m loving it as a dotnet developer!
Awesome! Glad you are enjoying it.
I haven't used blazor, but I will be starting a new job that uses it for newer applications, so this is good information to hear. I much prefer coding things with C# over JavaScript, so I'm excited to try it out.
Great!
This is a great video! You should definitely cover more of these changes and capabilities when they are in production!
I'm glad you liked it.
I use Blazor for some personal projects. I occasionally need to use the JS interop for things Blazor doesn't support but I presume such occasions will become less frequent as Blazor becomes more feature rich.
What are those things you need the js interop?
I think that will be the case, but I also thing that the interop will always be important since there is such a large set of JavaScript libraries that are available.
Is it complicated to use js Interop? How's the developer experience.
@@BarriDuty: In my case "Caroussel component" like Owl Slider. There is no carousel component in blazor :(
@@Feronom i would say it's pretty easy to use. the conversions happen pretty much automatically by the interop in both directions. the only thing i found slightly awkward is needing to have the JS functions i want to call, defined or referenced in the Layout. i think there is even a (compiler?) warning in Visual Studio if you put it in the content (a page component). maybe it has something to do with it being an SPA
My first and current job as a c# developer is developing client-side apps with Blazor, love it
Excellent!
Can we connect?
In enterprise software ive found that you cant build a Blazor site using only C# for most serious projects. So far there has always been reasons that I have to reluctantly use javascript in the Blazor project as well. Most recently because a 3rd party plugins the comp I work for uses, can only be used with Javascript.
Javascript is just still too ubiquitous on the web to get away from. That being said, I hope Blazor gets more adoption and get extended as a tool and libraries. Its amazing to work with for someone with C# exp!
It depends on if you use the control libraries or not, but I also don't see an issue occasionally dropping into JavaScript when necessary. It allows us to utilize the extremely large marketplace of existing libraries while mostly sticking with C#.
It's interesting to see a lot of the larger community talking about server side rendering and/or failure at being "full stack". It plays right into Blazor's hands. The biggest problem MSFT faces is that many developers, even dotnet developers, refuse to see dotnet as a web front end environment. Of course, the rise of SPA frameworks had a lot to do with this. For me, I've also raised an eyebrow at SPA. Client side code made sense to me, when it made sense. It's the classic "It depends" but there were many times I felt like some reasons for client side code was merely "because I want it that way" over an actual engineering decision.
I appreciate that you said "Every tool has a purpose, and not every tool fits a job." Well said and I advise everyone watching to take this approach when considering your choices.
Yeah, making the right choice for the right situation is incredibly important. It is also the reason why experience in the industry is important. After you've been burned a few times, you learn to make better choices. The thing I like about Blazor in .NET 8 is that it will allow you to mix and match what you need on a per-page basis rather than on a per-site basis. That means I can do server-side rendering (SSR) for the static pages, and just bring in the SPA-like features on pages where interaction is needed.
Just wait until the new sustainability reporting requirements that comes in 2024. SPA er dead and so are Blazor.
What I really misses about Blazor are UI Components.
JavaScript has a rich set of DatePicket, DateTable and so on but this is not the case for blazor.
And I miss great tutorials to start with blazor. When you read about Blazor it's always about the rendering. Ok I got it. But what's next?
I'm used to get my data over Ajax from my WebApi. In Blazor I can get it directly from DbContext (EF).
What if I want to continue with the WebApi? What is best practice there?
Another big issue I found is the behaviour for submitting a form back to the server. It offers a DataAnnotation and ... but how can I write my own UI Components?
The Edit form is for demo purposes only. And I don't want to use DataAnnotations but FluentValidation instead.
Maybe I have a case where I want to show the user what he filled is invalid but in the same way save it in the database because I don't want the data loss.
yeah. i totally recognize those problems, but i found solutions to them. hopefully these rough edges will get worked out at some point.
i also missed UI components. but Microsoft did actually make some UI Components called "Fluent UI Web Components" (i found out by reading their reactions on their blog as many complained). which are basically the controls used in MS Teams. but i think they are still working on a DatePicker (it has a git repo and the developers are on the Discord server mentioned in the microsoft documentation). for date i went with the builtin InputDate Form control, which translates to the browser's standard date picker, and i bound it to a nullable DateOnly value. and i guess there are also lots of third part controls.
i also encountered the same problem as you with the default behavior of form validation. you can actually change that by subscribing to the Form's OnSubmit event (which is always triggered) and not registering to the OnValidSubmit event (which causes validation). i use this to do custom validation. in my custom validation i manually get the DataAnnotations validation results with Validator.TryValidateObject and do my own validations (you could also save to the database). then afterwards with the result, i set the validation messages using the EditContext's ValidationMessageStore. i havent used FluentValdation though, as i try to avoid third party stuff.
hopefully this helps
Those fluid UI Blazor components are very good. Thanks man!@@xybersurfer
I love blazor, its so easy to understand
I agree.
I was s heavily invested in Silverlight back in the day, but I have t admit, Blazer needs to catch fire very soon or it will fall through the cracks....2023 was meant t be the year Blazor took off!!!
If you read through the comments, I think you will find that it has taken off. Trying to identify what has "taken off" really does depend on the area as well as how they are advertising. Don't forget that an ASP.NET Core job could be building Blazor or MVC or it could be MVC now but switching over to Blazor.
I really like blazor, I'm migrating several applications to blazor server. And I'm developing a new project this year here in mexico related to financial system, I hope to launch in production at the end of the year. Thanks Tim for your tips.
Sounds great!
I'm pretty sure C# will be the most used language in future.
Microsoft hard working on it to provide well documentation.
Docs are really well
The documentation is so much better than it was and they continue to make improvements.
At my job, I replaced a hybrid Windows Service and Xamarin enterprise application with a Blazor Server-Side (SignalR) single code base solution using MudBlazor, Dapper and I loved the experience. The beta testers all like it better than the old pure Mobile app and having to deal with deploying, etc.
Thanks for sharing!
Been developing in Blazor, WASM and now hybrid and MAUI. Absolutely love it. This is from a former angularjs/angular developer. Never again.
Thanks for sharing!
Went through Angular, Vue, React, Svelte. Having high hopes for Blazor as it now puts everything together. Can't wait for dotnet 8
Great!
Something people don't talk about is just how much time you need to dedicate to maintenance of Vue, React, Svelte. Every week something new comes out and the old thing just gets dropped completely. And if you have security scanner you have to update when a venerability comes out. Angular is much better here but still not even close to dotnet. I worked with React on a project for a few years now and the amount of work we spent on switching from classes to functions, updating libraries that switched to hooks, dealing with React script, changing enzyme to RTL... is insane. It's like every week you have to do something. Also recommendation on what is best practice changes constantly and you constantly need to make decisions on code reviews should you allow a new style because everyone is recommending it.
@@FilipCordas Interesting point
@@FilipCordas
In the dotnet area you have also the evolving aspect of the language. Some simple examples: check if something is null can be done in a lot of ways; to create an empty string can be done as far as I know in two different ways
@@PeteStyla Sure I know a lot of ways to check for null in c# (f# doesn't have null) but all ways are backwards compatible and are garantied they will never be dropped so your code will run on new versions of dotnet. The big issue with dotnet was when they added multiplatform support and some windows dependent features didn't work but that issue doesn't exist with projects started after 2013 or so. I updated from all versions since core 1 and didn't have many issues unless something specific that was easily resolved. But you can also stay on older versions since you still get security updates for almost everything people still use web forms from 20 years ago and you usually update quickly.
I have been Blazor since it was 6 months old. Its improving.
More and more companies are going full cross-platform from WinForms either with Blazor or Avalonia.
It is definitely growing. .NET 8 will be an even bigger jump.
My personal idea is Microsoft should more focus on improving Blazor to compete with other SPA frameworks rather than making it another MVC/PHP kinda thing. Doing so, it can fills the gap between frontend and backend developers and all the developers can work as fullstack developers. Blazor WA already have great features such as interacting with native assemblies, JS interoperability...etc. In the other hand, sometimes Blazor server side gives more headache due to bi-directional communications are blocking by firewalls and API gateways of some enterprise architectures. Hope this wont end as another Silverlight.
It feels things change faster and faster, so the only thing the devs have time working on is upgrading frameworks and implementing new features instead of having a stable framework that doesnt change all the time.
As a developer the product owner only sees what the product does, not how the inner working are. So you seldom get the time to "improve code" without it coming with some new fantastic feature.
Just updating to the latest version of .NET will almost certainly make your app run faster with no additional changes. That alone is usually a good enough value to justify the upgrade time.
Thanks, I love Blazor, and even more with Syncfusion!!!
You are welcome.
From our experience, Syncfusion's tech (unresponsive) and sales support (unreasonable) were poor, so we switched to Telerik UI for Blazor and never looked back. However, the Syncfusion Blazor UI components themselves were fine.
@@maratnikitin4460 never heard about Telerik, ill look it up, thanks
Been using Blazor since Jan 2020. Was going to start with .NET 5 also but had to start with 3.1 as our deployment was on version 3.1. I regret not pushing for an update to 5.0 but on the other hand I got alot of knowledge about how Blazor works and creating ALOT of components myself as alot components simply did not exist like a simple radiobutton. I had to create my own which eventually became almost the same code as MS used when we finally upgraded our stack to .NET 6 and suddently I had a lot of naming conflicts with my components and they were called the same as the MS ones like the RadioButton component.
Thanks for sharing!
MyRadioButton
I like typescript, but not having to configure vite, and TS.configs and managing packages makes blazor really enjoyable for me. And Blazor hybrid is wicked smooth and easy with MAUI! I am more inclined to Blazor than Vue and React at this point, however lots of things only have js/ts clients and SDKs though so that often influences my decision to use a JS framework. Note I only have experience with Blazor wasm/hybrid so haven't experienced the ssr dx
Thanks for sharing!
I'm glad to hear to MS keep on doing Blazor improvements, as I've been working with that for some years. Blazor does have some inherent problems though.
Server side rendering doesn't scale great on more complex pages and it is easily eating up server resources, and does require that connection to be solid.
And client side Blazor (wasm) quickly gets very big if your project is more complex - so it has a very slow first load time.
So the lure of C# on the web is nice, but I am not sure it will survive the test of time really. The 4 or 5 or however many load modes now coming is just a way to work around those core issues, not something a developer really wants to deal with.
All valid issues but for the client wasm slightly over estimated in general due to user error, as in most folks don't pay any attention at all to the compiler options, you can squeeze stuff mightily and drop stuff that is only theoretically ever called. Decorating your methods with proper attributes also helps the compiler quite a bit.
I think the biggest confusion with WASM is on who is to blame for large client-side projects. Sure, WASM will be slightly larger than a JavaScript framework at the beginning because of the runtime. However, that's a minor difference and it doesn't grow with time. The only thing that grows is your code. So, the more you want to do on the front-end, the larger your app gets. That will be true no matter what language you choose.
As for Blazor Server eating up server resources, that again isn't really a Blazor issue. If your application is eating resources, debug and fix it. A Blazor Server project is no different than an MVC project or Razor Pages project when it comes to server-side except for the very small connection via SignalR. That connection doesn't eat resources when the app gets bigger. What would eat resources is if you either had an enormous number of connected clients (10,000+ at a time) or if you are transferring enormous amounts of data to the client all the time (selecting all rows of a table instead of limiting on the server, etc.)
The transition from Server to WASM at runtime will eliminate the slower load times and the need for constant connection, but it will still come down to writing good, efficient code.
Avalonia is also something to look at, especially if you're a wpf developer. It's a framework that let's you create multi platform apps incl webassembly.
Yep, and Uno.
Avalonia is great but has a huge drawback for any complex application. There are no UI frameworks that support it (Telerik, DevExpress, Syncfusion, etc.). Complex software generally requires one of these UI libraries.
@oddikaro8236 and does Blazor have the same drawbacks? I'm genuinely asking because I'm new to Blazor. In my applications, I never have had any real need for the third party frameworks you mentioned. If I needed a particular control, I just went on and created it myself.
@@chewingal2324 W.R.T. UI controls Blazor has support from big UI libraries (DevExpress, Syncfusion, etc.) and it also has open-sourced ones like MudBlazor and Radzen. So, in that regard it is really nice.
“What they do is what they mean” - that’s a great quote from Tim 😊
Thanks!
Everything I do uses Blazor now so it is bright :)
Great!
i haven't experienced a faster idea to concept framework than blazor server. i prefer blazor wasm, or another backend/frontend split, when moving from PoC to a fully production app, but blazor is ... blazingly fast.
It really is. That is a great use case for it.
I am using blazor since 2020 with blazor wasm... Lot more updations are available in each version and waiting for the blazor unified... In my opinion, blazor unified will remove the load issue, that is the only problem that we faced for our projects... Hope for the best....❤❤
I definitely think it will.
Thanks Tim for this input. One question, can I horizontally scale Blazor Server in kubernetes or openshift. What do I need to consider?
Yes, you can do that just like you would with any other site. Since the connection stays open with SignalR, you don't even need to worry about switching servers between calls. With that being said, I haven't done this myself so there may be something I'm missing but as far as I know, you should be set.
@@IAmTimCorey thank you Tim, I should try something in a month or so and keep you posted.
There are really good topics you touch on. Personally, I really think it's cool to be able to do something in javascript, but I just think it takes a really long time to get from A to Z to have something finished when it's not backend and frontend on the same platform. that's why I've switched from Nextjs to Kaste over Blazor Web.
Thank you!
Blazor was in an interview. It's a c# react, but there's good stuff there!
It is really good, especially if you are already using C# on the backend.
Without started watching full, Blazor is awesome and it is a future.
Great!
Is there actually any Blazor webapp created by MS?
Everyone speak about blazor feature but no one speaks about that signalR Connectivity, the signalR connections is it limited to some number? or azure signalr service may need to pay just to establish connectivity?
You can have thousands of concurrent connections with SignalR. How many depends on the resources of your server (RAM, mostly, I believe). My rule of thumb is to start thinking about offloading work to the Azure SignalR Service after I'm consistently getting 10,000+ connections at a time. Not per day, at one time. A decent server could probably go over 20,000 without an issue, but I like to have margin.
We in progress of porting the huge desktop app to web. Tried blazor. The performance test showed 6 times performance degradation. And it was simple algo..so, maybe it works for simple web pages... not for heave CAD apps. We continue researching.
Doing heavy CAD work in the browser is going to be extremely hard. There's a reason why CAD machines are typically more powerful than "normal" desktops. Think of the browser as either an under-powered computer or a thin client. If you do most of the work on the server, the browser can act as a thin client, just displaying the work the server did. The way to do that in C# would probably be Razor Pages or MVC. If you want to do a lot of work on the client (such as interacting with the drawing or creating drawings), the browser is an under-powered machine. The browser itself is an app running on a user's machine (of unknown specs). That app doesn't provide full access to the CPU, RAM, or video card. It translates your request through layers before sending it to the OS and then the hardware. There are a LOT of things in between your request and the hardware, and each of these slows you down. There are some things you can do to improve performance, but at the end of the day, a web app does not have access to nearly as many resources as a desktop app.
The ability to switch modes between Server and WebAssembly sounds like exactly what I’ve wished for for Blazor-but for a different purpose than you described. My dream is to be able to build a Blazor app that works in WebAssembly mode when an internet connection is unavailable (so it can work offline/as a PWA), but can switch to Server mode when online. Basically getting all the benefits of Server when online (like directly talk to DB, no API) but still be able to work offline. As far as we know would the runtime “mode switching” enable this kind of thing? Or will it be too limited/intended mainly for simple things like speeding up startup as was mentioned?
It can be daunting at first, but now I’m getting into it I love the component based page setup (which I guess is more Razor than Blazor), and still miss my session state from webforms and a lot of stuff that seemed more straightforward there, but I’m gonna stick with it, MS usually knows what they’re doing for developers.
State was nice until you had to work with load balancing. Then it got messy.
@@IAmTimCorey didn’t we have sticky load balancers for that?
Yeah, but that's problematic when you want to move people around, etc.
Genuine question, I love blazor and the easy way to build sites with it in c#. But I can't use it in production because both server and webassembly have one big issue... Webassembly has an initial loading time to download the JavaScript, putting a lot of end users off. Blazor server helps this, but if you switch tabs and reopen the site, the signal-R needs to reconnect... I'm really looking forward to the new feature to switch from Server side to Webassembly in .Net8!
Exactly, What Blazor United is Solving. I'm super excited
Yep, that's going to be a huge feature. I also like the ability to do server-side rendering for pages that don't need interactivity. That will slim down the app even more.
@@IAmTimCorey definitely agreed! Will you be making a video about this topic once it comes out?
This is the reason i didn't use Blazor till now , if this problem is going to be solved that would be amazing i will start learning and working on it seriously
Thank you Tim for this nice video.
I have been using Blazor for almost 1 year moving from MVC. However, there are somethings that I don't like in blazor such as could not accessing the DOM. I always feel like a prisoner. Do you think that Microsot will allow accessing the DOM in Blazor?
Blazor WebAssembly has no DOM access because WebAssembly has no DOM access. That's outside of Microsoft's control. However, usually you will find that there are ways around the need for direct DOM access.
Are the Blazor courses of yours I bought still relevant? Are you updating them with the changes?
Yes, they are, although they don't have the .NET 8 stuff. I did update them for .NET 6/7. I am considering doing a new course for Blazor in .NET 8, though, since so much will change.
According to the videos I have seen, the auto mode will only switch to Web Assembly on the next load of the website (basically browser cached the WASM version during the initial server-side app).
Correct, although I believe they want to improve this before launch.
Dammm, I missed the July sales thing, ;( i wanted to get the C# prove it bundle to polish up holes in my understanding, I finished 3 of your courses and random yt videos, My .NET education has been you (thank you so much), kudvenkat, raw coding and nick chapsas, and the books by Mark J Price. Now I am at a good place and was hoping to go through the bundle so I don't feel like all the time I dont know something.
I wish next time you put up a sale it's done like at the end or beginning of month, when ppl usually get monthly cheque. And still hoping for region based pricing ;( some other platforms already do this, When you get $2000 a month on a expensive to live poor country as a junior developer, its kind of hard, but definitely still worth it but I am still hoping for region based pricing.
Lastly, very cool video, really needed this, was literally wondering about where blazor is heading, especially in new projects as ms did not have a good track record before, but I think can trust now with the new approach with .NET core etc.
Very good video tim, like always. Deep with all details, thanks.
I have a question. What are the options for state management like redux in blazor?
thanks for your video, I have a question, if you are a c# person and want to improve your resume for better options in market, would you learn blasor or go for JS frameworks ?
Start with Blazor, so that you have better skills in your area of expertise. Then, expand out to a JavaScript framework.
Excellent explanation.
Thanks!
Hello Tim, Great video as usual. :-)
Is there an AI that can assist with CSS/html layout allowing you to add the blazor code behind it? (I suspect something like bootstrap templates.) If so, what AI do you advise and can you do a video on implementation? Thanks
GitHub Copilot X is a good option for writing code.
2:31 Just like Microsoft itself, for its UI's.
A little yes, a little no. Yes, they are still supporting WinForms, which was developed 20 years ago, but that's because that is what companies still wanted. No because we are talking about Blazor, a brand new UI that came out in just the past few years.
Is it more suited for enterprise apps not public facing ones with seo in mind.
No, it can do both.
If the render mode can be changed at runtime, I wonder if we could finally get rid of the "trying to reconnect" problem in Blazor Server apps that are idle for x amount of minutes. They really give a bad user experience.
That's going to be a big feature. You can change to WASM so you don't have to keep that connection alive.
Haven't used Blazor, but I've heard it has huge app file sizes (mb's) that result in long load and startup times. Are there any problems with that?
This concept is in regard to Blazor WebAssembly. I believe the .NET runtime that downloads (once) is around 1MB now. Any code you create will be added on top of that now. That's common for a WebAssembly application. 1MB sounds like a lot, but on the modern web it really isn't. For example, if you went to www.youtube.com and watched how much data is loaded, it will initially load about 12MB and then will load another 16MB (for a total of 28MB) in the background. That is just on the homepage on my desktop. I just loaded ESPN and it was 15MB. Stack Overflow is super-efficient (and has few images) and it is 3.7MB. The transfer rates will be about a third of those numbers (compression, etc.) Beyond that, you need to think of a Blazor WASM app as an application, not a website. Those are two different concepts.
This is only considering straight Blazor WebAssembly. If you use the new Blazor Web App, you can pick which parts are WASM and which are Server or SSR. You can get the most performances possible while using the least resources possible.
Finally, when it comes to long load times and long startup times, that again is going to come down to how you program your app. If your app is massive and has lots of blocking calls, yes, it could take a long time to load. If you develop it right, you will only have small, reasonable wait times.
We'd like your opinion on tRPC. It's the other way around - becoming a TypeScript full-stack developer rather than a C# full-stack developer.
It is definitely an option. What it comes down to is preference. You can be a full stack developer in a number of languages. The question is do you want to. Personally, I like JavaScript but I don't want to spend my career neck deep in it every day.
My company reverted 2 major apps when they realized that Blazor has no future and are to difficult to use if you require anything else than a demo application with a simple button and a dropdown.
Sounds like they made a mistake because of poor information. Blazor has a very bright future and it is one of the easiest frameworks to use, even for complicated tasks.
Hello Tim, Very nice video but i would like you to do the same after the .NET 8 release. What do you believe about the new template "Blazor Web App". Does Microsoft promote it over Blazor WebAssembly template? what is the future of Blazor (WebAssembly) from Microsoft POV.
I'll cover .NET 8 when it gets closer to release (November). The Blazor Web App template allows you to pick what parts of Blazor you want, including WebAssembly or Server. You can also choose SSR and then add Server or WebAssembly to just the pages/components that need it. Basically, instead of being forced into one box or another on creation, you can choose what fits best as you go and change that as needed. That's a great thing. WebAssembly is a big part of that.
@@IAmTimCorey My point is that companies have already invested in Blazor WASM. Changing to something else / changing to another architecture isn't that simple. Again, this new thing look promising, and from hobbyist perspective i like it... but i am a bit skeptical about Blazor WASM future.
Best channel for me)
Great!
I just about finish learning one thing and begin to become productive, then the next thing comes out and it's back to square one.
It shouldn't be back to square one. You should still be able to use the "old" thing in production. Businesses don't just use the latest and greatest thing.
Is there risk, that after few years, blazor will be another silverlight?
No. First, it is designed around web standards, not proprietary technology. Second, Silverlight is remembered for the wrong things: th-cam.com/video/uH3z0ja7qfE/w-d-xo.htmlsi=pmIJ278UZ3VV_PHJ
Thanks for the video
You are welcome.
I can feel in my bones that they will kill it.
So far they have.
Without a surface designer Blazor is a dead-end for LOB applications.
Surface designer? Do you mean a WYSIWYG designer? If so, that's not going to happen, nor does it need to. That's not how the web is developed. When you try to do WYSIWYG designers on the web, you get sites that are decent but not great. They typically are overly-verbose, hard to use for people using screen readers, and not great on all screen sizes. They have their place, but it isn't in custom development.
I'm a frontend / javascript developer, working in a company that uses awful, ancient, bloated, messy spaghetti code, no documentation, no code standards, a mix of .NET, jQuery, kendoJS, etc...
There's been some talk about new tech and rebuilding the whole thing from scratch... But since the backend is all .NET and most engineers here are C# programmers, it might end up being Blazor.
Even though it's new to me, the current one is so awful that I'm willing to learn it rather than keep hacking and complicating this monstrosity we're currently using.
Questions: is there something Blazor can't do that modern JS frameworks like React can? Can you recommend learning materials suitable for JS developers for learning Blazor / C# ?
Blazor is really powerful, and the limitations are shrinking away. For instance, right now Blazor Server needs to be always connected (SignalR connection to the server). That doesn't work for all environments. Blazor WebAssembly is offline capable (PWA) and is fully client-side like React, but the initial page load can be heavy (don't test it in development, though - that will be really slow because of debugging - test it after you deploy it). These limitations can be concerning for some applications, but with .NET 8 (coming in mid-November 2023), Blazor is going to eliminate most of these downsides. We will have the ability to switch from Blazor Server to Blazor WebAssembly so we get the fast page load and then the offline-capable fully client-side project after it is downloaded in the background. We will also get fully server-side rendered Blazor (SSR) for those pages that don't need client-side interactivity.
To top all of that off, you can still easily integrate any JavaScript library into your Blazor app, so you don't miss out on the rich ecosystem of tools, libraries, and frameworks that are available in JavaScript.
I think there are so many intuitive approaches & dev experience they could/should still adapt over from Remix/React. Coming from the other side, I see where they took inspiration from, but am slightly annoyed with their 'alternate' interpretations of what is in essence, the same thing (razor code vs TSX/JSX and their library) - there's no need to recreate the wheel from what is already very refined (and with good reason).
Razor syntax has been around for years, though. They were keeping their code compatible with the rest of ASP.NET Core.
My company is migrating everything from Blazor to Silverlight or Access 2.0.
Uhhh, what?
I was just trying to be funny! This technology is changing so fast, sometimes I long for simpler times!!!@@IAmTimCorey
lol I wasn't sure. You never know these days.
What strings are attached to the licensing?
None. You can make anything you want with it without attribution, etc. I don't believe you can take the Blazor source code and claim it as your own, but that's about it. Microsoft provides you the tools to build Blazor apps for free (Visual Studio 2022 Community Edition, Visual Studio for Mac, or VSCode). You can then sell that app or create a SaaS out of it and make tons of money off of it without restrictions. Basically, you can build a business for free using their tools and technology. Once your company makes $1,000,000/year or more, you will need to purchase a Visual Studio license, though.
Am I the only one who has issues debugging my Blazor Webassembly projects in visual studio community 2022 after updating from version 17.4.* to 17.6.*?
If im not the only one I just think its funny that Microsoft wants people to start using Blazor, while making it impossible for people to debug their projects for weeks.
Vaadin is something you should investigate
Thanks for sharing!
Well, I met with Blazor in MVC trying to create an uber super complicated form. It was very easy comparing jquery stuff. I already used Angular before and I knew how component-based development runs. I litteraly loved Blazor! It made me faster than I expected.
In the future I am planing to learn maui+blazor hybrid app to be full+full stack developer :D.
You are helping so much. Thank you for your videos.
where is component template how to :D
Ok, so I am on the hook. Anybody running an OpenSource Blazor Project I could contribute? Really would like to do something hands-on - but not alone in isolation. Anyone?
Tim - is a course due which will take us through learning this from scratch? (or at least from an olde Web Forms developer’s perspective) - or are you waiting for some stability in features yet?
I have the Blazor Server From Start to Finish course that covers Blazor Server only: www.iamtimcorey.com/courses/blazor-server-from-start-to-finish/
As for the other flavors, not yet but I will be adding courses for them.
@@IAmTimCoreyYup - got that one already - look forward to the others as they’re added
The new Blazor course covering .NET 8 and all of Blazor has launched: www.iamtimcorey.com/courses/blazor-from-start-to-finish
@@IAmTimCorey Sounds great - will definitely look at that 👍🏻
This sounds a lot like the latest iteration of Next.js
👩💻👩💻 Blazor must to be like angular, all logic tasks must be processed in the browser and limit connectivity for none needed server resources
It depends on what you are trying to say. Blazor WebAssembly does operate like Angular in that all of the source code runs on the client. However, if you are saying that should be the only way to do things, that's not correct. There are downsides to client-side applications. For example, you cannot do direct data access securely. You need to run through an API, which increases latency and requires an extra spot in your web server (2 sites instead of 1). You also have the issue of initial load time. There is a reason why server-side web development is still king on the web. WordPress, for example, is server-side rendered using PHP. The power and speed the server offers and the reduced bandwidth usage really makes an impact.
The key is to look at technologies as tools to be put in the toolbox rather than trying to find the "one right way", since there is no one right way for every situation. Every solution has trade-offs. They might be acceptable for one situation, but they won't be for another.
@@IAmTimCorey you are right, but i mean: why every click sent to server and re receive action result as example: when i need to showing alert or confirm message i must return to server to this action executed, or i must create java script linked file to invoke this action locally
Blazor is DOA. I wouldn't waste time becoming a Blazor expert. Only a few Microsoft shops will use it. It's like WPA and WFF. It doesn't make anything easier. More importantly, there's no compelling reason to use it. Widely adopted frameworks already exist that fill the need for this tool. It just complicates things. Those of us who code close to the metal know that this is a one-off developed for a few corporate clients.
OK, there is a LOT to unpack here. Basically, this sounds like a sheltered perspective, where this advice works for your limited experience in one or maybe two businesses. So let's break it down.
"Only a few Microsoft shops will use (Blazor)" - Nope. It is rather popular. Microsoft is a business. They make decisions based upon where they want to be and what their customers want (a combination of both). That is why, for example, WinForms is still around and is, in fact, being improved at a much faster rate than WPF. The customer base really wanted WinForms because that is what they were used to. Microsoft tried to push WPF, then UWP, then WinUI, but two out of the three of those are deprecated and WPF is taking a lesser role. So when it comes to Blazor, Microsoft isn't just adding it as an option. They are positioning it as the primary option. Look at .NET 8. They have expanded Blazor so much that half of the new announcements for .NET 8 are about Blazor. That's because Microsoft has seen the adoption from the industry and because they know they have a winner on their hands.
"It doesn't make anything easier" - I would recommend you actually use Blazor. I did a course where I built web applications in all five web project types (Blazor Server, Blazor WebAssembly, Razor Pages, MVC, and API). Blazor is by far the easiest to get up and running. Now with .NET 8, we get Blazor Server-Side Rendered, which basically replaces the need for MVC and Razor Pages. But not only does it just replace them, it also has the ability to turn on the client-side rendering for specific controls as needed. That means that you can have a powerful, fast site that can also perform client-side interactivity when it needs to (and it can "fake" it on its own as well by doing partial page refreshes).
"there's no compelling reason to use it" - Again, no. If you are building a C# back-end, and you want to add a front-end client-side web application to it, now you can directly call your back-end libraries with a client-side C# application. The alternative (your widely adopted frameworks), which would be Angular, React, or Vue, means you need to now build a separate UI in a JavaScript framework, you need to add npm (instead of continuing to use NuGet), you need to add a build process beyond what you are doing for your back-end, and your developers need to context-switch between languages.
"those of us who code close to the metal" - I don't know if you even know what that means. First, web applications aren't "close to the metal". They are, by definition, and application running inside another application across the web. That's about as far away from the "metal" as possible. The closest you can get "to the metal" would be a server-side rendered web application, since it relies on the server to create the page before transmitting it, making it as efficient as possible. That's what Blazor will do in .NET 8 and none of the JavaScript frameworks can do that. But let's talk performance. If you really want performance, you don't want to use a client-side application. They are objectively slow. The efficiency comes from the fact that each client is doing their own work (instead of the server doing the work for everyone). If you want efficiency while still having a rich client-side interaction, use Blazor Server since it is server-side rendered and then uses a small web socket connection back to the server to get just the updates it needs. All of the work gets done on the server, so you have that server-side speed but the client experiences the rich interactivity.
"a one-off developed for a few corporate clients" - I would recommend that you take another look. For example, the Stack Overflow survey for 2023 listed ASP.NET Core developers at 18% with Blazor Developers at 5%. That seems small, but there are two things to note here - first, you can't do Blazor without ASP.NET Core, so based upon those numbers, 1 out of 3 C# web developers use Blazor. Second, Blazor is a newer technology. Companies always hold off on adopting a new, untested technology for a bit. That is especially true in the C# space, where people are still using the .NET Framework. So, with an overall 5% adoption rate and approximately 1 out of 3 C# developers using it professionally, that indicates that Blazor definitely isn't just for a few corporate clients.
Angular belongs to Google, React is backed by Meta. I wish Microsoft takes Vue Js. But they won't because they want to promote Blazor!
The difference is that Google created Angular and Meta created React. Microsoft didn't create Vue. They created Blazor. Which makes sense because that's their language and their way of doing things. Besides, that wouldn't solve anything to just take over Vue. Vue is a third way to use JavaScript to create a rich, client-side application. Blazor is the best way to create a rich, client-side application using C# (a language a lot of us are already using for back-end development).
18:30
It doesn't even qualify as a passing fad. Not even .NET shops are adopting it.
Not sure what shops you are talking to, but a lot definitely are. That’s why Microsoft is investing so heavily into it. They base those decisions on the numbers.
Blazor and all similar stuff are dead. Learn Vue, or Angular, or React, or PHP they are MUCH better.
I'm not sure if you aren't experienced in the field or just aren't actually looking around, but that is clearly untrue.
React blows
Blazor is the next Silverlight or MAUI or UWP. Dead like them.
Nope. I covered the Silverlight myth in this video: th-cam.com/video/uH3z0ja7qfE/w-d-xo.htmlsi=9rLjGgjF-YZ9AEqZ
What you are doing is comparing apples to oranges. What do UWP and Silverlight have in common? They are proprietary technology that only works if the underlying system supports it. Silverlight relied on the browsers to support the plug-in. UWP relies on a specific version of Windows. What is different about Blazor? With Blazor, there is nothing proprietary needed. It is open-source software built on web standards.
As for MAUI, it too is not dead. Microsoft just started developing it recently. They are still working on the major bug fixes for .NET 8.
I can understand being cautious about products, but there's a difference between being cautious and making poor decisions.
@@IAmTimCorey In 3 yrs there won’t be any Blazor or Maui. Just like SL and Xamarin. I said the same thing for SL 3 yrs before it died. I even had a bet with a weak software engineering manager. And I won :) The current reality and the foreseeable future is html, css and js. Everything else is only internal enterprise garbage.
Did you actually watch the above video? Because you are still comparing apples to oranges. Also, Xamarin isn't dead - they renamed it .NET MAUI when they merged it with .NET 6. That's like saying that .NET 5 is dead. Technically, that's true, but it is because .NET 6 and .NET 7 replaced it. As for the fact that "everything else is only internal enterprise garbage", do you know how much software development goes into internal enterprise software? A LOT! That's like saying all housing construction is single family homes except for those apartment buildings.
@@hero3616 You support your argument on bets and gut feelings? You are relying on past experience , which is understandable, but kind of weak as an argument.
Blazor is future, mayby for you but not for me..
It doesn't have to be for everybody. That's the beauty of choice.
no jobs yet
There are many Blazor jobs. They might not be mentioned in the jobs in your area, but even then they are probably available.
@@IAmTimCorey no Blazor jobs in Hungary beleive me...
Filler, thought you were going to come out with a course Tim.
Not filler. An answer to a question. A course on .NET 8 would be premature, since it isn't done yet and there will be major breaking changes over the next few months.
Remember 1 thing, Javascript is the BOSS of Client Side Applications. Blazor is nowhere near that. I am writing this comment once again after 5-6 years on another Blazor video.
JavaScript is the most common tool for client-side interactivity for sure. However, that doesn't mean that there isn't room for other options. That's like saying you love your screwdriver, so there is no need for other tools in the toolbox. If you are a C# developer, using the same language to get similar results compared to using a different language is a big deal.
Yes, you are right!! From the perspective of C# developers, its a good option.
Always think about this question: "What is Microsoft trying to sell?" - Here, the answer is Web Services. Cloud server hosting. Because $$$ for subscriptions.
So their devious plan is to give you free Visual Studio, a free programming language, free resources such as NuGet packages to make development faster, and a free web application project type that makes developing easier to create powerful applications. They then make that programming language cross-platform so that you can deploy to cheap or free Linux web servers. Then they give you the ability to deploy to any web platform you want for free. Oh, and you can use GitHub (which Microsoft owns) to house your code for free (publicly or privately) and to deploy your code anywhere you want for free. Then they give you free (for life) resource on Azure if you want to go that route. All so that you might consider using their paid web services, which are priced competitively in the market? How exactly is that bad for you? Does it hurt you in some way? Do you expect them to operate as a charity? I mean, let's turn that around. Let's ask the question "Why do you show up to work?" My guess is because of the $$$$. Makes you think, huh?
If you're going to allow apps to run "offline" / disconnected... You mean like a desktop application? We already have that.
Wait, so a pickup truck hauls materials? You mean like a tractor trailer? We already have that. Do you see the comparison? Let's just say you have a desktop application. You built a WinForms application (it feels like that would be your choice). Now you need to get it into the hands of your users. How do you do that? Well, you probably package it into an MSI file. But then you need to figure out how to get it to your user. So, you create a website to download it from. Cool. Now your users download your installer, run it, and...they don't have the right permissions. Your MSI needs admin permissions to run. But let's say you figure that out. Cool. Now you find a bug in your application. How do you get the bug fix to your users? You publish a new MSI file and you ask then to download it. Or maybe, you write some additional code or use a library to allow your application to be updated remotely. Now you need to host those updates on the server as well, but you have a working, installable application that can be updated.
You could do all of that, or you could use a Blazor WebAssembly application and add a couple files (a manifest and a service worker). Done. Now your web application can also be installed by clicking a button from the web browser. It will stay updated automatically. Oh, and it deploys to Windows, Mac, Linux, iOS, Android, and basically anything else that supports browsers. You get a desktop icon and everything. That's way more than your WinForms app can do and with a MUCH easier distribution system (and without the permissions issues you had).
Thanks for this, my boss is going to sleep much better after seeing this 😂🎉
I’m glad.
Avoid MAUI at all costs. You've been warned. Nothing is going to run everything, everywhere. Not. Gonna. Happen. If you do, I have a bridge I'd like to sell you. Cheap!
I'm wondering if you have just stopped interacting on the Internet for the past ten years. First, MAUI already runs in most places (Windows and Mac desktop, iOS, and Android). However, this isn't new technology (it is built upon Xamarin, which has been used for years). It also isn't the only technology that does this. Just in the C# realm there is Uno and Avalonia. They have been around for years and they even operate on more platforms (Linux and the Web). Outside of C#, there are a number of technologies that also do this (mostly in the JavaScript family). I built a cross-platform desktop and mobile app and had it published to the app stores a decade ago. So again, this is a really bad take.