La feature più richiesta dalla community .Net e più precisamente quella Blazor, nella sua accezione WebAssembly, è la possibilità di effettuare una compilazione AoT (Ahead-of-Time). Questa era già in programma per il rilascio di .NET 5.0 ma per questioni legate alla situzione globale si è scelto di ufficializzarne il rilascio con .NET 6.0.

Vediamo più nel dettaglio di cosa si tratta.

Blazor WASM nasce con l'ottica di eseguire codice C# in WebAssembly, ed è proprio qui che iniziano i problemi: questo tipo di conversione non è banale, al punto che si è deciso di utilizzare un interprete. Al momento della pubblicazione, la nostra applicazione viene convertita in IL (Intermediate Language) che verrà poi analizzato e tradotto da dotnet.wasm. Questa fase che prevede la traduzione da IL a codice binario è detta JIT (Just in Time compilation). Abilitando l'AoT lo step viene saltato, convertendo direttamente C# in WebAssembly.

Il risultato è che AoT consente al codice di girare più velocemente, riducendo il carico di lavoro a runtime della CPU.

Per abilitarla è necessario installare il pacchetto wasm-tools, abilitare la configurazione nel progetto, e utilizzare il normale comando di pubblicazione o la GUI di Visual Studio.

dotnet workload install wasm-tools

<!-- *.csproj -->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <RunAOTCompilation>true</RunAOTCompilation>
</PropertyGroup>

dotnet publish -c Release

L'attributo che specifica una condizione all'interno del file del progetto è opzionale, e può puntare anche a configurazioni custom; noi abbiamo preferito inserirlo perché di solito la compilazione AoT richiede molto più tempo della normale compilazione, e in questo modo possiamo attivarla selettivamente alla fine della fase di sviluppo.

Infatti, il compilatore dovrà tradurre tutto il codice in WebAssembly, operazione molto più dispendiosa di una normale compilazione IL. Un altro effetto di questa modalità, è che le dimensioni dell'assembly risultante saranno maggiori. Al primo caricamento, a seconda delle dimensioni dell'applicazione, potrebbero essere necessari più secondi di attesa, dato che il pacchetto risulterà più pesante.

Problema che viene alleviato dal browser, in quanto a seguito del primo download, il file verrà salvato nella cache e i tempi iniziali di caricamento torneranno ad essere analoghi alla versione JIT. Può essere utile avere questo tipo di condizione nel momento in cui vogliamo fare un deploy in locale o in un ambiente di test.

In conclusione il passaggio ad una compilazione AoT è un vantaggio in termini di prestazioni - Una funzione costruita con 4 cicli innestati può girare fino a 5 volte più velocemente - a discapito di un primo caricamento leggermente più lento. Otteniamo anche una garanzia a lungo termine, in quanto a seconda degli sviluppi del compilatore, si riuscirà a creare codice più performante e a coprire più casi: al momento della stesura di questo script la reflection e i tipi dynamic non sono supportati, e costringono l'applicazione ad utilizzare una compilazione JIT per quelle parti di codice.