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

221–230 of 302 posts

Re: .NET Blazor

#221

Post by renegade-otter »

yread wrote: post #217
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…

I consider myself more of a backend person but I feel I can deal with JS much easier than CSS. I learnt both in 15 yrs ago so compatibility with IE was crucial. Slap jquery on, stick to style guidelines so that variables are named consistently, avoid dependencies and it feels okish. There isn't anything like that to help with CSS though.

As a backend dev primarily, learning CSS Grid really helped me filter out a lot of the BS.

It's a UI framework that is 20 years too late, and with "lean" JS frameworks that are emerging, a lot of this UI development legacy can die a horrible death as far as I am concerned.

Re: .NET Blazor

#222

Post by switch007 »

JackMorgan wrote: post #170
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…

I use swashbuckle and swagger-typescript-api to automatically scrape my controllers and generate API calls and TS types every time I rebuild. No hassle or overhead at all. No need for converters or anything. I've been using this now for several projects, it's a great way to have all the power of TS for client side and C# for server side. https://www.npmjs.com/package/swagger-typescript-api https://www.nuget.org/packa…

N.B. the last commit/release for Swashbuckle was Jan this year.

https://github.com/RicoSuter/NSwag might be a better choice for a new project. It look much more maintained and active than Swashbuckle

Re: .NET Blazor

#223

Post by squidsoup »

KronisLV wrote: post #75
sebastianbk wrote: post #27

In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. So, when I started my own company last year, I quickly jumped on Blazor Server, which has been an absolute joy from a dev…

> In my previous job, I was on a team using Vue.js for the frontend and ASP.NET Core for the backend. I quickly got tired of the internal plumbing, package management, build configuration, and all the other things not related to the actual functionality of the app that Vue (v2) required at the time. Oh, hey, I have something relevant to say about this setup. Currently I'm bootstrapping a platform with .NET Core on th…

> it comes at a cost of duplicating your data model and the interfaces between them

Not the case if you use graphql.

Re: .NET Blazor

#224

Post by [deleted] »

jmnicolas wrote: post #157
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?

Contrary to Google, MS never kills any tech. You can still develop Winforms apps today.

[deleted]

Re: .NET Blazor

#225

Post by zerr »

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?

Re: .NET Blazor

#226

Post by feoren »

mythz wrote: post #40

I take the opposite view, as a recent Blazor convert since the just released .NET 8 we're now recommending Blazor for any new .NET Web App (excl. CDN Hostable, SSG websites). I was short on Blazor before .NET 8 and could only seriously recommend it for Internal Apps since the compromises for using either of Blazor's Server or WASM Interactivity delivered a poor UX for Intranet hosted Apps as covered by this post. How…

> Blazor SSR + Vue

I'm sorry, but WTF? You spend 5 paragraphs talking about how great Blazor Server-Side Rendering is and then throw a "+ Vue" right at the end? WTF? So it's not SSR at all!? How are you avoiding npm and JavaScript builds when you're literally using Vue? That little example app you showed has ~3500 lines of JavaScript in it ...

Re: .NET Blazor

#227

Post by BoorishBears »

mardifoufs wrote: post #65
BoorishBears wrote: post #26

Earlier quoted context omitted.

It's funny you're being downvoted, I've used Blazor on less important side projects and I love it for the same reasons, but a subset of HN hates it because their uBlock Origin no-Js anti-tracker cookieless oddball browsers choke on it. Interestingly enough Google's crawlers don't even choke on it: my fully SignalR based site was indexed soon after getting a spike in traffic without an issue. Does it annoy me that lea…

No, people hate it because it's a massive downgrade in UX, especially the wasm variant, just because backend devs don't want to use the right tools for the job. I'm fine with it in internal apps, but public facing apps using blazor would be horrible for the users, which is why it is thankfully very rare to see. Javascript seems downright lightweight and unbloated compared to shipping an entire dot net runtime for a c…

That's not how the right tool for the job works: the tool that results in the smallest bundle size and the most impressive web metrics is absolutely worthless if 99% of the value in what you're making is it existing and the creator of said tool doesn't feel like building out a SPA.

Of the tens of thousands of people who found my tool useful, the only people who ever complained where Hacker News users, and the tool simply would not exist if I had gone and wasted my time spinning up Next, realizing the app router is garbage, RSC has no place in most React apps, then going back to pages router, then rediscovering how awful NextAuth is, then...

Which is exactly how some of my otherwise interesting side projects die too.

Re: .NET Blazor

#228

Post by jongalloway2 »

DylanSp wrote: post #205
jmnicolas wrote: post #157

Earlier quoted context omitted.

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

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

Re: .NET Blazor

#229

Post by psadri »

Shameless plug: https://skymass.dev is a js/ts version of Blazor. It is a batteries-included, code-first solution for creating high quality business web apps by simply writing a single-dependency backend process. Please be gentle as it’s in beta.

Re: .NET Blazor

#230

Post by guhidalg »

littlecranky67 wrote: post #163
brtkdotse wrote: post #136

Earlier quoted context omitted.

> Well for Blazor Webassembly at least, you need to download the entire .NET runtime It's a one-time download that's smaller than the initial load of the Facebook feed

plus in LOB apps very likely to be in the browsers cache already. And dont forget buisness workstations are usually connected via at least 1GBit Ethernet.

I'm not who you're replying to but designing for excess resources is the kind of thinking that leads to slow software.

> And dont forget business workstations are usually connected via at least 1GBit Ethernet.

NOPE! More likely they are WiFi connected Dell shitboxes running Windows 11 with 8GB of memory, half of which is taken up by all the browser tabs, Teams, Office, and the 30 horrible little programs that IT deploys via group policy.

Speed matters. The user is probably running your code + 30 other things. Don't assume your page is the only thing they care about.

Post reply on HN