Coding Shorts 111: Was I Wrong About Blazor?

[@barsenovic]

My favourite part is when you put your glasses down... it's like the suspense moment!

[@webguru22]

Haha it's like "It's about to get real..."

[@barryblack8332]

Mine is when he puts it on

[@RafaelConceicao-wz5ko]

I've been using Blazor recently, and honestly it's the only thing that's made web development enjoyable for me at last

[@krss6256]

I'm building quite a massive Blazor app - probably one of the most ambitious projects in Blazor there is and I still love it. There is a lot of things that you need to keep in mind while you develop, a lot of things to do a little bit differently, and quite a few limitations around interacting with DOM but I think that the advantages of using modern C# are making the development experience simply unbeatable. I wish there was more mature tooling and working Hot Reload and debugging - this is absolutely the most annoying thing about Blazor but this is a small price to pay for the other benefits of the framework.

[@swildermuth]

Awesome and glad it's working out for you. Is there a code splitting option I'm missing? Crucial for large scale projects

[@abhayprince]

@@swildermuthLazy Loading is there for Blazor

[@georgebeierberkeley]

Yeah well hot reload doesn’t work that well with razor apps either.

[@unskeptable]

Hot reload is a joke in all latest Microsoft products

[@skywalker2278]

Surprised to see so many people having issues with Hot Reload while it always works for me.

[@romania-n6q]

I wish I’d discovered Blazor earlier! Moving from JavaScript through Node, Express, TypeScript, React, and React SSR felt like a constant juggle of libraries, packages, and compatibility issues. Each JS project needed a mountain of dependencies, which we could only hope would work well together across versions. And then there’s always that one person at work pushing to experiment with Bun, adding to the chaos. Remember when we used to think of React as a slow and clunky choice? Now, it’s evolved massively, much like Blazor.

[@81NARY]

On a side note, I started my Career by watching tons of courses on PluralSight (~8 years ago) from you, Julie Lerman and Scott Allen (RIP). So thank you! 💙

[@swildermuth]

I am honored to have been a part of your journey!

[@matthewwatts6281]

Great video and really good to get the opinion of someone who uses a JS framework but also C#. As someone who does about 20% front end and 80% backend I just find Blazor so much easier. I have used Angular at work and just find it a steep learning curve. Yes I could get better at it but with Blazor I can build very complex applications using my current C# knowledge.

[@swildermuth]

I get that. But I find learning a simpler JS framework to be more productive. I'm personally invested in Vue since it doesn't require the boilerplate of something like Angular. But, ultimately, if you're productive with Blazor, no reason to switch.

[@maxvideodrome4215]

I’m picking up web dev after about 15 years of not coding. Blazor is what I’ve been learning and it’s awesome. I’m avoiding JavaScript for time being as I have stuff I need to get done.

[@georgesaeid7231]

I think Blazor is the way to go for all. The question remains is which to use, SSR or CSR or Auto, this what will differ from project to another. I think as well there is no problem at all with bridging between JavaScript and the assembly code. It cannot be easier. I used it heavily in both Interactive Server Mode and WASM. I also got a quite enough experience with Angular and React. I can confidently say that everyone should consider Blazor, even those who are living in JavaScript/TypeScript world.

[@sprez]

One advantage of the new Blazor template is that you can run the .Client app using server side rendering by changing the rendering mode of the client MainLayout component. Essentially, the .Client app becomes a RCL. While developing you get faster initial loading, decent hot reloading and fast debugging.

[@swildermuth]

Essentially like next/nuxt

[@ivanvincent7534]

Great tempo and teaching style. Content about wasm on the server side as a compile target would be great.

[@swildermuth]

I'll add it to the list.

[@a-videoo]

'I'm going to save it to a folder, not some magical place.' hahaha ~10:08

[@swildermuth]

; )

[@CrynogarTM]

I am using VueJS and REST-API and all running in a Golang Project. I completely moved everything from C# to Golang.

[@marna_li]

Didn't the publish folder contain both the compressed and uncompressed files? Then the size is much smaller than 20 MB. I see that you create a separate component class from which the component/view inherits from. You could achieve the same with code-behind using a partial class. There is a refactoring that extracts @code block to a code-behind file. And if you want to test the components, like interactions and what is rendered, you can use a library like bUnit (together with favorite unit testing framework) that essentially mocks the view.

[@swildermuth]

Didn't think about partial. That makes a ton of sense.

[@ijungleboy]

I fully agree with "use JS when it's appropriate, WAMS won't make you happy". BUT the latest Blazor can now (.net 8) be used just like the classic Razor - and then use normal JS like it's intended to be. I think that use case is very valid, because the component model of Blazor is much better than the plain Razor model. Makes programing much better encapsulated.

[@swildermuth]

It does, though the magic of the @ code {} I could live without.

[@seldasorf9583]

Totally Fully agree, have developed MFC, Win Forms, WPF and meanwhile Web only for decades and see Blazor in the niche you see it. Thx for digging deeper and verifying that.

[@swildermuth]

Thanks!

[@nothingisreal6345]

I use it with the MudBlazor component library. Has a lot of ready to use powerful components and a lot of this nasty CSS crap is abstracted away. I would need to spend at least 2 years to get familiar with TS (would never use plain JS anymore) and some modern TS framework (Vue, React, ...). That is a big investment - and most likely the next project uses another JS framework. The binding in Blazor works great. With the new mixed render modes now supported performance got better. I agree that the tooling in VS and VS Code is B.A.D. Hot Reload does not work reliably at all. Overall IMHO any UI development is way too much effort and time consuming today. For building line of business applications something as productive as LightSwitch would be great - but MS killed it ... for some stupid reasons. The situation today is: LowCode is a death trap as way too often one get's stuck. The DIY approach (I do it all by myself) most projects use today has a terrible productivity and is way to error prone. There way too many competing frameworks. SW development must get much more mature and consolidated. Today we reinvent the wheel all day long.

[@swildermuth]

As long as it's working for you, no need to change.

[@XomegaNet]

What do you think of the Xomega platform?

[@swildermuth]

@@XomegaNet I don't have any exposure to that. What is it?

[@XomegaNet]

@@swildermuth It's is a low-code platform for .NET developers that helps you generate apps using Blazor or other technologies.

[@BenjaminSmith-pp3yg]

Thank you Shawn! For many years you have been on my radar as v. informative and v. interesting... love fact you seem to be fan of Vue + Tailwind - you clearly actually DO substantial real-world dev. (so much trash published by people who seemingly just think about real world dev, but rarely if ever actually do it). haha. Don't get me started on some of the MS Patterns and Practices stuff (I mean wow!). 100% agree (with my admittedly v. limited experience with Blazor) that you are correct with the summary (if I got it right?) i.e. " Is it worth it? Probably not (assuming you are comfy with js/ts and e.g. Vue). Unless you have some v. specific requirements that make WASM a real contender for the functionality you need. " Pls do shout if that is NOT a good paraphrasing of your topline? Also totally hear you with the clunky tooling e.g. need to restart the app (vs what we now come to expect i.e. ~immediate ~perfect hot reloading dev experience for frontend). I do wonder 1. if you were a fan of Knockout before Vue (do I remember some old blog posts about KO)? 2. if you prefer Vue (3) Composition API (over Options) 3. if you tend to use Pinia or similar in Vue3? FYI I'm pretty firmly 1 = Yes, 2 = Yes 3 = No Apologies if you've totally covered all of that on a blog/other vids (don't have much time to research/hone these days). ;( Much appreciated!

[@dudeharmonious]

Much appreciated, Sean. We really enjoy your objective takes on tech. Very validating.

[@swildermuth]

Glad to hear it.

[@SimpMcSimpy]

Visual Studio support is still not so great due to incomplete hot reload feature, but if you can digest few weak spots it can do nice job. It is perfect for building internal tools (thinking about enterprise companies) or smaller businesses. I've been into programming since late 90s and doing mostly system engineering, HATED doing any web coding. But with Blazor it's awesome. Coming from mostly low level C programming, I am one of those who believe web should fully embrace web assembly. This is why I see Blazor as a step in the right direction. It's far from perfect, but for simple and quick stuff it's good enough. And I underline this "good enough". I just hope MS keeps it alive longer than some previous frameworks :)

[@swildermuth]

That's where I am at with it too.

[@20windfisch11]

Use Blazor with MudBlazor, Bolero and use the Elm(ish) pattern. Once you have understood the functional approach, you get results quickly. I made an in-house web app running with Blazor Server (WASM is out of question, our company PCs all run Sophos which analyses all binaries once they come in which slows the application to a crawl) and the customer wanted one component of that application as a client-side app, exchanging the server-based functions with some simple file I/O. I managed to slap that component into a separate Blazor WASM application and use Electron to make the local application for the customer.

[@swildermuth]

If that works for you, YEAH! This video is about Blazor WASM. I don't care for the non-standard communication between server/client but I understand why people like it.

[@waynehawkins654]

I love Blazor and it only going to get better.

[@swildermuth]

More power to you!

[@keithnicholas]

that's great and all, but better than what? better than what blazor was before? seems most anything is like that, things improve over time. Real question is how competitive is it with other things, is it "better" than those other things.

[@joshman1019]

Blazor is definitely a great way to quickly build a utilitarian front end. I've used it for this purpose since scaling and threading are such a pain with WinForms. I enjoyed WPF, but I would get lost in the details sometimes. None of it was fast, but I loved the level of control.

[@SimpMcSimpy]

In my company I am replacing all old internal Win Forms tools with Blazor.

[@rotgertesla]

@@SimpMcSimpy Hello SimpMcSimpy, what is the logic to switching winforms app to blazor at your company? I am currently using winforms for all my tooling apps at work and I wonder what is gained from switching to blazor in that case?

[@carllindelof]

Very nice review of Blazor , will you do a review of Htmx and Aspnet Core. Server side rendering vs spa, what you would use for different kind of solutions

[@carlosjosejimenezbermudez9255]

Htmx + AlpineJS is a great way to bring some rich client-side UI experiences to an existing MVC app or even an app that will only have one very interactive page. Best of all worlds in my opinion. I architected an app that way about 2 years ago and it was awesome.

[@swildermuth]

I'll add it to the list

[@dovh49]

You can use HTMX like a SPA. It depends on how related your pages are across the domain. What's nice about that is that you can do hard splits on your pages depending on how closely related the pages are.

[@NBGTFO]

I really wanted to make Blazor my new goto for web apps (I currently use Razor Pages with mostly page handlers and JS), but a lot of my apps are used in a factory environment on tablets where wifi is spotty in some areas so I didn't want to have to deal with issues where SignalR would lose its connection briefly and bring down the apps. So really, the reliance on SignalR is the show-stopper for me.

[@swildermuth]

That makes sense, it's not always the right fit.

[@CraigLuna]

Blazor is a broad term and offers multiple strategies. Static SSR, interactive Server and WASM. You don't have to use SignalR, just use static or WASM (or mix it up). However, it is no different than websockets, long polling or SSE. If you need real time communication in a bad network environment, it will be the same issue for another. In a factory, use WASM or Static SSR if SignalR and its fallback mode with stateful reconnect doesn't work out.

[@Qrzychu92]

Actually, if you go full on WebAsembly, you can pretty much create an app that can be "installed" on those tablets, use SqLite for local storage etc - it can be quite resilient.

[@PticostaricaGS]

For that issue, the solution in most modern frameworks is to use PWA, which you can actually use alongside Blazor.

[@aspeckt112]

Why not use Blazor WASM in that case?

[@matteobarbieri2989]

I agree 100% with you. And when you repeatedly hear: "it's good for internal organization apps"...means that's a mess!

[@SimpMcSimpy]

No, it means you don't to learn new language or employ people just for web. Even an average C# coder can now quickly build a web application. I've been doing it for my company (internal tools) and I love it!

[@rollthers3157]

@@SimpMcSimpy Does it play well with third-party UI components?

[@ilh86]

It's because the drawbacks (having a constant SignalR connection for server side or loading the runtime in the browser for client side Blazor) aren't that much of a showstopper for internal applications. We use both versions and I wouldn't dream of using a JS framework as there's just way more utility of having a common code base on the front and back end.

[@horacioserrano5430]

I need this tool, with a limited team i need to produce client-server app that runs on browsers, is a dedicated android app and is a dedicated iphone app. I simply dont have the time or manpower to write 3 different front ends. Maui and Blazor bridge this gap by using the same code for all 3. It does require some tinkering and adaptations, cookies are a good expample, but if you manage to build those abstractions so that you can use them on all 3 environments this is a great solution. We are still developing it, it ends up working, this will be an awesome tool. Loading sizes and time are an overblown issue.

[@swildermuth]

When you marry this with Maui, that's a different question. Glad it is working for you. You're the perfect use-case IMO.

[@delphiguy23]

Im a seasoned c# dev mostly delving in the backend/api stuff. My understanding of js and its frameworks are very weak (UI has always been my weak point), and Blazor seems to be a good fit for me until I get myself comfortable with js. That said, I tend to agree that Blazor is not there yet. But for now, it is a good stop gap solution for me until I get comfortable with js frameworks.

[@swildermuth]

Not a bad strategy, but I am not sure that Blazor will help you get up to speed with js/ts.

[@bjorns1135]

Blazor's use case is probably geared towards the more highend webapps, than your run of the mill webpage.

[@swildermuth]

Or Enterprise/internal apps instead of websites.

[@Eric-v8t]

The development speed is high with Blazor, which is very important cost-wise. I experienced how slow the development process with React can be and the amount of garbage you need to write to satisfy the framework. However, AI assistant coding tools can change the narrative, and JavaScript wins because there are cheaper/younger developers in the market.

[@StephenStrong-x1s]

Wow the courage to ask "Might I be Wrong?" very rare these days. Like you I have been allover the ever changing web stack. I like blazor because I build editors that expect users to spend a lot of time in the client. However I do not think that my dll are beiung recompiled to wasm. it all works, but maybe it could work better. Yes there some dark magic here

[@swildermuth]

I appreciate it.

[@harrisonwell1719]

When it comes to front end nothing beats JavaScript

[@Qrzychu92]

From my experience, blazor has a niche use and if you don't fall into it, it's a mess. However if you do, it's a blessing. If you create am internal app with 50 users, blazor server is just so nice - keeping everybody up do date is easy, no time wasted on creating endpoints, just do the thing. Another use case is internal PWA - app that gets installed once and then users just keep it opened. Initial download time and startup time become irrelevant. Libraries around using sqlite are just so magic compared to JS, you can create some really nice things. I would happily trade the time I spend tracing "undefined is not a function", or wondering if hot reload did work or do I have a typo, for couple restarts here and there. At least I knwk what I am waiting for. Would I use Blazor for an app that is used by the public on a phone connection? Probably not. In every other case, I find it really nice

[@swildermuth]

Why is a private PWA more beneficial vs. Vite + PWA?

[@Qrzychu92]

@@swildermuth well, personally I find I spend less time restarting the app with Blazor (it's pretty fast to restart) than I waste trying to do things in JS. I am far from proficient with JS - just having LINQ in Blazor is enough argument for me. Apps that I create like that don't need flashy UI, so Tailwind not being as easy to use is not a problem - what counts is the app doing the thing it needs to do. For me, and many C# devs, it's much easier to achieve in C#. Because let's be honest, most of the work is filtering a list, and uploading a form, maybe store some cache in SQLIte for offline support (which you can do with EF Core in Blazor WA :)) If your app does more than that, probably use Vue. Out of all the JS frameworks this one is my favourite

[@rupture007]

​@@Qrzychu92 Exactly! It's not JavaScript that is the biggest draw. I use mostly "Vite + React + TypeScript" for work and even some personal projects. However, anything non-web, Blazor Hybrid is what I would choose in a heartbeat. That is not what this video is talking about though. I do agree though I would just rather work in C# although I consider myself proficient in both.

[@chrismingay6005]

I'm by no means a Blazor fanboy (I flip flop between Blazor and Svelte for my own projects) but re: 12:40 I'm interested to know why you consider learning Blazor to almost be lesser of a task/outcome compared to Javascript in the realm of web frontends? If Blazor is able to do everything you need, why is javascript even necessary? I've found recently that I'm not actually learning JS anymore, I'm learning React/Svelte/Angular and they just happen to use javascript. Ultimately the user doesn't care if the experience is good enough.

[@c1d3r-lf5ug]

I prefer Blazor over React, it has the support of the Dotnet framework and it tells. Blazor is also a compiled language so expect issues with hot-reloading. I see a "possible" better JS framework in Blazor then i do in React, i havent tested the limitations.

[@swildermuth]

I think Vue is awesome, but if it is working for you...no need to change.

[@paragateoslo]

Not having hot reloading as a frontender is a horrible experience. Having to compile the app over and over again drives med mad. Blazor should only be used in apps where user experience is somehow not important.

[@c1d3r-lf5ug]

​@@paragateosloBlazor does have hot-reload, unless you expect it to work when changing internals or something.

[@paragateoslo]

@@c1d3r-lf5ug well only slightly. Its highly unstable to the point of simple css prop changes ofte doesnt register.

[@c1d3r-lf5ug]

@@paragateoslo Yea it is not ideal.

[@PicaPauDiablo1]

Just FYI Shawn, typo in Title. Very cool video though, thanks man.

[@swildermuth]

Oops, you caught me! Thanks for the heads up.

[@danhartley2136]

I've been using Blazor wasm for about 3.5 years now, and have been able to build some pretty interesting projects. I like it a lot, but am not quite a Blazor evangelist. The biggest problem by far is the tooling which is painful to deal with. Hot reload just doesn't work. So anytime you need to make even a minor change to the markup, you have to stop/restart, wait for the build to finish, the browser to launch, the debugger to attach, etc. It can be pretty tedious.

[@Explorest]

Please do a 10 thousand feet view of Blazor (both server and client side) -- just basic description of what the different parts are , how they come together, how they talk to each other --- with the simplest possible project that can demo it. How to think and reason about Blazor. Would be a great great illuminator. Blazor is too big and fuzzy --- and horribly confusing.

[@PeterMatthews-j9x]

The biggest lie about Blazor is people calling is a "JavaScript Killer". I wish we wouldn't do that. JS is a tool in our toolkit the same as any other tool. Use it where necessary, use it when you want, use it as you'd use any other tool. JSInterop is massively powerful, and even more powerful if your CSP isn't hyper-strict. You can inject tiny payloads of JS into any page that needs it, and clean up the DOM as components are disposed.

[@swildermuth]

Exactly. Blazor is a different use-case.

[@PeterMatthews-j9x]

Kind of. I understand what you mean. Blazor isn't a replacement for JS, it's more than just another use-case. It's an additional render engine and routing pipeline that can be used as a part of the AspNetCore ecosphere. You can use MVC, Razor Pages, WebForms, Static HTML, MinimalAPI, WebAPI, Blazor Web App, and React, all in the same project if you like. They are all available to you as tools within your toolkit. Weapons within your arsenal. Choose your own analogy. As an example, if you want to remain within the bounds of PCI-DSS SAQ-A when building a checkout, then regardless of whatever render engine you use, you will have to write good old-fashioned JavaScript to interop with the drop in forms. The SAQ-A is a 19 page document with 22 questions. If you try to roll your own, and create your own checkout forms, because "We don't need JS now that we have Blazor! Why should I even bother learning JS anymore!?", then you need the SAQ-A-EP form, which is a 46 page document, with over 190 questions, and a quarterly external audit with an on-site assessment that can cost tens of thousands per annum.

[@MarkoMijuskovic]

I don't want to sound arrogant or sarcastic here, but this video very clearly sums up all the problems with modern javascript: kzbin.info/www/bejne/i6CWlH9qo9d6hc0. Now if we consider that time = money then Blazor does exactly what it is supposed to do - increase my productivity by reducing the daily javascript build/maintenance hell that we all live in. Does that mean it is better than or more viable than javascript? I don't know, I'm not that smart or educated, I think of myself as an average programmer. But I know that it makes my job much easier, fun and it allows me to focus on what matters - building a product instead of constantly doing plumbing fixes. We went from Knockout to React to Vue and now the latest flavor of the month is Svelte. Every one of them was hailed as "game changer" and, in the end, they all end up being... just another JS framework.

[@swildermuth]

That's not how I see it. The tooling/build for JS is, frankly, more mature than VS's Blazor WASM story. It's failings probably are hamstrung by the JS->WASM bridge deficienties. But if it is working for you, all power to you!

[@MarkoMijuskovic]

What do you mean by js->wasm bridge deficiencies? Can you give me a concrete example?

[@swildermuth]

@@MarkoMijuskovic en.wikipedia.org/wiki/WebAssembly#Limitations

[@muhammedadel9673]

Is there a way to code-split it based on routes to make it lighter?

[@swildermuth]

@@muhammedadel9673 not that I know of

[@emmanueladebiyi2109]

I went down this rabbit hole sometime earlier. Currently not possible as a single dll is generated

[@danroth27]

You can use lazy loading to load parts of the app based on the route.

[@emmanueladebiyi2109]

​@@danroth27 My bad, that's totally true. I should have been more specific. My research was more into lazy loading from a single project... Was trying to see if there was anyway I could build a convention based framework that just automatically lazy loaded components per route without manually specifying. Explored generating multiple DLLs per project but no luck so far. PS: I'm a big fan of the great work you do on Blazor 🙌🏽🙌🏽🙌🏽

[@ttolst]

The more i look into Blazor, the more i feel those who love it do so because they really are backend specialists trying to go full stack without learning the skills needed. The server version... wtf, new webforms. The Wasm feels like such an ugly fat hack. Just make your services API based and stateless, and use modern javascript like Vue for the client. Add someone to the team with competencies to teach the others. The client will be much faster, and you can have specialists in the team (no frontend specialist will touch Blazor) If you have not tried it, then i strongly recommend that you try to get into a position where you can work side by side with a highly skilled frontend developer and see the difference they can make when they truly understand the stack and think in reusable components.

[@swildermuth]

I think you're on the money here. Blazor (to me) fits into a space where you have C# full-stack (used to be WinForms or WPF) that need to move to web-based and have no time/interest in the JS ecosystem.

[@Arcadenut1]

Development tools are a religion...

[@swildermuth]

May your debugger go with you.

[@gfinzer]

@@swildermuth And also with you

[@davidmasterson883]

wasm released 1 year after server side, not hard to find unless you just want to suggest it is not a solid option to suit your pre decided opinion!

[@swildermuth]

It's just an opinion. The rolling experience continues to be painful. And how wasm works has decidedly checked in the last few years. A lot less friction that earlier editions. Debugging is still annoying IMHO.

[@LarsWorkShop]

Blazor rocks - so much less work than angular

[@kimpedersen4746]

i really like the comparing to forms .. it very nice to make all the mvvm code in c# and only have the gui part as html with binding to the vm . we do internal apps where we move a away forms to web. also nice to be able to make serverside since we have no heavy traffic

[@swildermuth]

As long as it works.

[@dand4485]

Might be me but what kind of turns me off on Blazor is the dependency on the sever. Might be nice for some stuff but i find my svelte stuff plenty fast for what i might need. And generllly i'll do the front end ui in svelte, and use messages to the pack end via some message. Then may server routines are C# for doing the heavy lifting for the app, them seems to me as the best mix... Could be wrong but i feel as i get the best of both worlds and good enough performance as a whole...

[@swildermuth]

Blazor WASM has no requirements on the server.

[@Siddiskongen]

For developers that don't know / don't want learn frontend (html / css etc) then Avalonia UI is a better tech stack. With design preview integration to VS and Rider it becomes a much better developer experience without having the need to stop / start the app for each xaml change.

[@BobFrTube]

I long moved from C# to TypeScript and don't see myself coming back. I do my desktop apps using Node with Express. Blazer seems to be for those who can't move on. I'm reminded of people who did tooling so Basic programmers would write web servers and apps without learning all that asynchronous stuff. DIdn't go well.

[@swildermuth]

I am not sure that's fair to those developers, but for C# only shops (think the new version of WebForms) - it's a viable solution IMHO

[@keyser456]

Could not disagree more. I moved my web app from JS to TypeScript circa 2016 which was nice for some semblance of type-safety. When Blazor WASM did finally hit, I was happy to throw away TS in favor of actual C# -> WASM in the client. No transpiling, npm, version mismatches, or other clunky build steps necessary. TS is for those who can't/won't move on, but stick with it boomer! :)

[@BobFrTube]

@@keyser456 Why go back to C# when you go just go back to Lisp, the great grandparent of TS? None of this new-fangled C-derived languages

[@keyser456]

@@BobFrTube You clearly haven't used Blazor WASM or you'd have moved away from TS yourself by now. Luddites gonna be Luddites though!

[@BobFrTube]

@@keyser456 You make many incorrect assumptions. I write peer apps, not clients.

[@TheCzemike]

The main thing I get from this video is that front-end web developers and back-end web developers are flexing two very different skill sets and expecting one developer to have true mastery on both sides might not be realistic.

[@pookiepats]

respectfuly, this is a terrible take, small businesses couldn't be as successful as they are were this true. expect more of yourself, you can do it too.

[@pookiepats]

* if you want to

[@lolyasuo1235]

Everyone knows that JS (even TS) becomes a mess when talking about large-scaling apps. This is something that JS devs are complaining about all the years.

[@swildermuth]

The "for years" is an interesting inclusion. This had been true for years, but in the last 5 years or so (coinciding with TS's adoption), large scale JS isn't as much of a mess as it once was. Bad architecture is bad, no matter the language.

[@ronnyek4242]

I just looked into it a week or so ago... I'd say tooling is NOT good... Significantly worse experience than workflows with react or other dev. I've always been a skeptic, but I really don't get blazer server is for, and blazor wasm seems less than optimal. I also think razor as a templating language is not great in 2024

[@swildermuth]

I think it's fine. Sure, it's not a mustache language, but I am not sure v-for is much better than @foreach.

[@afshin7104]

Hi shawn I may be wrong but I think blazor will have the same fate as windows phone for exactly the same reasons that windows phone failed

[@NBGTFO]

I agree. I think it'll be around for another couple of years and then fade away... unless they can make it much better than it is now.

[@carlosjosejimenezbermudez9255]

WASM isn't at the stage necessary for something like Blazor to kick off outside of corporate environments.

[@swildermuth]

Think web forms more than windows phone, I expect. Loyal following, long lived.

[@SBDavin]

I don't understand this comment. Yes - I had Microsoft phones, loved them, and feel Microsoft and the phone carriers dropped the ball with them. I especially won't buy Microsoft hardware ever again. However, most Microsoft software frameworks (OLE, COM, .NET, WinForms, WPF, etc.) have been around a long time and are still supported today. Microsoft has cleverly intertwined the MVC, Web Pages, and Blazor frameworks together. WIll they drop all three? What's the replacement?