Earlier quoted context omitted.
The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.
.NET Blazor
201–210 of 302 posts
Re: .NET Blazor
#202Earlier quoted context omitted.
I feel like your comment touched a million different places so I'll try to compose my arguments in a compact manner, hopefully to make some sense. > All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Where does this conclusion come from? At least from my humble experience,I've been doing them for ~10 years with various tools, both JS and Blazor/Razor Pages and the fact t…
> I don't understand the allergy of the so called "back end" developers with JS I think what many people are complaining about is that they actually dislike UI development and all the ambiguity and complexity. "JS" just catches blame for this. Modern JS and esp. TypeScript are pretty good languages, or at least comparable. A lot of these server side UI toolkits avoid some of the complexity by supporting basic UIs and…
It's not just that UI development is more ambiguous, it is the fact that it is difficult to make text-based code fit it. This is doubly (or maybe logarithmicaly) so when responsive (same code fit different screens). HTML, XAML, HAML, etc all require a lot of code. Reusability mechanisms (like components, etc) help this but it is a world of difference from what BE devs are comfortable with.
Thought #2: I'd guess BE devs like to just code, and the FE frameworks have a reputation of getting in the way of that. This is a less certain thought, so welcome opposition, but seems at least like part of the emotional reaction a BE dev would have to FE work.
Re: .NET Blazor
#203Re: .NET Blazor
#204I wonder what the practical scalability difference there is between streaming updates over a web-socket connection and streaming updates over a long-lived HTTP connection. It sounds like the same exact thing.
Hopefully it can keep the complexity of auto mode under the hood.. I don't think app devs want to deal with code that behaves differently depending on whether webassembly files are cached or not.
Re: .NET Blazor
#205Earlier quoted context omitted.
The problem is, all of this stuff will probably be dead in a few years. I think they would be better off working within established paradigms rather than trying to do something completely new. How about, for example, making it as easy as possible to use React with a C# backend?
Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.
Re: .NET Blazor
#206All the dis-advantages are not relevant for enterprise LOB apps, which Blazor is best suited for. Millions of .NET developers across the enterprise world are heaving a sigh of relief to never have to touch JS and be cozy and comfortable in their .NET ecosystem. With the latest addition of fully SSR, Blazor is also well suited for CMS, Blogs, Content Mills, small web apps, portfolio sites, etc. But, as a developer who…
BBBBBBBBBBBBBBINGOOOOOOOOOOOOOOOOOO! Yes, at the end of the day, businesses use software in LOB apps. Period. Get shit done. WebForms/ASP.NET MVC/.NET Core MVC/Blazor will outlive ANY js framework.
Re: .NET Blazor
#207The article (which basically says Blazor is a bit cumbersome and pointless) has plenty of truth (and a few half-truths) to it but it's assuming that you're using it in a context where pure js + html would just be much better for the end user (wait, isn't pure native better for the end user..). What it doesn't really tackle is the productivity from the developer perspective, very little mental context switching, code…
People don't realize this. Blazor is about the developer. I am a `DevOps/Backend` guy and in my previous job some internal tools were made with Blazor. It was such a joy to work with. Productivity was so high. You add Blazor Radzen components[1] or Syncfusion[2] and suddenly feels like magic. Super complex grid tables can filter, re-order columns, aggregate them and much more functionality for free in 10 lines or few…
Clearly. And that's exactly where the most salient criticism of it comes from: prioritizing the pleasure of the programmer during the development process over everything else, including the experience of the person who actually has to put up with using the thing—all while providing cover for the vendor who bid on the job to argue that they've fulfilled all the requirements so what are you upset about if it's a little janky? Classic enterprise crapware mindset.
Re: .NET Blazor
#208Earlier quoted context omitted.
React will die too, eventually. Or at least stop becoming the default.
Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol. What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly…
Re: .NET Blazor
#209Earlier quoted context omitted.
Let's say it does: It leaves behind a WebAPI backend that [new hotness] can utilize. WebAPI is an agnostic protocol. What does Blazor leave behind? Nothing reusable at all. It is a proprietary server hosting proprietary connections via proprietary pipeline. Plus sometimes inscrutable WebAssembly. Just go ask all the companies STILL stuck on Web Forms or Silverlight how that worked out for them the last times? Exactly…
Best practices would dictate that you still build WebAPIs for your Blazor apps, to avoid that potentially happening. It will also give you a clean separation of concerns in your application. Even when I build a traditional MVC application, I still built out my API as a separate layer so I can change out the front-end in the future.
Re: .NET Blazor
#210Earlier quoted context omitted.
Coming from the other side, this compatibility is why NodeJS is still very popular on the back-end. It makes sense for companies to try and stick to one programming language and / or ecosystem, else you end up with two disciplines within your company. http://boringtechnology.club/ 's slides show the problem pretty well. I'm not saying companies should stick to one technology, since the "golden hammer" is also not a g…
Blazor is the definition of boring technology through and through. Use it in MVC mode and get ergonomics that date back to the early 2000s with a hiring pool so deep you can't ever find the bottom of it
- Unknown unknowns (since it hasn't been out for as long and battle-tested by as many people)
- Shiny new tech (one could argue that C# is old, but that's a small part of the experience of a new and shiny API)