Live data from Hacker News

.NET Blazor

dusted.codes

201–210 of 302 posts

Re: .NET Blazor

#201

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.

That's because WinForms are in active development. But yes, for a while, it was baked.

Re: .NET Blazor

#202
post #171

Earlier 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…

As someone who suffers from this allergy, I'll chime in with 2 additional thoughts:

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

#203
I'm still weary of using Blazor in anything serious/long term. I've been burnt before by MS, leaving me with a tech that's both hard to continue using and hard to get rid of if need be.

Re: .NET Blazor

#204
Seems like an awful lot of complexity and significant compromises just to get to use C# instead of TS or JS.

I 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

#205

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.

Oh, that's handy, I thought MS had stopped supporting it. Good to know that it's still going. I thought they had dropped support in one of the .NET Core versions, before .NET 5+.

Re: .NET Blazor

#206

All 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.

Agreed. I mean really in the spirit of get er done the AS400 is the pinnacle of UI for these sorts of things. I've worked with other things, even WinForm apps, Access things, Excel sheets that were turned into portable apps, and of course web pages. Green screen allowed 99% of things to get done faster with 1000% less fuss.

https://en.wikipedia.org/wiki/Computer_terminal

Re: .NET Blazor

#207

The 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…

> Blazor is about the developer

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

#208
post #145

Earlier 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…

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

#209

Earlier 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.

So, in order to use Blazor safely, I need to develop and test everything twice. That's a death knell within itself. You just made my argument for me.

Re: .NET Blazor

#210

Earlier 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

Referencing the site, I would categorize Blazor under both:

- 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)

Post reply on HN