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

.NET 10

devblogs.microsoft.com

Post reply on HN
Print view View original

501–510 of 605 posts

Re: .NET 10

#501

Post by kant2002 »

AshleyGrant wrote: post #419
to11mtm wrote: post #410

Earlier quoted context omitted.

Blazor honestly is great for 'I need to write a simple backend control plane for whatever'. I.e. internal only stuff where you care about just shipping something functional and don't care too much how it all looks/etc. Further you go away from that circle, the less enticing it is.

Why is that? Do you speak from real-world experience? Not trying to push back. We're planning to use it for some new projects we have coming up on our team of .NET devs who can't seem to grok Angular or React and the entire ecosystem of tooling required, so I'm looking for reasons we shouldn't use it aside from Blazor being rather unpopular compared to Angular/React/other JS libs

As grandparent said, Blazor optimized for fast delivery. For public products you will have places where you should care about interactivity a lot. Their solution is interop with JS. You may try WASM but it’s definitely slow for UI.

WASM good for complicated tools, but you better probably with other language if you looking for next Figma.

Hybrid approach which is default have two issues. - round trip to the server. That’s not nice for interactivity and responsiveness. - hybrid hydration model is needlessly complicated. And again it will not fully solve your problem when you need to go extra mile.

Overall cold start for WASM require large payload, for Hybrid you need Websockets for updates. That sucks outside of cities or on junkie mobile. Not for public product.

Working with Blazor from Net Core 2.2

For internal tooling, or B2B where you don’t care that much is very efficient.

Re: .NET 10

#502

Post by Lord_Zero »

WorldMaker wrote: post #375
kopirgan wrote: post #93

Does this version improve or streamline the numerous options for web dev like Razor, Blazor etc? Anyone can comment on which is actually being popular

Same number of options. Razor is still the "default" and "Razor Pages" has a different brand name, but just means "Razor with more things in the main .razor file and fewer code-behind .razor.cs files and less of an MVC approach". Blazor mostly only matters if you want your frontend to also be Razor. At that point you've got the fork between Blazor using SignalR for HTML pipes from Razor files to the client versus Bla…

.razor is blazor, razor pages is .cshtml

Re: .NET 10

#503

Post by Loxicon »

jitbit wrote: post #2

For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%. We were even able to downgrade our cloud servers to smaller instances, literally. I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

As a startup I tried .NET (it was .NET 8), and it was great. The problem was the education around .NET.

So much DDD-this, Clean-that, CQRS-this, architecture-that.

I get all that stuff is for enterprise with bigger teams. But there wasn't much content/guidance on how to build apps 'quickly' for startups.

I am sure experienced .NET devs know this, but less experience .NET devs don't.

I ended up dropping it because I could work faster in PHP.

Re: .NET 10

#504

Post by Salgat »

nicoburns wrote: post #210
jitbit wrote: post #2

For us, every .NET upgrade since .NET 5 has gone surprisingly smoothly and reduced CPU/RAM usage by 10–15%. We were even able to downgrade our cloud servers to smaller instances, literally. I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma.

> I wish .NET was more popular among startups, if only C# could get rid of the "enterpisey" stigma. I tried .NET and liked C# as a language. But even though the language and runtime are now open source, it seemed like a lot of the recommended libraries were still commercially licensed, which was an immediate nope from me. I've never encountered that in any other ecosystem.

That's surprising. For the past two companies, all our library dependencies have been open-source. All our persistences, aws sdk, consul, kubernetes, github/bitbucket libraries, pdf generation, selenium testing, etc etc. I'd recommend giving C# another look, the proprietary stuff is mostly an artifact of back in 2015 when everyone was still on .NET Framework.

Re: .NET 10

#505

Post by Salgat »

eitally wrote: post #382
tracker1 wrote: post #325

Earlier quoted context omitted.

What libraries are you referring to? I really haven't used any commercial libraries at all since the .Net Core transition (and .Net 5+ as a result). Are you looking at older materials?

Just one example, but when I was running a .Net dev team we licensed the Telerik UI components. We ended up dropping them, but not until we had initiated a migration to Java/PG instead of C#/MSSQL. After we moved to Java everything standardized of a set of FOSS libraries for various things.

I'm not sure how that applies in this situation, since you're choosing to buy into a proprietary platform when plenty of open-source competitive options exist. That's the case for every language/tech stack.

Re: .NET 10

#506

Post by Salgat »

paride5745 wrote: post #160
parliament32 wrote: post #155

Earlier quoted context omitted.

I think the key problem is that a large number of startups are shipping software in containers, and dotnet requiring a CLR is not particularly well-suited for containerization. It's like the old school Java JVM model. You have to ship a copy of the runtime with every container, and if you're doing proper microservices it's an awful lot of overhead. Yes I'm aware MS makes it easy to build containers and even single ex…

Exactly this point. Go and Rust produce native binaries, I wish C# had an official native compiler without the big runtime needs of .Net.

Just an FYI, Go still bundles a runtime in its native binaries. C#'s AOT has restrictions on what works (largely reflection), but these same restrictions apply to Go (although Go applies these restrictions into how it's designed for the entire thing).

Re: .NET 10

#507

Post by Salgat »

parliament32 wrote: post #211
cachius wrote: post #164

Earlier quoted context omitted.

You might want to read https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Publishing your app as Native AOT produces an app that's self-contained and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.

And this sounds great until you get to the laundry list of restrictions. For us the showstopper was you can't use reflection.

These same restrictions exist for Go, the Go team just decided that it was easier to never support these features to begin with which has its pros and cons.

Re: .NET 10

#508

Post by mrcsharp »

raw_anon_1111 wrote: post #486
osigurdson wrote: post #395

Earlier quoted context omitted.

Every company should give developers $100 per year to donate to the open source project of their choosing. Right now the conditions are such that maintainers are incentivized to rug pull.

Hmm. My company gives everyone a $500 a year allowance for training and/or tools that we can use through OneRange. It shouldn’t be that hard to get approval to donate to an open source project. This is all hypothetical. There isn’t any open source project I depend on that isn’t backed by a large corporation.

I've tried that and got heavy push back from other developers funnily enough.

Re: .NET 10

#509

Post by phito »

josephg wrote: post #25
phito wrote: post #18

Earlier quoted context omitted.

OpenAPI and client generators solve this issue easily.

Still more work than just running the same code everywhere.

Still better than bringing JavaScript to the back end shudders

Re: .NET 10

#510

Post by troupo »

gf000 wrote: post #424
troupo wrote: post #362

Earlier quoted context omitted.

> while Java takes a while to design a bigger feature that will replace several smaller ones' use cases. Java is quite busy also implementing features that are small in other languages like text blocks. And I wish Java would design bigger features that would replace several "smaller ones", but that is almost never the case. It's almost always just a new big feature bolted on to the language that is almost there, but…

> Java is quite busy also implementing features that are small in other languages like text blocks. It's a small feature which is immediately understandable by anyone coming straight from Java 1.2, it doesn't materially increase the complexity of the language and is arguably one of the best implementation among different languages. So not really sure if it's a good counterpoint. Meanwhile records arrived several vers…

> It's a small feature which is immediately understandable by anyone coming straight from Java 1.2

You literally started with "Java takes a while to design a bigger feature that will replace several smaller ones' use cases".

But look, this small feature is not a one-off, and is actually useful because

> Meanwhile records arrived several versions ago

> Meanwhile C# has many many "one-off" features

Such one-off features like records and pattern-matching that C# also has? Or multiline strings that C# also has?

Or any other useful features directly impacting developer experience that you just dismiss out of hand because for some arbitrary reason you deem them "one-off" or small. Until they finally make their way into Java of course.

Post reply on HN