Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET Blazor

dusted.codes

Post reply on HN
Print view View original

271–280 of 302 posts

Re: .NET Blazor

#271

Post by abrookewood »

zerr wrote: post #225
kumarvvr wrote: post #113

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…

So is it like ASP.NET WebForms?

More like Elixir/Phoenix's Live View I would think.

Re: .NET Blazor

#272

Post by yCombLinks »

uticus wrote: post #206
SantiagoElf wrote: post #181

Earlier quoted context omitted.

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

My first job required maintaining a very old informix 4gl app. The trained users could fly in that thing! Seeing clunky webapps with a bunch of clunky laggy UI components doesn't seem worth it for trained internal users

Re: .NET Blazor

#273

Post by neonsunset »

devjab wrote: post #250
neonsunset wrote: post #141

Earlier quoted context omitted.

Previously from this account: https://news.ycombinator.com/item?id=38228674 The tldr of both the previous and this posts is OData being bad yet the author extends his grievances regarding it to the entirety of ecosystem.

It seems a little disingenuous of you not to mention how I never hide the fact that it's an issue with the batteries. I'd also say that considering how great OData's patch is with the modelbuilder it's actually EF that's being bad in this case. You could also point back to other posts like this one: https://news.ycombinator.com/item?id=37538333&p=3#37541652 Where I also point out other, similar issues with other part…

If you are having issues with EF Core, maybe it's not the tool's fault?

Re: .NET Blazor

#274

Post by progmetaldev »

Someone1234 wrote: post #235
progmetaldev wrote: post #212

Earlier quoted context omitted.

Do you not bother testing your JavaScript?

We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI. Your "question" is non-sequitur.

So you would build a solution that combined both using Blazor? I still don't understand, this is just like if you were to build a WebAPI and a front-end JavaScript SPA, except Blazor is your JavaScript SPA. You have your unit tests for your WebAPI, and you have your tests for your JavaScript SPA (in this case Blazor, but fill in Vue or React, etc.). You could then write integration tests if you wished, but there isn't any more testing or development process than if you were building a WebAPI with a traditional JavaScript SPA. Blazor is just affording you the ability to use C# rather than JavaScript.

If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.

Re: .NET Blazor

#275

Post by progmetaldev »

v-erne wrote: post #256
unsignedint wrote: post #232

Earlier quoted context omitted.

Silverlight's phase-out primarily stemmed from the browser ecosystem's shift away from plugins. It's worth noting that Silverlight 5 was supported until October 2021, a decade after its release, indicating substantial longevity despite the changing landscape.

Ok first thing first - allow me to vent my existential frustration with few off the cuff (mostly rhetorical) questions ... You call decade a substantial longevity? Is this some kind of a joke? Is your ability to assess being held hostage by js ecosystem expererience? But seriously - I expect a bit more from platform that could potentially waste my life and my venture. I am still happily supporting some Java (and JSF)…

The difference is that Blazor is built on web standards (WebAssembly), not a proprietary technology. Sure, Microsoft could discontinue support for Blazor, but WebAssembly will keep running. C#/Blazor are not the only technologies using WebAssembly. I personally wouldn't use Blazor for a public facing website, and would only use it for an internal LOB app where I know I can dictate what browser technologies can be used, as well as knowing the binary blob for the runtime will be cached in most users' browsers. I still use traditional MVC structure with C# for applications that will have a variety of users over different connection types, and use progressive enhancement with JavaScript for things that enhance the user experience (for example, creating multiple items of some type on screen, instead of only being able to create one at a time like with a standard form). The thing is, I've already separated out my application logic so that I can change the front-end technology at any time. That really shouldn't have anything to do with Blazor, and is just a way to make sure your application can adapt to future front-end technologies.

Re: .NET Blazor

#276

Post by progmetaldev »

DylanSp wrote: post #231
jongalloway2 wrote: post #228

Earlier quoted context omitted.

Presentation from .NET Conf 2023 last week with some of the new stuff: https://www.youtube.com/watch?v=N1weyWS_pL0

Thanks for linking that. The video description mentions they added WinForms to .NET Core in 3.0; maybe I was remembering the .NET Core 2.1/2.2 timeframe, when it wasn't supported in Core?

I believe prior to .NET Core 3.0, you could have a WinForms application in .NET Core, but the WinForms designer was not available in Visual Studio. While it was possible, having to build a GUI in WinForms without the designer is utter hell.

Re: .NET Blazor

#277

Post by progmetaldev »

password4321 wrote: post #183
osigurdson wrote: post #140

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?

Web Forms ("I'm not dead"), Silverlight, etc.

.NET Framework has not been EOL'd, so you can still build applications in WebForms. Silverlight was killed off by browsers no longer supporting plugins, that really wasn't a Microsoft decision. Flash is no longer available either, and had nothing to do with Microsoft.

Re: .NET Blazor

#278

Post by progmetaldev »

LaGrange wrote: post #270
codegeek wrote: post #142

Earlier quoted context omitted.

The tooling ecosystem around JS is nuts. Packages (npm etc) hardly have any backward compatibility. You install a package today. In 3 months, that code won't build. The errors want you to go take a cryptography course to understand WTF is happening. And I am not even talking about the language itself YET. ANd no, why should I be forced to use Typescript ? Yet another layer. And I did I get to the 100s of config files…

> You install a package today. In 3 months, that code won't build. Skill issue. Like I do that regularly. And I'm not even particularly great at frontend tech, so after 3 months I need to hit the docs to actually change anything. But the build pipeline works just fine. > And I did I get to the 100s of config files that need to be set just so I can run "npm build" ? ..."webpack.config.ts", "package.json" and "package-…

Your way of upgrading front-end tech, where you need to hit the docs, sounds exactly like moving from the different .NET technologies to the latest version. I still tend to build out classic MVC applications, and use JavaScript only for progressive enhancement. I've been able to move from .NET Framework to the different versions of .NET Core, and now just .NET. I just follow the documentation, Microsoft has great documentation on how to upgrade. It just sounds like you are more familiar with working with front-end tech, and I would hazard a guess that you are actually much better at it than you either let on, or believe you are (Impostor syndrome, I get it all the time until it's crunch time, and then you just get things done).

I'm not trying to convince you to change technologies, but if you're familiar with a specific process, it's always going to be easier to follow that process than something you're not familiar with. This is coming from someone that still uses Grunt for their front-end build pipeline. It's not the newest, but it's still well supported, and I know it very well and can pull off a lot with it.

Re: .NET Blazor

#279

Post by progmetaldev »

rqtwteye wrote: post #107
throwaway2990 wrote: post #97

Earlier quoted context omitted.

Xamarin for iOS and Android just works… Maui on the other hand is a turd. It’s such a pain to work with, workloads just plain suck. And if you install . Net 7 and your project targets 6, It will download .net 7 workloads and fail to build. Then 8 comes out and same problem. Have to pin the SDK.

And by the time Maui starts to mature and work, they will announce a new framework and the cycle starts again. I still don’t understand why they couldn’t keep working on WPF instead of cranking out a new framework every three years.

It's because WPF was too heavily tied to Windows technology.

Re: .NET Blazor

#280

Post by Capricorn2481 »

sebazzz wrote: post #251
Capricorn2481 wrote: post #152

Earlier quoted context omitted.

I have the complete opposite view. I'm a fullstack dev, so I'm comfortable using Javascript and a backend language. JS replacements like Blazor clearly serve backend engineers who don't want to deal with JS. That's fine, and it's a valid way of developing, but it's clear that using JS with C# is a more holistic way of developing.

I'm comfortable with Javascript. I'm not comfortable with constantly having to change and upgrade my code or build system for the next breaking change in Webpack or in an unreadable complex Typescript typing, or the spider web of React libraries. Doing nothing is not an option either, because that bites you in the ass as well because that newer Node runtime turns out not to support a deprecated md5 hash function the…

Why are you using md5 functions on the frontend? We're talking about using javascript for frontend
Post reply on HN