Live data from Hacker News

.NET Blazor

dusted.codes

161–170 of 302 posts

Re: .NET Blazor

#161
post #108

Honestly I'm pretty happy with just the stack: server html jsx templates + htmx boost + css view transitions. It's simple, easy to troubleshoot, fast to build, and crucially provides most of the important benefits of a SPA (seamless updates) without hardly any frontend JS.

Wanted to give htmx a try. I have a form, in which multiple text editors can be added. Apparently here we need an endpoint to deliver the extra field and I can tell htmx where to append it, so some extra work but okay. Then the user should be able to click a button and the additional text editor should disappear. > Oh for that you need this custom language called hyperscript, it's so easy to get st... no.

You don't need hyperscript, you can just do it with Javascript.

Re: .NET Blazor

#162

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

What about the CPU usage? Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.

Honestly I'm afraid you don't know what you're talking about. Blazor just isn't that experience and hasn't been for awhile.

Re: .NET Blazor

#163

Earlier quoted context omitted.

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet. Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

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

Re: .NET Blazor

#164

Earlier quoted context omitted.

> It will load slowly, work slowly Why do you think this will be the case?

Well for Blazor Webassembly at least, you need to download the entire .NET runtime and WebAssembly isn't quite as fast as JS in browsers yet. Couple that with the fact that interoping with JS can be a lot more annoying than just using JS

.NET 8 is suppose to greatly improve AOT. Depending on your use case, you might be able to get around bundling the runtime entirely.

Re: .NET Blazor

#165
post #4

Earlier quoted context omitted.

Yeah and then why don’t devs learn to administer their own databases as well. While they’re at it, writing some QA test cases can’t be all that hard. Continuous integration is pretty straightforward to set up so that as well. To be fair, it’s rather formulaic to come up with UI designs as well. Also security, load balancing and requirement docs just take a little dabbling to learn.

What a weird post. How is that not your actual attitude? All of these things are worthwhile to learn. (I'm assuming you're being sarcastic.)

They are worth while to learn but if you work for a corporation and they gradually cut people while loading you up with more and more work you’d get sour too.

Re: .NET Blazor

#166
post #162

Earlier quoted context omitted.

What about the CPU usage? Facebook loads a lot of information. I don't think we should be comparing the download size of a hello world app with loading dozens of images on a facebook feed.

Honestly I'm afraid you don't know what you're talking about. Blazor just isn't that experience and hasn't been for awhile.

Well color me convinced!

Re: .NET Blazor

#167

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.

They don't kill it, they just tie it up in the basement and pretend it never existed.

Re: .NET Blazor

#168

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.

https://www.theregister.com/2023/10/10/microsoft_says_vbscri...

Re: .NET Blazor

#169
post #153
post #114

Earlier quoted context omitted.

I enjoyed using ServiceStack. Write your data model in the C# API, run a tiny CLI command and it spits out Typescript definitions to match your data model. https://docs.servicestack.net/typescript-add-servicestack-re...

TypeLite used to offer something similar, but it's somewhat dead nowadays. OpenAPI client generators are probably what's popular today.

Yep. For frontend use, I think https://www.npmjs.com/package/openapi-typescript is the most widely-used/well-regarded, though https://www.npmjs.com/package/orval seems to me to have some nicer features like react-query support.

There are other options too, I'd just stay away from "_the_ openapi generator" (https://openapi-generator.tech/) which does a pretty poor job IMO.

Disclaimer: I'm the founder of a company doing SDKs commercially, but we don't focus on the frontend right now, and our free plan is still in beta.

Re: .NET Blazor

#170

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/packages/Swashbuckle

Post reply on HN