Microsoft hat die zweite Preview-Version für .NET 11.0 veröffentlicht und bringt darin unter anderem Neuerungen für die asynchrone Programmierung.

Die Schlüsselwörter async und await sind in vielen modernen Programmiersprachen verankert, zum Beispiel in Python seit 2015, in JavaScript seit 2017, in Rust seit 2019 und in Swift seit 2021. Auf die Frage „Wer hat es erfunden?“ muss man in diesem Fall sagen: Microsoft. Im Jahr 2012 erschienen diese beiden Schlüsselwörter zuerst in C# Version 5.0 und Visual Basic .NET Version 11.0. Sie vereinfachten die asynchrone Programmierung für Entwicklerinnen und Entwickler gegenüber vorher existierenden Konzepten und inspirierten danach viele andere Programmiersprachen.

Was für Entwicklerinnen und Entwickler einfach ist, ist unter der Haube aber bis heute komplex: In den .NET-Sprachen sind async und await bisher im Compiler als State Machines realisiert. In .NET 11.0 Preview 2 bringt Microsoft nun eine weiterentwickelte Version der .NET-Laufzeitumgebung Common Language Runtime (CLR), die nativ das Aussetzen und die Wiederaufnahme asynchroner Methoden unterstützt. Das erzeugt nicht nur weniger Overhead als die bisherigen State Machines, sondern ermöglicht schlankere Stack Traces und einfacheres Debugging.

Listing 1 zeigt vier asynchrone Methoden, die sich gegenseitig aufrufen.

using System.Diagnostics;
namespace NET11_Console.Runtime;
 
public class NET11_RuntimeAsync
{
 
 public async Task Run()
 {
  await MethodeEbene1();
 }
 
 async Task MethodeEbene1()
 {
  await Task.CompletedTask;
  await MethodeEbene2();
 }
 
 async Task MethodeEbene2()
 {
  await Task.CompletedTask;
  await MethodeEbene3();
 }
 
 async Task MethodeEbene3()
 {
  await Task.CompletedTask;
  Console.WriteLine(new StackTrace(fNeedFileInfo: true));
 }
 
}

Listing 1: Verkettung asynchroner Methoden

Bisher sah man als Ergebnis von Listing 1 die State Machine im Stack Trace:

   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in 
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3()
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2()
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in 
 h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1()
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
   at
 System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[TStateMachine](TStateMachine&
 stateMachine)
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run()
   at Program.
$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8

Mit der neuen Laufzeitunterstützung für Asynchronität ist der Stack Trace deutlich kompakter:

at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene3() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 27
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene2() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 21
   at NET11_Console.Runtime.NET11_RuntimeAsync.MethodeEbene1() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 15
   at NET11_Console.Runtime.NET11_RuntimeAsync.Run() in 
h:\git\ITVDemos\NET11\NET11_Console\Runtime\NET11_RuntimeAsync.cs:line 9
   at Program.
$(String[] args) in h:\git\ITVDemos\NET11\NET11_Console\Program.cs:line 8

Auf dieser Basis konnte Microsoft auch das Debugging-Erlebnis verbessern, siehe Pull Request „Runtime support for breakpoints and stepping“ auf GitHub.

Allerdings erfordert die neue Unterstützung für Asynchronität in der Laufzeitumgebung aktuell noch, dass diese Neuerung in der Projektdatei separat aktiviert wird, siehe Listing 2.

 
 
  net11.0
  …
 
 
 
 
   runtime-async=on
   true
 

Listing 2: Aktivierung der Asynchronität in der Laufzeitumgebung per Projekteinstellungen

Alle TAR-Formate

Das TAR-Archivformat beherrscht .NET seit der Version 7.0 mit den Klassen TarFile, TarEntry, TarReader und TarWriter im Namensraum System.Formats.Tar. Bei der Erstellung einer TAR-Datei mit TarFile.CreateFromDirectory() und TarFile.CreateFromDirectoryAsync() wurde als Archivformat immer das PAX-Format (POSIX.1-2001) verwendet. Entwicklerinnen und Entwickler haben seit .NET 11.0 Preview 2 die Möglichkeit, alle vier TAR-Formate zu wählen: TarEntryFormat.V7 (das ursprüngliche TAR-Format), TarEntryFormat.Ustar (Unix Standard TAR), TarEntryFormat.Gnu und TarEntryFormat.Pax.

Dies geschieht durch den zusätzlichen Parameter mit einem Enumerationswert aus TarEntryFormat:

TarFile.CreateFromDirectory("d:\Export", @"t:\archiv.gnu.rar",
  includeBaseDirectory: true, TarEntryFormat.Gnu);

Ein wesentlicher Unterschied zwischen den TAR-Formaten sind die maximalen Dateilängen: V7 erlaubt nur maximal 100 Zeichen für den Namen eines Eintrags. Bei USTAR sind es 256 Zeichen. Bei GNU und PAX ist die Länge von Dateinamen unbegrenzt. Bei USTAR ist die Dateigröße auf 8 GB beschränkt.

MinBy() und MaxBy() für Datenbankzugriffe

Die LINQ-Operatoren MinBy() und MaxBy() hat Microsoft bereits in .NET 6.0 eingeführt. Anders als die schon seit der ersten LINQ-Version in .NET Framework 3.5 verfügbaren Operatoren Min() und Max() liefern MinBy() und MaxBy() nicht nur den Minimal- bzw. Maximalwert selbst, sondern das ganze umgebende Objekt mit. Bisher waren MinBy() und MaxBy() nur in LINQ-to-Objects einsetzbar. Das ändert sich nun in .NET 11.0: Auch Entity Framework Core kann diese LINQ-Operatoren in SQL-Befehle umsetzen, siehe Listing 3.

var ctx = new DA.WWWings.WwwingsV1EnContext();

// Min vs. MinBy()
var wenigsteFreiePlaetze = ctx.Flights.Min(x => x.FreeSeats);
CUI.H1("Der Flug mit den wenigsten Plätzen hat " + wenigsteFreiePlaetze + " freie Plätze");
var flugMitDenWenigstenFreienPlaetzen = ctx.Flights.MinBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenWenigstenFreienPlaetzen);

// Max() vs. MaxBy()
var meisteFreiePlaetze = ctx.Flights.Max(x => x.FreeSeats);
CUI.H1("Der Flug mit den meisten freien Plätzen hat " + meisteFreiePlaetze + " freie Plätze");
var flugMitDenMeistenFreienPlaetzen = ctx.Flights.MaxBy(x => x.FreeSeats);
Console.WriteLine(flugMitDenMeistenFreienPlaetzen);

Listing 3: MinBy() und MaxBy() in Entity Framework Core 11.0

Während der LINQ-Operator Min() die MIN()-Funktion in SQL nutzt

SELECT MIN([f].[FreeSeats])
      FROM [Operation].[Flight] AS [f]

erstellt MinBy() eine sortierte Datensatzmenge und liefert den obersten Datensatz mit TOP(1) zurück:

SELECT TOP(1) [f].[FlightNo], [f].[Airline], [f].[Departure], [f].[Destination], 
[f].[FlightDate], [f].[FreeSeats], [f].[Memo], [f].[NonSmokingFlight], [f].[Pilot_PersonID], 
[f].[Seats], [f].[Timestamp]
      FROM [Operation].[Flight] AS [f]
      ORDER BY [f].[FreeSeats]

Datenübergabe zwischen HTTP-Anfragen mit TempData

Die in .NET 8.0 eingeführte Blazor-Variante Static Server-Side Rendering (SSR) ist den vorherigen Ansätzen für die Erstellung von Multi-Page-Apps im modernen .NET (ASP.NET Core Model-View-Controller (MVC) und ASP.NET Core Razor Pages) überlegen, hinsichtlich des Komponentenmodells, der Razor-Syntax und des partiellen Seitenaustauschs. Allerdings gab es bis dato auch einige Funktionen in MVC und Razor Pages, die Blazor SSR nicht beherrschte. Dazu gehören das Caching von Seitenteilen, erweiterbare Bedingungen für Routenparameter und die Datenübergabe zwischen HTTP-Anfragen mit dem TempData-Objekt (siehe GitHub-Issue). Letzteres ist nun in .NET 11.0 Preview 2 möglich. Die Datenspeicherung erfolgt wahlweise als Cookie (CookieTempDataProvider) oder im Session Storage (SessionStorageTempDataProvider) des Webbrowsers.

Anders als bei MVC und Razor Pages ist TempData aber keine Property der Basisklasse, sondern muss als Cascading Parameter explizit konsumiert werden, siehe Listing 5. Dabei ist zu beachten, dass TempData wie bei MVC und Razor Pages nur Zeichenketten abspeichern kann, das heißt, komplexe Objekte müssen Entwicklerinnen und Entwickler selbst serialisieren, siehe Listing 4.

@page "/Registration"
@using BlazorSSRSamples
@using Newtonsoft.Json
@inject NavigationManager NavigationManager
 

 
 

  Ihr Name: 
   reg.Name)" />
 
 

  Ihre E-Mail-Adresse: 
   reg.EMail)" />
 
 Bestellen

 
@code {
 [SupplyParameterFromForm]
 RegistrationData reg { get; set; } = new();
 
 [CascadingParameter]
 public ITempData? TempData { get; set; }
 
 private string? message;
 
 private void HandleSubmit()
 {
  TempData!["Message"] = "Registrierung  erfolgreich übermittelt!";
  TempData!["Reg"] = System.Text.Json.JsonSerializer.Serialize(reg); // speichert nur Strings
  TempData!["RegInfo"] = DateTime.Now.ToString(); 
  NavigationManager.NavigateTo("RegistrationConfirm", new NavigationOptions() { ForceLoad = true });
 }
}

Listing 4: TempData in Blazor-SSR-Seite befüllen

@page "/RegistrationConfirm"
@using BlazorSSRSamples
@inject NavigationManager NavigationManager
 
@message
 
@if (reg.HasValue)
{
 
Ihre Daten:
@reg.Name
@reg.EMail
}
 
@if (regInfo.HasValue)
{
 
Registriert am:
@regInfo
}
 
@code {
 [CascadingParameter]
 public ITempData? TempData { get; set; }
 
 private string? message;
 private string? regInfo;
 BlazorSSRSamples.RegistrationData? reg { get; set; } = new();
 
 protected override void OnInitialized()
 {
  message = TempData?.Get("Message") as string ?? "No message";
  reg = System.Text.Json.JsonSerializer.Deserialize(TempData?.Get("Reg").ToString());
  regInfo = TempData?.Get("regInfo") as string;
 }
}

Listing 5: TempData in Blazor-SSR-Seite auslesen

Geplant für kommende Preview-Versionen ist, dass das Auslesen von Daten aus TempData über eine Annotation [SupplyParameterFromTempData], mit der man eine Property annotieren kann, vereinfacht wird, siehe Pull Request.

Weitere Neuerungen in .NET 11.0 Preview 2

Laut den Release Notes von .NET 11.0 Preview 2 gibt es folgende weitere Neuerungen:

• Der in ASP.NET integrierte Webserver Kestrel lehnt nun ungültige Anfragen schneller ab, weil Microsoft intern auf das Auslösen einer BadHttpRequestException verzichtet und stattdessen eine Struktur zurückgibt. Das verbessert laut Microsoft den Durchsatz um 20 bis 40 Prozent bei Angriffen via Port Scanning oder mit fehlerhaften Anfragen.
• .NET-Core-basierte WebAPIs unterstützen jetzt die Open API Specification in der Version 3.2. In .NET 10.0 war es Version 3.1.1.
• Für die Erstellung von Web-Worker-Projekten gibt es nun eine eigene Projektvorlage „.NET Web Worker“ in Visual Studio beziehungsweise an der Kommandozeile: dotnet new webworker. Dabei entsteht eine DLL, die in Blazor-WebAssembly-basierten Anwendungen genutzt werden kann.
• Bei Entity Framework Core kann man nun für SQL Server die dort eingebaute Volltextsuche via Fluent API konfigurieren:

modelBuilder.Entity(b =>
{
 b.HasFullTextIndex(e => new { e.Titel, e.Text})
     .HasKeyIndex("PK_FullTextEntity")
     .HasLanguage("Titel", "German")
     .HasLanguage("Text", "German");
});

• Ebenso steht in Entity Framework Core die Vektorsuche mit der SQL-Server-2025-Funktion VECTOR_SEARCH() via LINQ-Operation VectorSearch() zur Verfügung:

var sqlVector = new SqlVector(EmbeddingsUtil.Get(suchBegriff));
  var q =  ctx.TexteSet.VectorSearch>(b => b.Embedding, sqlVector, "cosine", topN: 5);

Dabei ist zu beachten, dass man VECTOR_SEARCH() auch in der stabilen Version von SQL Server 2025 erst via SQL-Befehl aktivieren muss

ALTER DATABASE SCOPED CONFIGURATION SET PREVIEW_FEATURES ON

und in .NET die Warnung „EP9105“ deaktivieren muss:

#pragma warning disable EF9105 // Type is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.

• In .NET MAUI wurde das Steuerelement
verbessert. Die Syntax ist nun kompakter.

Außerdem kann man Elemente auf der Karte (Polygon, Polyline, Circle) nun per IsVisible und ZIndex steuern. Zudem gibt es Click()-Ereignisse auf diesen Elementen.

• Auch .NET-MAUI-Anwendungen für Apple-Betriebssysteme (iOS, tvOS und Mac Catalyst) können nun auf der .NET Core Runtime statt Mono laufen. Seit .NET 10.0 war dies experimentell für MAUI-Anwendungen auf Android möglich. Auch die Apple-Implementierung der .NET Core Runtime gilt aber als experimentell. Die Anwendungen werden aktuell durch die Umstellung aber größer und das Debugging ist noch eingeschränkt.
• Die Größe der Container Images von .NET SDK 11.0 Preview 2 ist gegenüber .NET 11.0 Preview 1 um 41 bis 44 MB (bis zu 17 Prozent) verkleinert, da Microsoft nun Hard Links für doppelte Dateien verwendet. Das gilt auch für die Installer für Linux und macOS.

Sonst nichts Neues

Laut den Release Notes von .NET 11.0 Preview 2 gibt es in dieser Vorschauversion keine Neuerungen für die Sprachsyntax von Visual Basic und C# sowie das GUI-Framework Windows Forms. Bei der Windows Presentation Foundation (WPF) gibt es nur einen Bugfix.

Ausblick

.NET 11.0 soll im November 2026 erscheinen und einen Standard-Term Support von zwei Jahren erhalten. Bis dahin können Entwicklerinnen und Entwickler mit fünf weiteren Preview-Versionen von April bis August sowie jeweils einer Release-Candidate-Version im September und Oktober rechnen. heise developer wird jeweils berichten.

(mai)

Nvidia folgt dem Hype um den KI-Agenten OpenClaw und entwickelt eine Plattform namens „NemoClaw“ speziell für Unternehmen, berichtet Wired unter Berufung auf mehrere Personen, die mit Nvidias Plänen vertraut sein sollen. Die Plattform soll es Unternehmen ermöglichen, KI-Agenten einzusetzen, die Aufgaben für die eigene Belegschaft übernehmen.

Da es sich um ein Open-Source-Projekt handeln soll, wird der Code nicht nur Unternehmen zur Verfügung stehen. Nvidia will Unternehmenspartnern jedoch zusätzliche Werkzeuge für Sicherheit und Datenschutz bereitstellen, um zentrale Risiken beim Einsatz autonomer KI-Agenten zu reduzieren. Außerdem könnten sie laut Bericht frühzeitig und kostenlos Zugang zu „NemoClaw“ erhalten, wenn sie sich an der Entwicklung beteiligen.

Der Chiphersteller habe „NemoClaw“ bereits bei verschiedenen großen Softwareanbietern beworben. Der Wired-Bericht nennt Salesforce, Cisco, Google, Adobe und CrowdStrike als mögliche Partner. Ob aus den Gesprächen konkrete Kooperationen hervorgegangen sind, sei allerdings noch unklar.

Strategische Öffnung bei Nvidia?

Dem Bericht zufolge sei es wahrscheinlich, dass mögliche Partner die Plattform unabhängig davon nutzen können, ob ihre KI-Agenten auf Nvidia-Chips laufen.

Der Verzicht auf eine Bindung an Nvidia-GPUs ist eher ungewöhnlich für Nvidia. Bisher stützte sich das Softwareökosystem des Konzerns stark auf die proprietäre Plattform CUDA, die Entwickler faktisch an Nvidia-Hardware bindet und dem Unternehmen einen wichtigen Wettbewerbsvorteil verschafft hat.

Der Open-Source-Ansatz ist ebenfalls bemerkenswert, auch wenn es dafür bereits Beispiele gibt: So veröffentlichte Nvidia im Dezember mit Nemotron 3 Nano ein KI-Modell, das fast vollständig Open Source ist.

„NemoClaw“ könnte ein weiterer Schritt in Richtung Öffnung sein, der womöglich durch den zunehmenden Erfolg offener KI-Modelle motiviert ist. Viele Start-ups und Entwickler nutzen solche frei verfügbaren Modelle, um neue Anwendungen zu testen oder eigene Produkte darauf aufzubauen.

Hinzu kommt, dass große KI-Anbieter zunehmend eigene Chips entwickeln oder entwickeln lassen, um sich langfristig unabhängiger von Nvidia zu machen. In dieses Bild passt auch Nvidias Partnerschaft mit dem Start-up Groq, das sogenannte Inferenz-Chips entwickelt. Diese sind weniger für das Training von KI-Modellen gedacht, als dafür, bereits trainierte KI im Alltag möglichst schnell und energieeffizient antworten zu lassen.

Das Wall Street Journal berichtete kürzlich, dass Nvidia auf der kommenden Entwicklerkonferenz GTC einen eigenen Inferenz-Chip auf Basis eines Groq-Designs vorstellen könnte. Womöglich gibt es dann auch Konkretes zu „NemoClaw“ zu erfahren. Die Konferenz findet vom 16. bis 19. März in San José statt.

OpenClaw zeigt Chancen und Risiken autonomer KI-Agenten

Der KI-Agent OpenClaw sorgte Anfang des Jahres für große Aufmerksamkeit in der KI-Szene. Das Open-Source-Projekt des Entwicklers Peter Steinberger unterscheidet sich deutlich von klassischen KI-Chatbots, die meist nur auf einzelne Eingaben reagieren und Antworten generieren. Der auf einem lokalen Rechner laufende OpenClaw kann dagegen mehrstufige Aufgaben selbstständig ausführen und dabei verschiedene Programme oder Online-Dienste steuern.

Gleichzeitig birgt dieser Ansatz auch Risiken, da die mächtigen KI-Agenten mit weitreichenden Zugriffsrechten potenziell Schaden anrichten können, wenn sie fehlerhaft arbeiten oder manipuliert werden. Die chinesische Cybersicherheitsbehörde hat deshalb erst kürzlich Behörden, Staatsbetrieben sowie Banken davon abgeraten, den KI-Agenten auf Arbeitsgeräten zu installieren. OpenAI nahm Steinberger im Februar unter Vertrag, OpenClaw ist aber weiterhin Open Source.

(tobe)

Das quelloffene JavaScript-Framework Astro hat Version 6.0 erreicht. Darin sind zahlreiche Neuerungen enthalten, unter anderem eine Überarbeitung des Entwicklungsservers und eine integrierte Fonts-API. Die bestehenden Features Live Content Collections und Content-Security-Policy-API sind nun stabil. Als experimentelle Funktion steht ein neuer Rust-Compiler als Nachfolger des Go-basierten Compilers in den Startlöchern.

Rust-Compiler: vom Experiment zum geplanten Standard

Wie das Astro-Team ausführt, begann der neue Rust-Compiler zunächst nur als KI-Experiment. Aber da er sich als schneller und teils sogar zuverlässiger erwiesen hat als der Go-Compiler, soll er in Zukunft zum Standard werden. Interessierte können ihn bereits ausprobieren, indem sie das rustCompiler-Flag aktivieren und das entsprechende Package installieren (npm install @astrojs/compiler-rs). Auch an weiterem Rust-basierten Tooling arbeiten die Astro-Entwickler nach eigenen Angaben bereits.

Neue Fonts-API und stabile Funktionen

In Astro 6.0 finden Entwickler eine integrierte Fonts-API vor. Damit lassen sich Fonts mithilfe lokaler Dateien oder Anbietern wie Google oder Fontsource konfigurieren. Anschließend übernimmt Astro weitere Arbeiten wie das Herunterladen und Caching für Selbst-Hosting oder das Generieren optimierter Fallbacks.

Bereits seit Astro 2.0 sind Content Collections mit an Bord. Damit können Entwicklerinnen und Entwickler Sets an strukturierten Inhalten in Astro-Projekten verwalten, beispielsweise Blogeinträge oder Produktbeschreibungen. Astro kann hierfür mit lokal gespeicherten Daten in den Formaten Markdown, MDX, Markdoc, YAML, TOML oder JSON umgehen. Bisher erforderten Content Collections einen Rebuild, wenn sich Inhalte änderten.

Das gehört dank der nun stabilen Live Content Collections der Vergangenheit an: Sie erfassen den Content zur Request-Zeit und erlauben eine unverzügliche Aktualisierung von Inhalten ohne Rebuild. Astro-Developer können eine Live-Quelle in der Datei src/live.config.ts mittels defineLiveCollection() festlegen. Parallel zu den Live Content Collections lassen sich im gleichen Projekt auch die klassischen Content Collections nutzen.

Ebenfalls stabil ist ein sicherheitsrelevantes Feature, die Content-Security-Policy-API. Laut dem Astro-Team ist Astro eines der ersten JavaScript-Metaframeworks, die integrierten Support für Content Security Policy (CSP) für statische und dynamische Seiten sowohl in Server- als auch Serverless-Umgebungen bieten.

Cloudflare-Fokus: Update für astro dev

Astros Entwicklungsserver astro dev wurde überarbeitet, um mit Runtimes abseits von Node.js, wie Cloudflares workerd-Laufzeit, zusammenzuspielen. Dazu kommt Vites neue Environment API zum Einsatz. Da der Dev-Server ursprünglich auf Node.js ausgelegt war, konnten Developer unter Verwendung anderer Runtimes wie Cloudflare Workers, Bun oder Deno die eigentliche Produktionslaufzeit bisher nicht während der Entwicklung einsetzen. Nun können sie während der Entwicklung eine benutzerdefinierte Laufzeitumgebung auswählen. Dev-Server und Build-Pipeline verwenden in Astro 6.0 die gleichen Codepfade.

Diese Überarbeitung entspringt der offiziellen Partnerschaft mit dem Unternehmen Cloudflare, das im Herbst letzten Jahres Astro mit 150.000 US-Dollar unterstützte. Im Januar 2026 wurde Astro von Cloudflare übernommen, soll jedoch Open Source bleiben.

Weitere Details zu den Neuerungen in Astro 6.0 lassen sich dem Astro-Blog entnehmen.

(mai)