.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node). I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh
Reinventing how .NET builds and ships (again)
51–60 of 146 posts
Re: Reinventing how .NET builds and ships (again)
#52.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node). I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
Re: Reinventing how .NET builds and ships (again)
#53Earlier quoted context omitted.
Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…
We are also running into more and more performance issues with EF. There are ways to tune it but I am not sure if it’s worth learning this for EF or if it’s not better to just go for straight SQL. Seems MS has this tendency to create abstractions that then don’t work 100%. I see this with .NET too. Often you have to go down to Win32 for apps that are tightly coupled with Windows and hardware.
Re: Reinventing how .NET builds and ships (again)
#54Earlier quoted context omitted.
> I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem. Can you elaborate a bit? This article talks about internal machinery of building .net releases. What does that have to do with "this churn", whatever that is?
My guess is if you build with .NET Framework you can just forever run your builds, but if your source code is based on newer .NET you have to update to a new version each year, and deal with all the work in upgrading your entire project, which also means everyone in your team is also upgrading their dev environment, and now you have new things in the language and the runtime to deal with, deprecation and all that. Pl…
It's hard for me to imagine a version increment being much easier than this.
Re: Reinventing how .NET builds and ships (again)
#55.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node). I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh
Re: Reinventing how .NET builds and ships (again)
#56Re: Reinventing how .NET builds and ships (again)
#57Earlier quoted context omitted.
.Net need a "node" level of developer experience and perfomance of rust/zig since node/python ecosystem rewrite make it more perfomance than ever I cant see .net win againts those odds tbh
.NET has a far better developer experience than Node and is nearly as fast as Rust if written for performance, certainly much faster than Node or Python
Re: Reinventing how .NET builds and ships (again)
#58Earlier quoted context omitted.
This isn't really anything user facing. It's just yet again an example of why monorepos are better.
Anything is a monorepo if you submodule hard enough lol
Re: Reinventing how .NET builds and ships (again)
#59.NET was a solid choice for backend builds before Node became so popular (And .NET is generally more performant than Node). I hope this churn in .NET builds is temporary because a lot of people might be looking to go back to something stable especially after the recent supply chain attacks on the Node ecosystem.
Is nuget any different from npm
Re: Reinventing how .NET builds and ships (again)
#60I have a lot of respect for the .NET team. They often publish great in-depth articles and their pursuit for performance is relentless (e.g. see Kestrel and Entity Framework evolution). And ASP.NET is one of the few large projects which managed to survive a large breaking changes. Almost to Python 2->3 level. You had to change how your web app behaved completely if you relied on their magic session which worked hard t…
Last time I tried Entity Framework it was slow. Replaced it with Dapper and a simple custom migration system. This took database validation and seeding from 10 seconds to less than 2 seconds during startup on low powered hardware with SQLite. The queries created by Entity had pointless cascade of multiple join statements. I have been reaching for GO with simple tooling and HTTP back end. .NET is useful for other solu…