Cerchiamo di capire, in questo primo articolo, da dove è nata l’esigenza di un nuovo framework di front-end.
Un po’ di storia
Con la (presunta) morte del Desktop di qualche anno fa, molti hanno deciso di migrare le proprie applicazioni su tecnologie web, risolvendo il problema della compatibilità cross-platform e della distribuzione degli aggiornamenti dell’applicazione. Spostando però una parte dell’elaborazione dai client al server, sono nati tutta una serie di problemi tecnici, tra cui quello dell’esperienza utente, della connettività continua al server e del carico da gestire.
Niente di insuperabile, ma il passaggio non è stato indolore, anzi, molti si sono resi conto che migrare la propria interfaccia da una tecnologia client, come ad esempio Windows Form, a una tecnologia web, come WebForms o MVC, è spesso un rifacimento totale della propria soluzione software.
Nella maggior parte dei casi i benefici superano gli svantaggi e comunque lo sviluppo software si evolve ad una velocità tale da non poter rimanere troppo indietro. In ogni caso, a un certo punto, è nata l’esigenza di avere una user experience più spinta, fortemente limitata dal rendering server-side di ASP.NET. Ed è qui che è stata evidente l’esigenza di eseguire codice nel browser, utilizzando JavaScript.
I programmatori .NET non amano JavaScript per motivi storici, ma con l’aiuto di jQuery e di alcuni helper si è cominciato ad aggiungere funzionalità client alle applicazioni web. Tutto bene fino a quando non si è sentita l’esigenza di spostare sul client tutto il rendering dell’interfaccia, lasciando al server solo le API per il recupero e il salvataggio dei dati.
A quel punto la scelta di una libreria, o addirittura un framework completo è diventanto indispensabile per rendere sostenibile lo sviluppo, e soluzioni come Angular, React e Vue hanno cominciato a diffondersi anche tra gli sviluppatori .NET. Angular, in particolare, si è affermato grazie all’utilizzo di Typescript e a un approccio molto vicino ai framework Microsoft.
Con questi strumenti è possibile realizzare quella che viene chiamata una Single Page Application, cioè una singola pagina HTML all’interno della quale l’interfaccia viene creata dinamicamente e la navigazione tra le pagine dell’applicazione avviene senza spostarsi fisicamente.
Perchè Blazor
Dover imparare un linguaggio come JavaScript e un nuovo framework non è certo una passeggiata, anche se aiutati da TypeScript. Molti hanno preferito attendere per capire come si evolveva il mercato, altri per mancanza di tempo per affrontare il tutto.
Blazor si colloca proprio qui. Risolve esattamente questo problema. E’ possibile, grazie ad esso, riutilizzare le prorie conoscenze del .NET framework per realizzare una Single Page Application. Lo fa in diversi modi, sfruttando diverse tecnologie, e possiamo scegliere la modalità che meglio si adatta alle nostre esigenze.
Con il framework .NET Core 3.0 è stato rilasciato in RTM Blazor Server, che sfrutta SignalR per inviare al browser gli aggiornamenti da fare all’interfaccia, eseguendo comunque l’elaborazione lato server. Con il .NET Core 3.1 è stato rilasciato in preview Blazor WebAssembly, che invece scarica nel browser l’applicazione che realizziamo e la esegue grazie allo standard WebAssembly. Approfondiremo la differenza tra i due nel prossimo articolo, per il momento cerchiamo di capire perchè sta avendo tanto successo.
Perchè investire su Blazor
Se conoscete ASP.NET Core e Razor, il passaggio a Blazor è davvero semplice: è questa la sua forza. Una volta capito (davvero) il concetto di componente, entrambe le versioni vi permettono di sfruttare tutto quello che già sapete e su cui avete investito. Inoltre c’è già un bel po’ di materiale e tanti componenti già pronti per pensare di sviluppare una vera applicazione da mettere in produzione.
Blazor non è nè Silverlight nè LightSwitch, Microsoft ci crede e ci sta investendo. La community di sviluppatori .NET è fortemente interessata e lo ha dimostrato fin dal primo momento. Non c’è nessun plug-in da installare, è tutto basato su standard web, ed è questo che vi garantisce che non farà la fine degli esperimenti del passato.
Microsoft ci crede così tanto che ha annunciato una roadmap da brividi per Blazor: non solo web, ma anche Mobile e Desktop. MAUI (Multi-platform App UI) è l’evoluzione di Xamarin Forms. Con .NET MAUI potete creare un progetto, compilarlo ed eseguirlo su Android, iOS, macOS e Windows. Con la pubblicazione di .NET 6 (Novembre 2021) è stato reso possibile usare componenti Blazor all’interno di un progetto MAUI!
https://docs.microsoft.com/en-us/dotnet/maui/user-interface/controls/blazorwebviewt Docs
Installazione
Se avete Visual Studio 2022 (la versione community è scaricabile gratuitamente qui) e avete installato il supporto allo sviluppo ASP.NET e Web, avete già tutto quello che vi serve: create un nuovo progetto Blazor e lanciate l’applicazione per cominciare a prenderci confidenza.
Se siete appassionati di Visual Studio Code e della riga di comando, l’installazione della versione 6 del framework .NET vi metterà a disposizione anche i template per Blazor. In questo modo potete creare una applicazione Blazor Server con il comando
dotnet new blazorserver
Oppure una applicazione Blazor WebAssembly con il comando:
dotnet new blazorwasm
Conclusioni
In questo primo articolo abbiamo solo scaldato i motori, cercando di capire dove si colloca Blazor e perchè è la scelta da fare in questo momento per gli sviluppatori .NET. Nei prossimi articoli andremo a fondo nell’utilizzo del framework e cercheremo di toccare con mano la potenza di questo strumento.
Scritto da:
