We've been experimenting with NativeAOT for years with ASP.NET Core (which does runtime code generation all over the place). The most promising prototypes thus far are:

- https://github.com/davidfowl/FasterActions - https://github.com/davidfowl/uController

They are source generated version of what ASP.NET does today (in both MVC and minimal APIs). There are some ergonomic challenges with source generators that we'll likely be working through over the coming years so don't expect magic. Also its highly unlikely that ASP.NET Core will not depend on any form of reflection. Luckily, "statically described" reflection generally works fine with NativeAOT.

Things like configuration binding, DI, Logging, MVC, JSON serialization all rely on some form of reflection today and it will be non-trivial to remove all of it but we can get pretty far with NativeAOT if we accept some of the constraints.

As of right now, we're trying to make sure "motivated people" can play with it, but it's not something that is supported by ASP.NET Core or EF at the moment. https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativea...

PS: Some of the challenges https://github.com/dotnet/aspnetcore/issues/42221

Thanks for your hard work with the .NET community David.

Thanks for using .NET!

Actually system text json does work with source generators and di can work with source Generators aswell.

Thanks for telling me :). On a serious note though, anything can work with source generators but it doesn't match the style of coding that we'd like (moving everything to be declarative isn't the path we want to go down for certain APIs). Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator (if we wanted to keep things NativeAOT safe). Right now most of the APIs you use in ASP.NET Core are imperative and source generators cannot change the callsite so you need to resort to method declarations and attributes everywhere.

That's not an optimization, that's a programming model change.

> Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator

This is the biggest challenge I see, there are times where either Expression.Compile or T4 still 'feels' cleaner than sourcegen.

Well in system text json the api keeps the same and you „only“ need to pass an autogenerated meta object its basically the same api you just need to pass another object instead of an generic Parameter. But yeah its a change.

It’s incredibly exciting to follow your work and the teams!

Thank you!

JamesNK also answered this. We started off with just nuget packages, it was beautiful for about 5 minutes until we ended up with ~300 in the default project. Then physics kicked in, slower build times, slower compilation times, slower intellisense. All of those old O(N/N^2) algorithms started to show up on profiles and we had to do something about it. That was just the practical performance side of things, then there was the customer confusion around which packages had which APIs. We offered a .NET buffet that customers hated. On top of that, the versioning got nuts. Each of those packages could in theory version independently, who is going to test all of those combinations of things? What happens when you need tot publish ~300 + packages to your server deployment because you didn't want to "install the framework"? You'd be complaining that they were too many assemblies (which people did). Amplify that by deploying these binaries to the same physical machine when running multiple .NET Core applications there (very popular for IIS setups). We pre-JIT (ready to run) the core libraries and ASP.NET to improve startup time, that makes the assemblies bigger (as they contain both native code and IL), this makes your applications bigger by default.

We got LOTS of feedback that this was all really terrible and we listened.

We did this from .NET Core's inception to .NET Core 3.0 when we pulled the plug. We set things up so that the base install/platform/framework was not composed of packages but framework references. We merged several assemblies together to get rid of some of the unnecessary layering. We invented shared frameworks so that people could install the framework once and run lots of applications using shared libraries so that:

- Customers have faster publish times as you only need to deploy your application bits, the framework can be pre-installed - Loading the same dll on disk into multiple processes allows for more virtual memory sharing (a handy performance optimization) - We could version the set (.NET, ASP.NET Core) as a coherent unit - We could pre-JIT (R2R) the built in stuff so it's installed on the machine once and usable by many apps.

As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.

PS: This stuff is harder than it looks on the surface and we spend lots of time and take lots of care designing it (making the typical tradeoffs you make when doing software engineering).

@David, thanks, and completely aligned on why we don't use nuget packages anymore.

> As for being intuitive, the default experience is to use the Web SDK. I didn't even get into SDKs but it does more than default the framework reference. It also exposes capabilities that tooling use to light up behaviors in the build and in the IDE.

It is these "does more than default framework reference" are precisely the things in discussion here. All of these hidden functionalities and dependencies are like a black box. What's the difference between what James shared here and the default Sdk=...Web, then? It's the lack of uniformity, where "ASP.NET is a first class citizen" rather than just another piece of the ecosystem that is a turn off.

Compared to other ecosystems, for example: Go, Rust, even Java for example, where everything is just code that one can pull in, and the customization is in the code, not the runtime/JVM.

This is almost the correct answer, https://news.ycombinator.com/item?id=30667145 is more accurate.

One thing I'd like to add as a potential differentiator as well is that YARP runs very well on Windows and because it's build on ASP.NET Core, can run inside of IIS and directly on HTTP.sys as well (which means we can take advantage of cool features like http.sys request delegation where possible https://github.com/microsoft/reverse-proxy/commit/b9c13dbde9...). This means you get platform portability AND deep platform integration for free.

It supports WebSockets, HTTP/2 (including gRPC) and HTTP/3 (with .NET 6+).

This is a good one. Will remember it for the next project

Extensibility via C# for custom rules. It's not as attractive if you have nothing to customize but we've found lots of developers want to write code to influence the proxying. If you're a .NET developer or you don't like writing LUA (what nginx uses) then you can use YARP.

This is a "premiere use case" we've seen people use YARP for.

Typically platform teams like ours (.NET person here) gets to see what a wide variety of teams are doing or are trying to do. YARP was a case of that happening and it felt like a good opportunity to build something low level and extensible that could help other teams at Microsoft, the OSS community and could directly drive improvements into the .NET networking stack.

These proxies are within reach performance wise. One of the reasons we did YARP was to push the performance boundaries of asp.net core and http client. It will also replace many of the front ends that were built in house (not many want to write lua or c to modify the routing logic).

It’s new, give it some time

The downside of yet another anything is that unless it is an order of magnitude better than what already exists is that it will split the available human resources. Not only that, it also isolates the users to within their own language/framework, promoting a monoculture (now there's a pun that could be made here).

While it's better than other in-house alternatives, it's not better for the entire ecosystem as a whole. The need for hyperlocal reverse proxies is a problem on its own, generally only solved this way due to organisational dysfunction or a very niche requirement.

Maybe? Turns out nginx, traefik and others came out after nginx and have gained some mindshare. Of course YARP has the "Microsoft" problem but I think the programmability is actually huge non-niche benefit (at least in what we've seen in practice)