.NET 8 was released on November 14th at .NET Conf. The annual cadence of .NET releases is now well established. The improvements in .NET 8 span performance, native AOT compilation, Blazor architecture, and the new Aspire stack.
The .NET team has been focusing on performance as a competitive advantage. They publish benchmark comparisons with previous versions and other runtimes. .NET 8 shows 15-30% throughput improvements on common web workloads compared to .NET 7. This consistent investment in performance across .NET versions since .NET 5 has transformed .NET from a runtime with a mixed performance reputation to one of the fastest server-side runtimes available. The TechEmpower benchmark rankings for .NET have improved substantially with each version.
In my experience with .NET 6 and .NET 7, I have seen firsthand the impact of these performance improvements. For example, at my previous company, we saw a 20% reduction in latency for our web application after migrating from .NET 6 to .NET 7. This was largely due to the improvements in the .NET runtime and the optimizations made to our code.
Native AOT, or ahead-of-time compilation, means the runtime compiles to native machine code before deployment. This results in no JIT compilation overhead, startup times in milliseconds rather than seconds, and memory usage reduced by 30-50%. .NET 8 significantly expanded the framework surface area compatible with native AOT. This changes the economics for scenarios like AWS Lambda cold starts, Azure Container Apps scaling, and other latency-sensitive serverless use cases.
I have worked on several serverless projects, and one of the biggest pain points has been the cold start latency. With .NET 8's native AOT, we can now achieve sub-millisecond startup times for our AWS Lambda functions. This has enabled us to build more responsive and scalable applications.
Blazor in .NET 8 introduces a unified model that lets developers mix server-side and client-side rendering at the component level within the same application. A page can have components running on the server via SignalR, components running in the browser via WebAssembly, and static pre-rendered components, all composable in one Razor file. This resolves the previous either/or choice between Blazor Server and Blazor WebAssembly.
For new projects, .NET 8 is the obvious choice. For existing .NET 6 LTS projects, the migration path is well-documented, and the performance and native AOT benefits are worth the effort. .NET 6 LTS support ends in November 2024, so migration planning should start now. The migration from .NET 6 to .NET 8 is generally smoother than previous major version upgrades.
One thing to consider when migrating to .NET 8 is the potential impact on your development workflow. For example, we use a combination of Azure DevOps and GitHub Actions for our CI/CD pipeline. We had to update our build scripts and Azure DevOps pipeline to accommodate the changes in .NET 8. However, the benefits of the new features and performance improvements far outweighed the costs.
The .NET team's focus on performance and native AOT compilation has paid off. .NET 8's performance improvements are a significant achievement. The .NET team has been publishing benchmark comparisons with previous versions and other runtimes. These comparisons show .NET 8's throughput improvements on common web workloads.
The consistent performance investment across .NET versions since .NET 5 has moved .NET from a runtime with a mixed performance reputation to one of the fastest server-side runtimes available.
Native AOT compilation in .NET 8 significantly expanded the framework surface area that is compatible with native AOT. This expansion makes native AOT more practical for a wider range of applications.
The unified Blazor model in .NET 8 lets developers mix server-side and client-side rendering at the component level within the same application. This unified model provides more flexibility and resolves the previous either/or choice between Blazor Server and Blazor WebAssembly.