We use blazor in production and chose it specifically because our team gets many varying assignments. For maintenance, being able to go back 6 months or a year later and not have to relearn a language we haven't used since is a big win for us.
I’m a developer in a small team within a large company, primarily focused on building internal-use applications. We mostly work with C#. We’re slowly migrating older apps to web technologies. Initially, we started with MVC and JavaScript for the migrations, but I’ve recently rebuilt some of our apps using Blazor WASM. Honestly, I find it a much more enjoyable and productive experience compared to working with MVC and JS.
I was you about 4 years ago -- small team building primarily internal line of business apps in C#. All of our stuff was either web forms or MVC and .net framework 4.8. We made the decision to move to server side blazor starting with .net 5 and it's been great. We are a few years into it and just finished a .net 8 migration. Everything is better. We develop new features faster, the user experience is better, the performance is dramatically better. No regrets.
Yes Blazor is the perfect match for internal applications. Many years ago I wrote a app running on a Citrix server Blazor would have been perfect if it had been about all those years ago. Blazor is brilliant if you are a .Net site but don't have a sizable development team to use a mixture of technologies. Never forget one of Blazor 's real strength is code reuse. Blazor Server is also very secure since there are a few less things to consider over SPA applications. I love Blazor for writing browser based admin and data input applications that collect data that I push out to older MVC applications. I have used Angular with Laravel and Rails backend API's, but developing in just C# means I am so much more productive. I am only using JS when I cannot find a Blazor solution which was the case in the early days but is not so much now. If you have a strong Vue,, React or Angular team I don't think there is much in Blazor for you IMHO.
We've migrated all our React apps to the Blazor and React devs, never looked back. It was one the the best decisions I've made as an architect. Our use-case might be niche, but works very well in our context. Having said that, there is really nothing to disagree or to be mad about in Your first vid. I've been in touch with Steven and guys from MS product team, we might follow-up on our use case and publish a success story.
I think React is just too fast to develop in to ignore (for me). I can have an entire app done in days with the tooling available. Just as .NET is extremely well tooled for backend, React is the frontend tool I reach for when it matters most.
Blazor is amazing. We have worked with it for years, it speeds up development in more than 50%, faster ROI. No way we go back to Angular, React, nor Vue.
Really depends on what your company does. If you create internal apps/dashboards for customers with not a lot of concurrent users? Sure go Blazor. If you're building a complex product which requires rich UI & need a dedicated UI/Platform team, go anything JS (preferably react for easier hiring).
@@PticostaricaGS I would love to see sites which do that & change my opinion on Blazor (link some examples if you can). I believe you may be able to do that but I do not believe that your site would be as performant & done as fast or as well as a team with JS devs
@@PticostaricaGS no we've burnt our fingers with blazor. initially it was good but when app grows it starts to lag specially in wasm. server is good but when connection to server stops it hangs
Blazor addresses the challenge of enabling developers to build both the frontend and backend using the same language and toolchain. That's the problem it solves.
That is exactly it. And as long as it manages to solve the problem enough to be able to make a decent web application, that's enough for a whole lot of businesses. Especially when it comes to internal business applications, where functionality usually takes precedence over looks and being all shiny. Since Blazor is apparently not being used on notable (public) web sites, including Microsofts' own, I guess that 'making decent web applications' is currently the best that you can (reasonably) get out of it.
That isn't a real problem though. It is better to use a language suited to the domain than to force another language into the domain. The same way I would argue that anyone that uses JavaScript on the back end is a moron
@@mattymattffs Honestly, JS is quite polarizing for many engineers. Blazor is one of the few real, statically typed competitors out there. Competition needs time to develop, so honestly they should keep trying. That said the current state of things is not enough to make it a real option for larger projects, also it’s telling that Microsoft uses react for most of its websites.
Blazor is amazing! I've already built several medium-scale apps with it. While I'm not entirely sure about using Blazor Server for large-scale applications, Blazor WebAssembly combined with a Web API works perfectly. For real-time scenarios, you can easily integrate SignalR. If you're good in JavaScript, you can combine it with Blazor to overcome any limitations.
I fully support the statement. Also if you have an existing C# application and C# developers you can easily migrate to Blazor WebAssembly. I also have still have old .NET Framework 4.8 Code run behind the WebAPI that over time will be converted to .net core.
Honestly I disagree. It's a much better development experience having backend and frontend in one project solution and one language. You can just create a project with your DTOs and use the same classes in backend and frontend. This means you don't have to re-create your types in the frontend or use other tools or technology to create the types from your API schema or something. Also, this approach reduces dependencies and simplifies your tech stack. For many cases, Blazor gets the job done and there are great free UI frameworks like MudBlazor for example. I'm currently using .NET backend + Vue frontend in some projects, and Blazor in others, and honestly I wish I would have used Blazor in all of them. It's just a better experience and the end product is not better or worse with Blazor in my opinion
I have the same opinion. Sharing code between frontend and backend really simplifies development. I can have DTOs, Commands, Queries, Validators, Helpers shared across both sides.
I get where you're coming from, but it's a super leaky abstraction. You still have to learn all the web stuff like HTML and CSS, except you don't have as good tooling. MudBlazor is a dumpster fire - it looks terrible, is buggy and is ridiculously inaccessible. You can't even navigate a form or focus a button using the keyboard. I would be upset if I paid for professional web development and got something made with MudBlazor.
You are doing it wrong then. No problem. Mixing frontend and backend has never been a good idea and never will be though if you are a single person team it probably doesn’t matter 🤪 that being said if you’re using the right tools like openapi client generators and a vue frontend it will scale easily from a one person team to separate frontend/backend teams. Hell why would I ever care for the frontend as a backend developer 😉
Blazor at work, and in production. Ditched the Angular front-end along, which required waaay to complex setup to work as expected. 4 developers went from angry to happy. Not to mention the need to upgrade the Angular version every 6 month is you want to keep up with the Google train.
In Spain there is a boom with Blazor, many developers do not want to return to other technologies, what was done in 10 hours with other technologies with 1 in Blazor is enough and with more organized and clean code and only c sarp
Microsoft needs to eat it's own dog food. When anyone hears I use Blazor, the question is always - Is it ready for prime time? Is it enterprise ready? Microsoft needa to really push Blazor so companies know they can safely build enterprise apps with it and one way is if Microsoft uses themselves (a lot) and not just in some small projects here and there
This. So much. It's unbelievable how fast and simple things can be to implement, when you use a full-stack framework with an amazing language and ecosystem.
Senior dev with 15 years of experience here - I'd crawl over broken glass to use TypeScript and a proper frontend framework rather than take on the technical debt that is Blazor. It's such a Microsoft product, through and through, and that's not a compliment.
I'm a team leader in Moscow. I used Blazor not so long ago, together with the framework from telerik. The project was something like a personal terminal for applicants who came to the service center. It works on all devices, documents are displayed on it, you can put an electronic signature, a physical signature, and it integrates with the main EDMS.
Using Blazor WASM in production for years. It's a pleasure to use it, feels a lot like Vue 2. Now indeed I'm hoping Blazor will be successful and well adopted because as a Blazor developer I don't want to go back to this JS thing.
Using blazor wasm at work and at home. Can say it's much faster for prototyping and debugging. We moved from an angular front end with .net back end, and it's made life much simpler. Biggest plus is the sharing of models between front end and back end and no longer introducing buds because of property name typos
As a C# developer, I have not had a need to spend time learning React and Angular because of MVC and Razor pages and now Blazor. I love Blazor and what they are doing with it. There is not anything React and Angular developers are doing that I cannot do with Blazor. I think it has a user base just like all other languages.
I love Blazor and I'm working on a big project using it. It's the only technology I'm now looking at from Microsoft to the point that whole Aspire push was really annoying to me because I knew they were redirecting work force, partially from Blazor to some Aspire related thingies. If they push Blazor more and show that WASM can be trusted and extremely useful, this will lead to some major changes on Web technology stack.
I've just started playing with Aspire actually. It's an orchestration thing more than anything else. I've been using Blazor for several years now (and loving it). However, for my personal projects I use other stuff. I've just created a dotnet project with Aspire and added my api app (express) and ui app (react/next) and it was SO straightforward. Aspire both launches and stops my apps, and I can see their logs in there/etc. I'd say give it a try. I haven't added .net projects to it yet, but I can only imagine it would easier than node apps - being all Microsoft
Blazor is the GOAT! If you do C# web development and your company is a .NET shop. It's a no brainer! Productivity through the roof! I hope to see more interactivity added to Blazor SSR. That said, if you are not a MS shop, I think ANY MS development frameworks (and tech) have a huge uphill battle. I can't see foresee the open-source JS framework devs jump ship. I think the best we can hope for is the good ideas from Blazor make their way to the other popular frameworks (and vice versa). I agree 1000% MS needs to dog food it's frameworks. The frameworks will get the edge cases polish it needs. It also is a good showcase that they believe in what they "sell/push". If you a MS shop, give it a try on your next new project. You'll love it. Keep learning my friends!
We've used Blazor in multiple large scale projects after switching from Angular. We couldn't be happier. I think an argument against Blazor that I would agree with is SEO. If you need SEO friendly then maybe it's not for your needs. If you're building interactive applications, in my opinion it's fantastic. In particular with the current version the ability to render components statically, server side, or web assembly on a component level.
The ability to load the first time Server Side and as soon as it is all downloaded start using web assembly in the next loads out of the box is awesome to!😊
React and redux are way complex, next to Blazor. I dont believe react is the right tool for web, maybe blazor neither, but at least it is simpler and easier.
Feels a lot more like abandonware to me… I mostly enjoy the day to day of writing Blazor code, but there are some quite serious problems that prevent it being used in production on large scale apps. The GitHub issues have been open for years with little movement. With Blazor Server, the need for a constant connection to the backend means you have no way to deploy a new version of your app without disconnecting users and having them reconnect to a new instance that’s running the latest version of the code. There’s no practical way to rehydrate the server-side state on the new instance. That’s a BIG issue if your users won’t tolerate maintenance windows. Then you have a bunch of little annoying bugs that ruin productivity. Do you think that if you navigate to the same page you’re already on, but change the value of two route parameters, that your page would be re-rendered with both of the new values? Guess again. That happens sometimes, other times you get a render with one parameter changed, but not the other, followed by another render with the second parameter updated. Things like that are maddening because they’re seriously unintuitive and completely undocumented.
We use Balzor in production, but almost exclusively for internal applications. These are real applications that do some cool things, but they're not at hyperscale, and we are less concerned by design as we are by function.
I still don’t think Blazor is particularly useful in any web application, it kinda caters to developers who just don’t want to learn JavaScript, but after decades of JavaScript pretty much dominating the web market, I wonder how big that audience is. So I believe Blazor will be used mainly in some business apps that are mainly deployed in an intranet like LoB apps, and I don’t think we will see a public apps written in Blazor anytime soon, and by now we should have already seen one if it were to happen.
I've been developing for over 20 yrs and I actively avoided front-end work because I absolutely hate Javascript with a passion. Being a backend C# developer, Blazor has helped me bridge the gap and avoid a lot of the javascript nonsense; so for that, Blazor has been a god send
I work in a software factory placed in Argentina. We have been using Blazor for develop many backoffice apps. All of them successfully working on production with no problem.
I think blazor is great for making management portals, tools, and other internal use web applications for teams that don't focus on the web. If the usage of these web applications is limited, you can just put the application on a server and not worry about it. But yeah, i wouldn't put it on a public facing web application.
About Microsoft not using Blazor, I think Blazor is a perfect fit for non-sexy backend systems with a ton of CRUD, data processing and real-time interactive views, where SEO and every page loading in a millisecond are not priorities. So like an ERP system or a management system that have tons of features and whose users are experts making lots of queries and transactions. Blazor would be a terrible fit for a consumer app like Facebook.
@bravedeveloper Why so? I think it's more about choosing the right tool for the job. Personally I feel like Blazor is the most productive tool I have found so far, and it tends to make implementing features like the ones I mentioned like 10x faster, and there's no need for any glue code for client-server communication. But I happily use React or Next too if Blazor is not viable for a certain use case.
I really enjoy building in Blazor both for work and for personal projects. I really hope it does not die out and it gets more love from the dotnet team and wider adoption across Microsoft services.
Blazor is the best web UI technology of all time. It started at the top, and they’re only increasing their effort to make it even better. There’s no competition. Microsoft should embrace it more broadly, demonstrating greater commitment and leadership to set an example for the community.
Aspire uses Blazor, and it is getting a lot of investment from Microsoft. You shouldn't delete or produce content to appease the crowd, you should state your opinions and truth no matter what people think. Never delete videos because people are mad about it.
I don't agree with this take at all. Sure, Blazor doesn't solve a "problem" per se, but it's easier to use than react/vue/angular. Easier to use means fewer bugs and a quicker dev cycle. All wins in my book.
I don't agree with this. Just because Microsoft isn't advertising who is using it doesn't mean it's not being used. A lot of companies have put a lot of money and time into making components for Blazor, which to me shows there is a market and it is being used. Same with cloud providers now supporting signalR, they wouldn't bother if there wasn't a demand. It's a great product and much faster to use than the alternatives especially when you have to do server side things. I no longer have to write a front-end and an API.
In my team we have spent the last 2 years using Blazor WASM and pushing it way beyond SPA. Our whole team loves it. Sure there has been a lot of learning and libraries like Telerik are really lacking still, but its damn easy to make your own controls so meh!
I feel like your criticisms are a bit superficial. Why stick with popular technology rather than looking what the benefits are. We created an enterprise blazor application and one of the amazing things we were able to do is write once run anywhere. I wrote all our business logic and models that is shared between client and server. This lowers maintenence considerably, especially when you have to update your contracts after changing an api. Another thing is using a strongly type language like c# over Javascript yields way more benefits like offering compile time errors and is better performance as webassembly runs natively within the browser.
I find these assessments of the state of Blazor interesting that everyone only looks at Microsoft. After all the WASM format is an open standard and supported by all the popular languages. For me the bellwether is the state of the WASM standard as a whole and the other languages supporting it. If the feeling is that WASM isn't going anywhere, or the spec isn't iterating fast enough and it looses favor that way.
Thank you for the video. Blazor in production dev here. I love writing features with Blazor, but I also agree with your critiques. I’m also worried that people are ignoring the static rendered razor components, because they are so much better for creating a typical MVC app.
Blazor Framework is the best framework that Microsoft had released ever. Its perfect. Especially creating projects using Mudblazor. The production feels me a desktop application on the web. Brilliant!! No way to get back to any other frameworks!!
As a Line of Business developer, I've built an internal use app in Blazor, and coming from MVC I love that I don't need to write javascript to interact with the UI. I don't like that IDE integration with Rider is not optimal wrt hot reload. The variable naming is confusing, though dependency injection in Blazor9 in the code-behind file does help with this.
I've used Blazor in production since 2021, and I've come full circle back to React. Microsoft doesn't eat their own dogfood, and there are real pain points with Blazor that they just don't care about *because* they don't use it.
Blazor is great. I migrated a bunch of C# code from Windows Forms that I had been writing for the last 15 years. Finally, I didn't feel the need for another development tool. I can focus on solving business problems instead of learning other tools. To replace Blazor, something else would have to be significantly better. Like for example what Bitcoin is to money.
It is difficult to consider moving to Blazor when everything and everyone uses JS. In my opinion JS has major flaws and really should be superseded. But that’s incredibly difficult due to the inertia when it is so ubiquitous. Maybe Blazor is a bit ahead of its time in that regard. It’s solving a problem that there isn’t sufficient will to solve yet. If people are avoiding JS because they have only really worked with backend before… well maybe it’s an option, but you will be limited on what support you have and who you can hire. Even using Razor/MVC is somewhat an issue for as as design agencies are used to people working with React or low-code platforms.
Why learn react when you already know how to use c#? Life's too short to learn dozens of languages. Microsoft already gives you the tools and power to simplify things, why bother with 10 different technology stacks? I get it, .Net might not be always be the "right tool" (whatever the hell that means) for the job, but I think you should only consider using other technologies if the pros outweigh the cons just to get the job done, most of the time these advantages are negligible compared to the time it will take you to learn a new language or techstack. Ps: this is in a context where you need to build a product. If wanna just learn new things go ahead, i didn't say to put yourself in a c# box.
If you feel confortable with a technology is ok, but I don't think you will really lose anything learning other stuff. I can't simpatice with that mentality because that's how I feel how we end up stuck with the same thing and never improving.
I desperately hate to say this as it verges on gatekeeping, but as developers it behooves us to be able to cross language boundaries. And I don’t mean being able to write C# and VB/Java. If there is a real problem with the .NET ecosystem, it’s that it is too vast to properly understand without sacrificing the flexibility that the real world requires. Not to mention that other languages bring paradigms that can hugely change the way we consider our code, whether we use that language in production or not. Ignoring the lessons learned by other stacks is handicapping yourself.
You must learn and understand multiple languages. I wouldn't hire someone that puts themselves in a C# box. That's not the right mindset. Tech changes rapidly, and so should you.
The problem with Blazor and Razor, is that at some point you're going to need some rich html control like a chart or complex menu or whatever, and you're going to have to use javascript for it. Then you have two systems that are building UI. You may as well just embrace a framework like react/vue/angular etc.
@@Songfugel Much better with a framework build on standard like css, html. I have worked with silverlight and wpf and I hated SAML and the way styling was made. I have never been more productive, now that I use Blazor WASM and Telerik
React is so shitty compared to Blazor. I don't want to deal with all of the React rendering bullshit. In Blazor i can do both frontend and backend using my favourite technology .NET and C#.
@@iTakvim44 I tried React, Angular, Vue and Svelte. React is the worst to work with. I really like Svelte. Im open minded about all the tools for web development, but working in one language for both frontend and backend is great for me. I can share some code and there is no need for a context switching.
I'm working in company where we're building some automation software and blazor is our main technology. Our websites are technical: creating permits, monitoring gates, devices etc. And here blazor works as charm. Blazor speeded out dev time many times. So now we're more effective than using JS.
Last year I jumped on the hype train and worked on an Elixir Pheonix project which went really well. The scope was to push an MVP as a big team, so that afterwards only 1 - 2 devs can continue the work. But I have to say that current Blazor really feels better than Pheonix. I agree that it’s somewhat of a niche, maybe even because it is so common to have one FE and one BE team working on an MVP, but it’s still a super nice Fullstack experience
We use Blazor in production at Broadcom because of its high development velocity and ease of starting up. My own team has two Python/AI/data science folks with almost no programming experience outside of Python. They chose to do their front-ends in Blazor and backends in Python.
They coupled it wrong. They should've shipped C# in the browser, focused on minimize bundle size (they're huge), and just let people use React via interop.
Blazor is one of the most productive front end frameworks. My second weapon of choice would be Vaadin with Spring Framework. But Blazor iswsy more powerful once you get going. Static Server Side Rendering is my favorite.
The problem is that javascript is such a terrible language to maintain. All these libraries angular, react, vue... they change so often and sometimes with major implications. Now, if I change something in C#, immediately I can see where the errors are (granted using ReSharper), but with Javacsript, you can accidentally change a variable name and you will never know until someone reports a bug and you have to do a deep dive to find the issue. I honestly hate working with it, especially taking over someone elses javascript dogpile. Javascript is only as popular as it is because for the longest time, we had no other choice. I also don't understand why you say we should be average at everything. Being excellent at one thing is way better in my opinion. Obviously not to the extent that you are completely naive about anything else.
I really have to disagree. I've been a C# developer for 12 years and started with Blazor 2.5 years ago, after almost a year of unsuccessfully trying to gain a foothold in Angular. Javascript and Typescript work differently than C# in many areas and I still can't get to grips with them. On top of that, the constant context switching between JS for the frontend and C# in the backend is an absolute horror. I work alone and in 2.5 years I have now written 7 internal applications with Blazor and brought them up to production level. I would never have been able to do that with the switch to Angular, I would probably have spent half my day in forums and on RUclips. With Blazor, it took me maybe 6 weeks to get into it. With Angular, I would probably be just about ready to go live with my first application. This is of course my personal case, but I have met many C# developers in my career who give JS/TS a wide berth. For them, Blazor is a real blessing.
Месяц назад+10
Microsoft need to use it themself to get adoption, and still then it will be hard. Microsoft is using React and React Native on many projects, but almost never Blazor, MAUI or UWP/WinUI. The idea is fine, but it's for people who have a backend in C# and wants to make a frontend. It's not for people who wants to make a frontend with a C# backend.
Yes, this exactly. (I just left a comment saying the same). If I google 'NET Blazor/MAUI real world examples' there is almost nothing. And certainly nothing from MS. Almost every demo is a bootstrap weather app, or a note taking app, or a todo list. I know there's a podcast app and the Pizza Workshop demo (which were much better) I was toying between MAUI/React Native for an app. Wasn't sure which. Looked at both sites and seeing Instagram, Tesla and Microsoft Office in particular apps built with RN made it a very convincing argument. There was NOTHING for MAUI. And I have the same with Blazor. 'Simple to build with Blazor' is for a beginner tutorial, a complex application showing Blazors FULL potential is what will sell it to me
i love the way nick understands MS i cant understand their doucmenttion online but with people like nick make it easier for me so documentation is a huge problem for them
We use blazor in production for an ERP system, the desktop version of the app supports scripting via c# and vb and because of the coolness of WASM i can run Roslyn in browser to run my scripts.
We use blazor server-side and wasm in some enterprise apps. Quick easy and low maintenance cost. It is not designed for high traffic sites and that is fine. Devs are happy using it.
I feel like blazor is a good solution for companies that have a product that is written in C# and need some kind of frontend. IMO these days a web or maui hybrid UI is the easiest and most sustainable way to develop that, when then don't have any web developers on the team. For example when they develop many background services that only need some GUI to be configured, so the UI is not the focus but a necessary evil...
For a loose-coupled spa solutions you would still autogenerate your C# request/response models from backend to new frontend models. And whether the frontend models are C#, typescript, js, something-else really (for me at least) kills the advantages I thought having of not repeating code and rewrite domain-specific methods twice. So it really just comes down to what language and frontend framework you prefer (react, vue, angular, blazor)
In my team we use Blazor, because we've already know C# and it's amazing, the learning curve is very short. Instead of Angular when you start with a version and finalizes the project, you realized that already there are 3 major versions released and you have few time to learn the changes.
Balzor default project is admin panel, that is main use for it. We use it exactly for that in my company. Now we will make app for end users but it is for limited number of users our costumers.
Honestly, I hate anything that tries weirdly merging frontend and backend. Like Blazor or Next.js or similar. I prefer to have it completely separate, always. For development AND security purposes. For backend I always prefer the .NET Minimal API, it is amazing. As for frontend, I choose the tech based on my project: - Native HTML/CSS/JS for simple stuff - Svelte/React for more complex sites that will be reusing a lot of components - Avalonia for when I specifically need C# on frontend (usually when using certain C# only libraries...) or for cross-platform apps (it will perform a lot better than React) Even when I want C# on frontend I usually prefer Avalonia over Blazor because of how easy it is for me to develop cross-platform apps with nice animations (just like WPF but simpler). I don't know how Blazor is today, I used it back in .NET 7 and it was meh. Avalonia, on the other hand, has been amazing. Used it for 3 bigger apps already and loved it.
Blazor is still buggy and mostly undocumented (at least for the newer dotnet versions). You aren’t missing out on anything. I’m gonna give Avalonia a try, didn’t realize it was for web also.
Blazor Server is honestly great for an intranet app that doesn't need to worry about scaling. WASM and Hybrid have been gaining traction. While it's never going to get the marketshare that React or Angular (okay, or even Vue) have, it's still got a solid community. Your course numbers are a better metric than "number of mentions at NDC" (seriously who thinks that's representative?). Something to remember about how much they were pushing MAUI at NDC - think back to how much they were pushing Silverlight 13 years ago. MAUI is, at best, interesting. I would never bet the farm on a desktop UI technology from Microsoft given their history on that front, though. Blazor is what got me back into web development, and while it may not be the technology I use for my next public facing site, it definitely would be for an intranet based application. The reason it wasn't getting mentioned at NDC is (IMO) more down to the fact it's reached evolutionary status rather than revolutionary (i.e. unstable) status, which I feel MAUI is still in.
Blazor, as of ~8 months ago, hasn't scaled well. The previous company I worked for have had projects use Blazor on a few occasions. The experience had been that the project started out fine but as it was getting more fleshed out during development, and more was being asked of Blazor, the team would end up having to hack around Blazor due to performance issues. I don't think it has changed much since then but that was one of the big issues and why that company essentially told all of the dev teams that they can use it for proof of concepts but not for production.
Started a greenfield project using Blazor auto-render mode (server and wasm). Loving it! Will never go back to Angular. Although we are still maintaining a few legacy applications. As far as the point on talent pool being bigger in TS/JS vs c#, that may be true in terms of the quantity, but not sure about the quality. I find that everybody and their grandmother claims to be proficient in JS, but they are not.
One just don't use any tech from Microsoft that they are not dogfooding. Simple as that. Silverlight? WPF? WWF? F#? XNA? WinJs? WinRT? Blazor - next UWP - next WinUI - next MAUI - next
In the place I work, we have a lot of programs written in C# because these are many back services. But there are some interfaces we are developing and they were made with Angular. Now, we are migrating them to Blazor. There is a good reason for this and I think it is obvious: since a majority of C# skills is required, it is then easier for C# developers already in place to learn Blazor than Angular. It is less efforts. Otherwise we would had to recruit experts in Angular (done before but since then they went elsewhere).
"Tired of wrestling with JavaScript's quirks and cryptic errors? Join the Blazor revolution and let C# save the day! It's like trading in a rusty old bike for a shiny new electric scooter - smoother, faster, and way more fun!"
Company: We have written a tool that allows you to write everything in one language, and the toolchain will do the rest, you only have to write in one language. Devs: Use it all the way to production, and use it without thinking about why. Devs a few years later: We should not have done that... we should not have done that... we need to rewrite. Any system big enough that needs to actually be designed and thought about critically; this approach never works. Hire devs that think in more than one tech stack, you'll be better off on every metric there is to measure a team. Anything will ' work ' for any system small enough, but those systems should not be the reason something is 'good'.
I am a heavy Blazor user, and I must say that no longer imagine my work without it. - What it gives for me is a speed of development, ease of use, enabling developing both Front-End and Back-End using same language. - When it comes to big companies using Blazor: UiPath (leading RPA platform in world) Apps are built using Blazor. Point is that there are those use cases, but how will we know if it is not being communicated and/or we do not look for it? - Yes, SignalR disconnects are annoying, 100%. But ability to render Server side & Client side kind of helps here: yes, live chat can be rendered on server and can be disconnected, random wiki content can be rendered client side, and you won't get disconnect. It all comes to use cases.
I would say there are two kind of developer's thinking ways: frontend and backend. For first lager of developers is best JavaScript beacus of it "simplicity" (and as result, popularity). For others - JavaScript is unclear rudimental trash that should be replaces with strong typed language in future. P.S. majority is not always right and the simply solutions not frequently best.
I think Blazor or and other Web assemblies are going to be the technology in the next years. But I agree that it is not quite production ready. It has a huge overhead when downloading components which is bad for places with low speed internet like rural areas and countries that haven’t developed the high speed internet infrastructure. I think Microsoft needs to use it more in their own applications and we need to be more critical about Blazor so we can get it to be production ready.
To me the advantage of Blazor is that it allows you to share logic between the front and back end. For example, validation. It has also been my experience that most developers (I included) don’t have the mental bandwidth to be experts in multiple stacks simultaneously, making a “full stack” developer more of a unicorn than a reality. If you suddenly have a lot of back-end work, or a lot of front-end work, it can be hard to shift the resources. Sure, some people are “good enough” to do both, but those people who are “good enough” often require oversight, which is time and money, or they will make a right mess out of the application. The downside to Blazor is Microsoft. They have a proven track record of heralding some new “groundbreaking” technology, then dropping it like a rock. Windows Phone and Silverlight come to mind. I suspect the only reason Microsoft hasn’t dropped Blazor yet is because they know if they do, they will never be taken seriously in the UI space again; not that people take them too seriously now.
I am curious to know, are you not using Blazor because you are not doing any web gui stuff, or are you not using it because you prefer a different front-end framework (react...)?
You do not need Azure for SignalR connection. You're wrong here. If you're referring to scalability, then say so, but even then Blazor server works perfectly fine for small/medium apps.
@@nickchapsas That's a specific system constrain. Many apps are build just for the NA or EU (ie specific) region, so Blazor solution is perfectly fine and works just fine.
I remember commenting on this very issue in the original video. I think it could be @nickchapsas lack of understanding on SignalR. If you want to scale it, you can add a Azure SignalR managed solution, or even run your own. I don't know where he is getting his information from.
We use blazor in production and chose it specifically because our team gets many varying assignments. For maintenance, being able to go back 6 months or a year later and not have to relearn a language we haven't used since is a big win for us.
I’m a developer in a small team within a large company, primarily focused on building internal-use applications. We mostly work with C#. We’re slowly migrating older apps to web technologies. Initially, we started with MVC and JavaScript for the migrations, but I’ve recently rebuilt some of our apps using Blazor WASM. Honestly, I find it a much more enjoyable and productive experience compared to working with MVC and JS.
Thanks for insight, I was wondering if its used in pro environment and should I learn it.
Yeah same opinion on enjoyment here
I was you about 4 years ago -- small team building primarily internal line of business apps in C#. All of our stuff was either web forms or MVC and .net framework 4.8. We made the decision to move to server side blazor starting with .net 5 and it's been great. We are a few years into it and just finished a .net 8 migration. Everything is better. We develop new features faster, the user experience is better, the performance is dramatically better. No regrets.
Yes Blazor is the perfect match for internal applications. Many years ago I wrote a app running on a Citrix server Blazor would have been perfect if it had been about all those years ago. Blazor is brilliant if you are a .Net site but don't have a sizable development team to use a mixture of technologies. Never forget one of Blazor 's real strength is code reuse. Blazor Server is also very secure since there are a few less things to consider over SPA applications. I love Blazor for writing browser based admin and data input applications that collect data that I push out to older MVC applications. I have used Angular with Laravel and Rails backend API's, but developing in just C# means I am so much more productive. I am only using JS when I cannot find a Blazor solution which was the case in the early days but is not so much now. If you have a strong Vue,, React or Angular team I don't think there is much in Blazor for you IMHO.
I think part of that is that the MVC model is dumb
I look forward to the third instalment next year where Nick reviews Nick reviewing Nick.
That should then probably be in 4 years.
Yeah, this was a bit weird. Also the agreeing with yourself in amazement was a bit much. It was just a few years ago...
Nickception
And then we need to go deeper ;-)
If you say Nick three times does he suddenly appear behind you?
We've migrated all our React apps to the Blazor and React devs, never looked back. It was one the the best decisions I've made as an architect. Our use-case might be niche, but works very well in our context.
Having said that, there is really nothing to disagree or to be mad about in Your first vid.
I've been in touch with Steven and guys from MS product team, we might follow-up on our use case and publish a success story.
did you find any success with microfrontends with blazor?
I think React is just too fast to develop in to ignore (for me). I can have an entire app done in days with the tooling available. Just as .NET is extremely well tooled for backend, React is the frontend tool I reach for when it matters most.
Blazor is amazing. We have worked with it for years, it speeds up development in more than 50%, faster ROI. No way we go back to Angular, React, nor Vue.
Really depends on what your company does.
If you create internal apps/dashboards for customers with not a lot of concurrent users? Sure go Blazor.
If you're building a complex product which requires rich UI & need a dedicated UI/Platform team, go anything JS (preferably react for easier hiring).
@albatrossherifi2510 You can quickly and easily do that with Blazor, with no js, and still have tremendous performance.
@@PticostaricaGS I would love to see sites which do that & change my opinion on Blazor (link some examples if you can). I believe you may be able to do that but I do not believe that your site would be as performant & done as fast or as well as a team with JS devs
@@PticostaricaGS no we've burnt our fingers with blazor. initially it was good but when app grows it starts to lag specially in wasm. server is good but when connection to server stops it hangs
JS benchmarks show Blazor to be the slowest of them all. 5 times slower than vanilla js.I prefer Razor + HTMX =
Blazor addresses the challenge of enabling developers to build both the frontend and backend using the same language and toolchain. That's the problem it solves.
For c#... i mean NodeJS already existed.
That is exactly it. And as long as it manages to solve the problem enough to be able to make a decent web application, that's enough for a whole lot of businesses. Especially when it comes to internal business applications, where functionality usually takes precedence over looks and being all shiny.
Since Blazor is apparently not being used on notable (public) web sites, including Microsofts' own, I guess that 'making decent web applications' is currently the best that you can (reasonably) get out of it.
That isn't a real problem though. It is better to use a language suited to the domain than to force another language into the domain. The same way I would argue that anyone that uses JavaScript on the back end is a moron
@nicolaisattler1990 True, but I'm not touching JS with a ten foot pole when my career involves specialist roles with C#
@@mattymattffs Honestly, JS is quite polarizing for many engineers. Blazor is one of the few real, statically typed competitors out there. Competition needs time to develop, so honestly they should keep trying. That said the current state of things is not enough to make it a real option for larger projects, also it’s telling that Microsoft uses react for most of its websites.
Blazor is amazing! I've already built several medium-scale apps with it. While I'm not entirely sure about using Blazor Server for large-scale applications, Blazor WebAssembly combined with a Web API works perfectly. For real-time scenarios, you can easily integrate SignalR. If you're good in JavaScript, you can combine it with Blazor to overcome any limitations.
I fully support the statement. Also if you have an existing C# application and C# developers you can easily migrate to Blazor WebAssembly. I also have still have old .NET Framework 4.8 Code run behind the WebAPI that over time will be converted to .net core.
If you're good in JavaScript you use React / NEXT :)
@@ss5899which one you choose server , client or auto interactive ?
Honestly I disagree. It's a much better development experience having backend and frontend in one project solution and one language. You can just create a project with your DTOs and use the same classes in backend and frontend. This means you don't have to re-create your types in the frontend or use other tools or technology to create the types from your API schema or something.
Also, this approach reduces dependencies and simplifies your tech stack. For many cases, Blazor gets the job done and there are great free UI frameworks like MudBlazor for example.
I'm currently using .NET backend + Vue frontend in some projects, and Blazor in others, and honestly I wish I would have used Blazor in all of them. It's just a better experience and the end product is not better or worse with Blazor in my opinion
Thanks for insight :)
I have the same opinion. Sharing code between frontend and backend really simplifies development. I can have DTOs, Commands, Queries, Validators, Helpers shared across both sides.
I get where you're coming from, but it's a super leaky abstraction. You still have to learn all the web stuff like HTML and CSS, except you don't have as good tooling. MudBlazor is a dumpster fire - it looks terrible, is buggy and is ridiculously inaccessible. You can't even navigate a form or focus a button using the keyboard. I would be upset if I paid for professional web development and got something made with MudBlazor.
You are doing it wrong then. No problem. Mixing frontend and backend has never been a good idea and never will be though if you are a single person team it probably doesn’t matter 🤪 that being said if you’re using the right tools like openapi client generators and a vue frontend it will scale easily from a one person team to separate frontend/backend teams. Hell why would I ever care for the frontend as a backend developer 😉
@@camerascanfly There was a web before React, Angular, and Vue.
Blazor at work, and in production.
Ditched the Angular front-end along, which required waaay to complex setup to work as expected. 4 developers went from angry to happy.
Not to mention the need to upgrade the Angular version every 6 month is you want to keep up with the Google train.
In Spain there is a boom with Blazor, many developers do not want to return to other technologies, what was done in 10 hours with other technologies with 1 in Blazor is enough and with more organized and clean code and only c sarp
Microsoft needs to eat it's own dog food. When anyone hears I use Blazor, the question is always - Is it ready for prime time? Is it enterprise ready? Microsoft needa to really push Blazor so companies know they can safely build enterprise apps with it and one way is if Microsoft uses themselves (a lot) and not just in some small projects here and there
Blazor is amazing 🤩
Have coded in many JavaScript frameworks. What a waste of time
This. So much. It's unbelievable how fast and simple things can be to implement, when you use a full-stack framework with an amazing language and ecosystem.
I agree, waste of time, my experience as well.. Time = money
Senior dev with 15 years of experience here - I'd crawl over broken glass to use TypeScript and a proper frontend framework rather than take on the technical debt that is Blazor. It's such a Microsoft product, through and through, and that's not a compliment.
I'm a team leader in Moscow. I used Blazor not so long ago, together with the framework from telerik. The project was something like a personal terminal for applicants who came to the service center. It works on all devices, documents are displayed on it, you can put an electronic signature, a physical signature, and it integrates with the main EDMS.
Using Blazor WASM in production for years. It's a pleasure to use it, feels a lot like Vue 2.
Now indeed I'm hoping Blazor will be successful and well adopted because as a Blazor developer I don't want to go back to this JS thing.
But vue2 has a crappy component structure
We use blazor in production at work, mid size company. The reason being that the ecosystem is pretty good, dev workflow super fast and easy to learn.
Using blazor wasm at work and at home. Can say it's much faster for prototyping and debugging. We moved from an angular front end with .net back end, and it's made life much simpler. Biggest plus is the sharing of models between front end and back end and no longer introducing buds because of property name typos
As a C# developer, I have not had a need to spend time learning React and Angular because of MVC and Razor pages and now Blazor. I love Blazor and what they are doing with it.
There is not anything React and Angular developers are doing that I cannot do with Blazor. I think it has a user base just like all other languages.
I love Blazor and I'm working on a big project using it. It's the only technology I'm now looking at from Microsoft to the point that whole Aspire push was really annoying to me because I knew they were redirecting work force, partially from Blazor to some Aspire related thingies.
If they push Blazor more and show that WASM can be trusted and extremely useful, this will lead to some major changes on Web technology stack.
I've just started playing with Aspire actually. It's an orchestration thing more than anything else. I've been using Blazor for several years now (and loving it). However, for my personal projects I use other stuff. I've just created a dotnet project with Aspire and added my api app (express) and ui app (react/next) and it was SO straightforward. Aspire both launches and stops my apps, and I can see their logs in there/etc. I'd say give it a try. I haven't added .net projects to it yet, but I can only imagine it would easier than node apps - being all Microsoft
OMG, we lost him. Nick reacting to his own videos? It's like Limp Bizkit remixing their own songs.
😂😂😂
I would listen to a Limp Bizkit remix of a Limp Bizkit song though...
I'd like to see Fred Durst react to a Nick Chapsas video.
Blazor is the GOAT! If you do C# web development and your company is a .NET shop. It's a no brainer! Productivity through the roof! I hope to see more interactivity added to Blazor SSR.
That said, if you are not a MS shop, I think ANY MS development frameworks (and tech) have a huge uphill battle. I can't see foresee the open-source JS framework devs jump ship. I think the best we can hope for is the good ideas from Blazor make their way to the other popular frameworks (and vice versa).
I agree 1000% MS needs to dog food it's frameworks. The frameworks will get the edge cases polish it needs. It also is a good showcase that they believe in what they "sell/push".
If you a MS shop, give it a try on your next new project. You'll love it. Keep learning my friends!
We've used Blazor in multiple large scale projects after switching from Angular. We couldn't be happier. I think an argument against Blazor that I would agree with is SEO. If you need SEO friendly then maybe it's not for your needs. If you're building interactive applications, in my opinion it's fantastic. In particular with the current version the ability to render components statically, server side, or web assembly on a component level.
The ability to load the first time Server Side and as soon as it is all downloaded start using web assembly in the next loads out of the box is awesome to!😊
same as me.
switched some angular with poor typescript to blazor wasm.
From nightmare to paradise
All these UI frameworks to just put a record in a relational database 🤷♂
Right!? Oh - and the fashionable framework will change next week.
What are you using instead of Blazor nowadays, Nick?
He said React a few times.
React and redux are way complex, next to Blazor.
I dont believe react is the right tool for web, maybe blazor neither, but at least it is simpler and easier.
React + MobX superfast and super easy
Hot reload is improved and the initial load is faster now. It's moving in the right direction it seems
Did hot reload improve at all in .net 9? There was nothing in the release notes.
Feels a lot more like abandonware to me…
I mostly enjoy the day to day of writing Blazor code, but there are some quite serious problems that prevent it being used in production on large scale apps. The GitHub issues have been open for years with little movement.
With Blazor Server, the need for a constant connection to the backend means you have no way to deploy a new version of your app without disconnecting users and having them reconnect to a new instance that’s running the latest version of the code.
There’s no practical way to rehydrate the server-side state on the new instance.
That’s a BIG issue if your users won’t tolerate maintenance windows.
Then you have a bunch of little annoying bugs that ruin productivity. Do you think that if you navigate to the same page you’re already on, but change the value of two route parameters, that your page would be re-rendered with both of the new values?
Guess again. That happens sometimes, other times you get a render with one parameter changed, but not the other, followed by another render with the second parameter updated.
Things like that are maddening because they’re seriously unintuitive and completely undocumented.
We use Balzor in production, but almost exclusively for internal applications. These are real applications that do some cool things, but they're not at hyperscale, and we are less concerned by design as we are by function.
Thanks for the shoutout Nick. And well done on getting closure on your old video - it was more important at the time than most people think.
The interviewer keeps interrupting and doesn't let listen the smart person.
Blazor makes development faster and makes the product better.
I freaking love Blazor. I'm a backend dev and Blazor is so smoothly integrated that I can work with it. Especially for internal projects
I still don’t think Blazor is particularly useful in any web application, it kinda caters to developers who just don’t want to learn JavaScript, but after decades of JavaScript pretty much dominating the web market, I wonder how big that audience is.
So I believe Blazor will be used mainly in some business apps that are mainly deployed in an intranet like LoB apps, and I don’t think we will see a public apps written in Blazor anytime soon, and by now we should have already seen one if it were to happen.
Microsoft uses it for the Aspire dashboard. And we know how they feel about Aspire.
I keep thinking about Blazor but I worry about being siloed into a specific technology that doesn't transfer to non Microsoft stacks.
I've been developing for over 20 yrs and I actively avoided front-end work because I absolutely hate Javascript with a passion. Being a backend C# developer, Blazor has helped me bridge the gap and avoid a lot of the javascript nonsense; so for that, Blazor has been a god send
I work in a software factory placed in Argentina. We have been using Blazor for develop many backoffice apps. All of them successfully working on production with no problem.
Hola, usan blazor server o wasm?
If there Blazor had an amazing drag/drop UI designer, it would be game over for all other frameworks. (Obviously not literally, but it'd help)
I think blazor is great for making management portals, tools, and other internal use web applications for teams that don't focus on the web. If the usage of these web applications is limited, you can just put the application on a server and not worry about it. But yeah, i wouldn't put it on a public facing web application.
Blazor needs to become the standard front end framework for working in c#
About Microsoft not using Blazor, I think Blazor is a perfect fit for non-sexy backend systems with a ton of CRUD, data processing and real-time interactive views, where SEO and every page loading in a millisecond are not priorities. So like an ERP system or a management system that have tons of features and whose users are experts making lots of queries and transactions. Blazor would be a terrible fit for a consumer app like Facebook.
Then it is a terrible idea to consider blazor...
@bravedeveloper Why so? I think it's more about choosing the right tool for the job. Personally I feel like Blazor is the most productive tool I have found so far, and it tends to make implementing features like the ones I mentioned like 10x faster, and there's no need for any glue code for client-server communication. But I happily use React or Next too if Blazor is not viable for a certain use case.
Just like Web Forms was. Perfect for the internal non-sexy sites. Blazor is the successor.
You are wrong, Blazor is better at everything if you built it right.
The only drawback for now is the 1st load time, that's it
@@rankarat that simply, objectively, isn't true
I really enjoy building in Blazor both for work and for personal projects. I really hope it does not die out and it gets more love from the dotnet team and wider adoption across Microsoft services.
I'm excited from Blazor since starting using it.
I switched from Angular and never look back.
Blazor is the best web UI technology of all time. It started at the top, and they’re only increasing their effort to make it even better. There’s no competition. Microsoft should embrace it more broadly, demonstrating greater commitment and leadership to set an example for the community.
Aspire uses Blazor, and it is getting a lot of investment from Microsoft. You shouldn't delete or produce content to appease the crowd, you should state your opinions and truth no matter what people think. Never delete videos because people are mad about it.
I love blazor
I don't agree with this take at all. Sure, Blazor doesn't solve a "problem" per se, but it's easier to use than react/vue/angular. Easier to use means fewer bugs and a quicker dev cycle. All wins in my book.
I don't agree with this. Just because Microsoft isn't advertising who is using it doesn't mean it's not being used. A lot of companies have put a lot of money and time into making components for Blazor, which to me shows there is a market and it is being used. Same with cloud providers now supporting signalR, they wouldn't bother if there wasn't a demand. It's a great product and much faster to use than the alternatives especially when you have to do server side things. I no longer have to write a front-end and an API.
Still concerned about the performance of customer-facing site with Blazor
In my team we have spent the last 2 years using Blazor WASM and pushing it way beyond SPA. Our whole team loves it. Sure there has been a lot of learning and libraries like Telerik are really lacking still, but its damn easy to make your own controls so meh!
I feel like your criticisms are a bit superficial. Why stick with popular technology rather than looking what the benefits are.
We created an enterprise blazor application and one of the amazing things we were able to do is write once run anywhere. I wrote all our business logic and models that is shared between client and server. This lowers maintenence considerably, especially when you have to update your contracts after changing an api.
Another thing is using a strongly type language like c# over Javascript yields way more benefits like offering compile time errors and is better performance as webassembly runs natively within the browser.
I find these assessments of the state of Blazor interesting that everyone only looks at Microsoft. After all the WASM format is an open standard and supported by all the popular languages. For me the bellwether is the state of the WASM standard as a whole and the other languages supporting it. If the feeling is that WASM isn't going anywhere, or the spec isn't iterating fast enough and it looses favor that way.
Thank you for the video. Blazor in production dev here. I love writing features with Blazor, but I also agree with your critiques. I’m also worried that people are ignoring the static rendered razor components, because they are so much better for creating a typical MVC app.
Blazor Framework is the best framework that Microsoft had released ever. Its perfect. Especially creating projects using Mudblazor. The production feels me a desktop application on the web. Brilliant!! No way to get back to any other frameworks!!
I think that if I had seen this video 4 years ago, I would have agreed. Now, definitely. Razor just seems like a better choice to me.
As a Line of Business developer, I've built an internal use app in Blazor, and coming from MVC I love that I don't need to write javascript to interact with the UI. I don't like that IDE integration with Rider is not optimal wrt hot reload. The variable naming is confusing, though dependency injection in Blazor9 in the code-behind file does help with this.
I've used Blazor in production since 2021, and I've come full circle back to React. Microsoft doesn't eat their own dogfood, and there are real pain points with Blazor that they just don't care about *because* they don't use it.
Blazor is great. I migrated a bunch of C# code from Windows Forms that I had been writing for the last 15 years. Finally, I didn't feel the need for another development tool. I can focus on solving business problems instead of learning other tools. To replace Blazor, something else would have to be significantly better. Like for example what Bitcoin is to money.
Your hoodie game was better back then ;-)
I'm curious what technologies you are using for the Dometrain website and why
Want a video on it?
@@nickchapsas Yes plz! :D
@@nickchapsas yes please
@@nickchapsas can't wait!
please
I use it for all my admin panels, blazor web assemply
It is difficult to consider moving to Blazor when everything and everyone uses JS.
In my opinion JS has major flaws and really should be superseded. But that’s incredibly difficult due to the inertia when it is so ubiquitous.
Maybe Blazor is a bit ahead of its time in that regard. It’s solving a problem that there isn’t sufficient will to solve yet.
If people are avoiding JS because they have only really worked with backend before… well maybe it’s an option, but you will be limited on what support you have and who you can hire.
Even using Razor/MVC is somewhat an issue for as as design agencies are used to people working with React or low-code platforms.
Why learn react when you already know how to use c#? Life's too short to learn dozens of languages. Microsoft already gives you the tools and power to simplify things, why bother with 10 different technology stacks? I get it, .Net might not be always be the "right tool" (whatever the hell that means) for the job, but I think you should only consider using other technologies if the pros outweigh the cons just to get the job done, most of the time these advantages are negligible compared to the time it will take you to learn a new language or techstack.
Ps: this is in a context where you need to build a product. If wanna just learn new things go ahead, i didn't say to put yourself in a c# box.
If you feel confortable with a technology is ok, but I don't think you will really lose anything learning other stuff.
I can't simpatice with that mentality because that's how I feel how we end up stuck with the same thing and never improving.
I desperately hate to say this as it verges on gatekeeping, but as developers it behooves us to be able to cross language boundaries. And I don’t mean being able to write C# and VB/Java. If there is a real problem with the .NET ecosystem, it’s that it is too vast to properly understand without sacrificing the flexibility that the real world requires.
Not to mention that other languages bring paradigms that can hugely change the way we consider our code, whether we use that language in production or not. Ignoring the lessons learned by other stacks is handicapping yourself.
You must learn and understand multiple languages. I wouldn't hire someone that puts themselves in a C# box. That's not the right mindset. Tech changes rapidly, and so should you.
You know one language, you know then all
why eat in mcdonald when you have kfc
The problem with Blazor and Razor, is that at some point you're going to need some rich html control like a chart or complex menu or whatever, and you're going to have to use javascript for it. Then you have two systems that are building UI. You may as well just embrace a framework like react/vue/angular etc.
Use a component library
Web Assembly powered Silverlight 7 would havd been 10x better idea than blazor and netmaui
@@Songfugel Much better with a framework build on standard like css, html.
I have worked with silverlight and wpf and I hated SAML and the way styling was made.
I have never been more productive, now that I use Blazor WASM and Telerik
Try tailwind in blazor.
More like a skill issue if you don't know how to combine vanilla js or a framework with blazor
React is so shitty compared to Blazor. I don't want to deal with all of the React rendering bullshit. In Blazor i can do both frontend and backend using my favourite technology .NET and C#.
Totally agree
@@iTakvim44 I tried React, Angular, Vue and Svelte. React is the worst to work with. I really like Svelte. Im open minded about all the tools for web development, but working in one language for both frontend and backend is great for me. I can share some code and there is no need for a context switching.
How do you real with hot reload never working? Takes forever to build something when you neeed to restart and lose state.
I'm working in company where we're building some automation software and blazor is our main technology. Our websites are technical: creating permits, monitoring gates, devices etc. And here blazor works as charm. Blazor speeded out dev time many times. So now we're more effective than using JS.
Insert Obama medal-ing himself meme. But yeah, i agree with old Nick.
Last year I jumped on the hype train and worked on an Elixir Pheonix project which went really well.
The scope was to push an MVP as a big team, so that afterwards only 1 - 2 devs can continue the work.
But I have to say that current Blazor really feels better than Pheonix. I agree that it’s somewhat of a niche, maybe even because it is so common to have one FE and one BE team working on an MVP, but it’s still a super nice Fullstack experience
We use Blazor in production at Broadcom because of its high development velocity and ease of starting up. My own team has two Python/AI/data science folks with almost no programming experience outside of Python. They chose to do their front-ends in Blazor and backends in Python.
They coupled it wrong. They should've shipped C# in the browser, focused on minimize bundle size (they're huge), and just let people use React via interop.
Blazor is one of the most productive front end frameworks. My second weapon of choice would be Vaadin with Spring Framework. But Blazor iswsy more powerful once you get going.
Static Server Side Rendering is my favorite.
blazor wasm has been amazing for me in developer POV. agree with you on how Microsoft going with blazor though.
The problem is that javascript is such a terrible language to maintain. All these libraries angular, react, vue... they change so often and sometimes with major implications. Now, if I change something in C#, immediately I can see where the errors are (granted using ReSharper), but with Javacsript, you can accidentally change a variable name and you will never know until someone reports a bug and you have to do a deep dive to find the issue. I honestly hate working with it, especially taking over someone elses javascript dogpile. Javascript is only as popular as it is because for the longest time, we had no other choice. I also don't understand why you say we should be average at everything. Being excellent at one thing is way better in my opinion. Obviously not to the extent that you are completely naive about anything else.
I really have to disagree. I've been a C# developer for 12 years and started with Blazor 2.5 years ago, after almost a year of unsuccessfully trying to gain a foothold in Angular. Javascript and Typescript work differently than C# in many areas and I still can't get to grips with them. On top of that, the constant context switching between JS for the frontend and C# in the backend is an absolute horror. I work alone and in 2.5 years I have now written 7 internal applications with Blazor and brought them up to production level. I would never have been able to do that with the switch to Angular, I would probably have spent half my day in forums and on RUclips. With Blazor, it took me maybe 6 weeks to get into it. With Angular, I would probably be just about ready to go live with my first application. This is of course my personal case, but I have met many C# developers in my career who give JS/TS a wide berth. For them, Blazor is a real blessing.
Microsoft need to use it themself to get adoption, and still then it will be hard. Microsoft is using React and React Native on many projects, but almost never Blazor, MAUI or UWP/WinUI.
The idea is fine, but it's for people who have a backend in C# and wants to make a frontend. It's not for people who wants to make a frontend with a C# backend.
Yes, this exactly. (I just left a comment saying the same). If I google 'NET Blazor/MAUI real world examples' there is almost nothing. And certainly nothing from MS. Almost every demo is a bootstrap weather app, or a note taking app, or a todo list. I know there's a podcast app and the Pizza Workshop demo (which were much better)
I was toying between MAUI/React Native for an app. Wasn't sure which. Looked at both sites and seeing Instagram, Tesla and Microsoft Office in particular apps built with RN made it a very convincing argument. There was NOTHING for MAUI. And I have the same with Blazor. 'Simple to build with Blazor' is for a beginner tutorial, a complex application showing Blazors FULL potential is what will sell it to me
There's never a reason to take a video down, engagement is good.
Why dont you say what you use on dometrain? I would be really curious
He uses 11ty
i love the way nick understands MS i cant understand their doucmenttion online but with people like nick make it easier for me so documentation is a huge problem for them
We use blazor in production for an ERP system, the desktop version of the app supports scripting via c# and vb and because of the coolness of WASM i can run Roslyn in browser to run my scripts.
We use blazor server-side and wasm in some enterprise apps. Quick easy and low maintenance cost. It is not designed for high traffic sites and that is fine. Devs are happy using it.
Blazor is superb
I feel like blazor is a good solution for companies that have a product that is written in C# and need some kind of frontend. IMO these days a web or maui hybrid UI is the easiest and most sustainable way to develop that, when then don't have any web developers on the team. For example when they develop many background services that only need some GUI to be configured, so the UI is not the focus but a necessary evil...
For a loose-coupled spa solutions you would still autogenerate your C# request/response models from backend to new frontend models. And whether the frontend models are C#, typescript, js, something-else really (for me at least) kills the advantages I thought having of not repeating code and rewrite domain-specific methods twice. So it really just comes down to what language and frontend framework you prefer (react, vue, angular, blazor)
In my team we use Blazor, because we've already know C# and it's amazing, the learning curve is very short. Instead of Angular when you start with a version and finalizes the project, you realized that already there are 3 major versions released and you have few time to learn the changes.
Balzor default project is admin panel, that is main use for it. We use it exactly for that in my company. Now we will make app for end users but it is for limited number of users our costumers.
Honestly, I hate anything that tries weirdly merging frontend and backend. Like Blazor or Next.js or similar. I prefer to have it completely separate, always. For development AND security purposes.
For backend I always prefer the .NET Minimal API, it is amazing. As for frontend, I choose the tech based on my project:
- Native HTML/CSS/JS for simple stuff
- Svelte/React for more complex sites that will be reusing a lot of components
- Avalonia for when I specifically need C# on frontend (usually when using certain C# only libraries...) or for cross-platform apps (it will perform a lot better than React)
Even when I want C# on frontend I usually prefer Avalonia over Blazor because of how easy it is for me to develop cross-platform apps with nice animations (just like WPF but simpler).
I don't know how Blazor is today, I used it back in .NET 7 and it was meh. Avalonia, on the other hand, has been amazing. Used it for 3 bigger apps already and loved it.
Blazor is still buggy and mostly undocumented (at least for the newer dotnet versions). You aren’t missing out on anything. I’m gonna give Avalonia a try, didn’t realize it was for web also.
@@yogxoth1959And how is it "buggy"?
@@BoJack32 Because of the way that it is. It's an abstraction, and not a great one.
@@catalystcorp "Because I said so" -> Famous last words from parents all over the world. 😂
Blazor Server is honestly great for an intranet app that doesn't need to worry about scaling. WASM and Hybrid have been gaining traction. While it's never going to get the marketshare that React or Angular (okay, or even Vue) have, it's still got a solid community. Your course numbers are a better metric than "number of mentions at NDC" (seriously who thinks that's representative?).
Something to remember about how much they were pushing MAUI at NDC - think back to how much they were pushing Silverlight 13 years ago. MAUI is, at best, interesting. I would never bet the farm on a desktop UI technology from Microsoft given their history on that front, though. Blazor is what got me back into web development, and while it may not be the technology I use for my next public facing site, it definitely would be for an intranet based application. The reason it wasn't getting mentioned at NDC is (IMO) more down to the fact it's reached evolutionary status rather than revolutionary (i.e. unstable) status, which I feel MAUI is still in.
Yeah we are using Blazor server in production during the 4 years and it is quite good.
Microsoft does have a "Blazor customers showcase" page. They only show 7 companies though.
Blazor, as of ~8 months ago, hasn't scaled well. The previous company I worked for have had projects use Blazor on a few occasions. The experience had been that the project started out fine but as it was getting more fleshed out during development, and more was being asked of Blazor, the team would end up having to hack around Blazor due to performance issues. I don't think it has changed much since then but that was one of the big issues and why that company essentially told all of the dev teams that they can use it for proof of concepts but not for production.
this doesn't make sense to me.. WASM/SSR? Any examples with metrics?
Started a greenfield project using Blazor auto-render mode (server and wasm). Loving it! Will never go back to Angular. Although we are still maintaining a few legacy applications.
As far as the point on talent pool being bigger in TS/JS vs c#, that may be true in terms of the quantity, but not sure about the quality. I find that everybody and their grandmother claims to be proficient in JS, but they are not.
I'm curious to see what kind of backlash you got on that original video!
Once you make a video private you can’t see the comments any more. RUclips just deletes them, which is unfortunate
One just don't use any tech from Microsoft that they are not dogfooding. Simple as that.
Silverlight?
WPF?
WWF?
F#?
XNA?
WinJs?
WinRT?
Blazor - next
UWP - next
WinUI - next
MAUI - next
In the place I work, we have a lot of programs written in C# because these are many back services. But there are some interfaces we are developing and they were made with Angular. Now, we are migrating them to Blazor.
There is a good reason for this and I think it is obvious: since a majority of C# skills is required, it is then easier for C# developers already in place to learn Blazor than Angular. It is less efforts. Otherwise we would had to recruit experts in Angular (done before but since then they went elsewhere).
"Tired of wrestling with JavaScript's quirks and cryptic errors?
Join the Blazor revolution and let C# save the day! It's like trading in a rusty old bike for a shiny new electric scooter - smoother, faster, and way more fun!"
Using Blazor 3 years in production having over 100K subscribers on our cloud platform. Would not changed it for anything.
Hello, do you use blazor server or WASM?
link to your platform
0:58 - So this is how it all began
Company: We have written a tool that allows you to write everything in one language, and the toolchain will do the rest, you only have to write in one language.
Devs: Use it all the way to production, and use it without thinking about why.
Devs a few years later: We should not have done that... we should not have done that... we need to rewrite.
Any system big enough that needs to actually be designed and thought about critically; this approach never works. Hire devs that think in more than one tech stack, you'll be better off on every metric there is to measure a team.
Anything will ' work ' for any system small enough, but those systems should not be the reason something is 'good'.
I am a heavy Blazor user, and I must say that no longer imagine my work without it.
- What it gives for me is a speed of development, ease of use, enabling developing both Front-End and Back-End using same language.
- When it comes to big companies using Blazor: UiPath (leading RPA platform in world) Apps are built using Blazor. Point is that there are those use cases, but how will we know if it is not being communicated and/or we do not look for it?
- Yes, SignalR disconnects are annoying, 100%. But ability to render Server side & Client side kind of helps here: yes, live chat can be rendered on server and can be disconnected, random wiki content can be rendered client side, and you won't get disconnect. It all comes to use cases.
I would say there are two kind of developer's thinking ways: frontend and backend. For first lager of developers is best JavaScript beacus of it "simplicity" (and as result, popularity). For others - JavaScript is unclear rudimental trash that should be replaces with strong typed language in future.
P.S. majority is not always right and the simply solutions not frequently best.
I think Blazor or and other Web assemblies are going to be the technology in the next years. But I agree that it is not quite production ready. It has a huge overhead when downloading components which is bad for places with low speed internet like rural areas and countries that haven’t developed the high speed internet infrastructure.
I think Microsoft needs to use it more in their own applications and we need to be more critical about Blazor so we can get it to be production ready.
To me the advantage of Blazor is that it allows you to share logic between the front and back end. For example, validation. It has also been my experience that most developers (I included) don’t have the mental bandwidth to be experts in multiple stacks simultaneously, making a “full stack” developer more of a unicorn than a reality. If you suddenly have a lot of back-end work, or a lot of front-end work, it can be hard to shift the resources. Sure, some people are “good enough” to do both, but those people who are “good enough” often require oversight, which is time and money, or they will make a right mess out of the application.
The downside to Blazor is Microsoft. They have a proven track record of heralding some new “groundbreaking” technology, then dropping it like a rock. Windows Phone and Silverlight come to mind. I suspect the only reason Microsoft hasn’t dropped Blazor yet is because they know if they do, they will never be taken seriously in the UI space again; not that people take them too seriously now.
I am curious to know, are you not using Blazor because you are not doing any web gui stuff, or are you not using it because you prefer a different front-end framework (react...)?
You do not need Azure for SignalR connection. You're wrong here. If you're referring to scalability, then say so, but even then Blazor server works perfectly fine for small/medium apps.
No it doesn't. If you have an international audiance you have to scale it out to every region to make the experience not suck
@@nickchapsas That's a specific system constrain. Many apps are build just for the NA or EU (ie specific) region, so Blazor solution is perfectly fine and works just fine.
I remember commenting on this very issue in the original video. I think it could be @nickchapsas lack of understanding on SignalR. If you want to scale it, you can add a Azure SignalR managed solution, or even run your own. I don't know where he is getting his information from.