Da qualche tempo il team sta lavorando alla prossima versione di ASP.NET, nome in codice ASP.NET vNext. In realtà, se siete abituati ad ASP.NET (e One ASP.NET), la prossima versione rappresenta un netto taglio rispetto al passato.

Fin dalla prima versione di ASP.NET sono stato un fautore di un meccanismo più snello riguardo a runtime, gestione del markup, compilation model e semplificazione della pipeline. Probabilmente ero troppo prematuro nelle mie richieste, perché il resto del mondo sembrava non averne bisogno. Forse, semplicemente, c'era troppa cultura enterprise e il web "consumer" non sembrava uno scenario interessante.

ASP.NET vNext è, semplificando molto il concetto, questo:

• runtime snello, che può girare su Windows o Mono (e quindi su MacOSX, Linux);
• progetto e singoli file modificabili da Notepad (ovviamente con pieno supporto anche a Visual Studio);
• no-compilation deployment: copia i file e sei pronto ad andare;
• portabilità su cloud e basso impatto su memoria (niente reference a tutto il framework e tutto è nella bin);
• pipeline e modello di programmazione unificato tra MVC e Web API.

La prossima versione di ASP.NET include solo ASP.NET MVC e Web API, non richiede per forza il .NET Framework, non vi obbliga ad utilizzare Visual Studio, perché la compilazione avviene a runtime, non necessita di installare il framework sul server, perché è deployato insieme al runtime. Inoltre, richiedendo una versione minima del runtime per funzionare, ha un basso impatto sulla memoria, vi consente di fare deployment solo delle feature che vi servono e di tenere una data versione di un dato component indipendentemente da quello che c'è sul server. Il tema della memoria è importantissimo in un'epoca in cui andiamo verso il cloud computing, perché così sprechiamo meno memoria per il runtime (con feature che non useremo) e possiamo impegnarne di più per le necessità delle nostre applicazioni.

Tutto questo, però, richiede breaking changes. Il modello di ASP.NET vNext è quello di MVC, con l'aggiunta di Web API. La compatibilità al 100% del codice, però, non c'è. C'è ancora Razor, ma non ci sono tutte le classi della BCL del .NET Framework. Per migrare un'applicazione esistente occorre ripensarne certe parti. Hanno incominciato la lunga opera di avvicinamento partendo da OWIN, che vi ritrovate in tutte le salse nelle ultime versioni, magari senza sapere perché: il primo step necessario era limitare la dipendenza di ASP.NET da IIS, il web server.

I vantaggi di questo nuovo approccio sono tantissimi: oggi è del tutto normale che una vista sia fatta da una parte renderizzata server-side e da una componente di dati che arrivano da un servizio REST. Semplicemente, avere due posti in cui spezzare la logica di implementazione, spesso, non ha senso. E se i controller di ASP.NET MVC possono sputare fuori JSON, Web API è un'altra roba. Questo merge dei due mondi non farà che dare benefici a tutti i livelli: alla fine un controller è tale perché fa qualcosa, non per l'output che produce, e HTML è sempre meno quello che vogliamo servire.

ASP.NET vNext nasce dall'idea che ormai lo sviluppo web non è solo fatto di server-side, come agli inizi del 2000, ma c'è una componente fondamentale di client-side che cresce sempre di più. Usare un framework come AngularJS deve essere possibile, così come deve essere facile fare un deployment di una modifica, senza bloccare l'intera applicazione, mentre un assembly da 350 kb viene caricato e l'AppDomain si ricicla. Per i ritmi e i tempi di oggi, il modello di compilazione del .NET Framework non può più applicarsi bene ad un'applicazione web.

Che fine fa ASP.NET WebForms? Nessuna, è sempre lì. ASP.NET WebForms è quanto di più accoppiato al .NET Framework, legato ad IIS e pensato per un web che non c'è più, ci possa essere. Ma è fatto e finito, nel senso che ha tutto quello che ha senso che abbia. Potrete avere di tanto in tanto delle migliorie sparse, qualche nuova feature portata da ASP.NET MVC, ma resta un toolkit nato per chi faceva applicazioni web nel 1999: tanta gente che sviluppava per il desktop e voleva avere l'illusione di poter sviluppare per il web senza conoscere HTML, JavaScript e CSS. Ma non temete, perché WebForms resterà dov'è e potrete continuare ad utilizzarlo.

Quel periodo è passato e abbiamo bisogno di un toolkit più maturo, che sia al passo con i tempi.

Quando mi chiedono su cosa conviene investire, se MVC o WebForms, rispondo da sempre con l'unica risposta possibile: investi su ASP.NET MVC. Perché è quello che è più vicino al web, l'unico dei due dove l'HTML ti è sbattuto in faccia, la pipeline è breve, non ci sono astrazioni inutili e, quindi, ti tocca conoscere come funzionano HTTP, HTML, CSS e JavaScript. Ti tocca, insomma, essere uno sviluppatore web.

Con ASP.NET vNext, finalmente, avremo un toolkit moderno al 100% e se vogliamo usare Visual Studio, IIS e Windows avremo la combinazione migliore, ma non saremo limitati solo all'ecosistema Microsoft e saremo liberi di mischiare a piacimento. Tenete d'occhio il nostro sito, perché per ora è un'alpha e ne parliamo poco, ma già il 22 ottobre con il nostro prossimo webcast inizieremo a (ri)mettere il web al centro di ASP.NET: non perdetevelo.