Durante il bellissimo workshop di ieri ho parlato di WCF vNext. Anche se sembra strano, uno degli argomenti presi in carico dal team di WCF è una ampia libreria jQuery che permette di sviluppare Rich Client LOB utilizzando Html5 e jQuery utilizzando i RIA services.
Non è un mistero che Microsoft stia puntando tutto su Html5 e queste nuove librerie di WCF vNext sono una prova concreta.
Nella mia demo sono partito da un esempio classico Silverlight (HR Application dei samples):
Per la demo ho sviluppato un front-end uguale usando le nuove librerie jQuery e Html5 che hanno identiche funzionalità:
Già in CTP le nuove librerie hanno caratteristiche decisamente allettanti:
- Template html analoghi a quelli Xaml
- DataBinding su field html marcati con ${nomecampo}
- Notifiche stile INotifyPropertyChanged in modo da ottenere "gratis" il refresh della view
- Utilizzare i RIA services ottenendo json + i metadati RIA
- Validazione grazie ai metadati forniti da RIA
- Navigazione in modo "online" e "disconnesso"
- Submit dei cambiamenti in modalità "implici commit" (cioè ogni volta che cambio qualcosa viene invocato il server) oppure buffered (spedizione batch delle modifiche)
- Paginazione, sorting, filtering
Nota di redazione. Il binding lato client non è una novità. Lo presentai in diversi corsi a fine anni '90 - inizio 2000 utilizzando Visual Interdev, asp classic, SQL 2000, VB6 & VC++, vbscript lato client, XML Data Island e un nuovo componente Microsoft chiamato XmlHttp, oggi chiamato Ajax.
Altre novità di queste librerie sono state promesse al Mix11 entro la RTM:
- Generazione automatica di un proxy jQuery per utilizzare RIA in modo ancora più semplice
- Generazione di widget (analoghi a degli user control) che permettono di redistribuire un componente jQuery che qualsiasi webmaster può inserire nella propria applicazione (pensate ai widget per la previsione del tempo)
A questo punto mi preme riportare alcune osservazioni oggettive:
- Molti (ma non tutti) scenari che prima erano esclusivi di Silverlight adesso si possono sviluppare in puro Html5
- Il meritato successo di MVC dimostra che lo sviluppo è già oggi più client-side. Non avrebbe avuto senso invece nel 2003 con asp.net 1.1 dove la mancanza di uniformità dei browser e di una libreria come jQuery creavano un gap troppo alto.
- Gli utenti stanno apprezzando nuovi device che alla nascita di Silverlight non erano neppure ipotizzabili. Windows, Mac, Linux, WP7, iPad, iPhone, Android, per non parlare di tutti i flavor dei produttori "minori" stanno rendendo il panorama estremamente eterogeneo e impossibile da coprire con Silverlight/Moonlight.
L'interoperabilità è quindi un fattore di cui non si può non tenere conto. - Certo che lo streaming o il progressive downloading, il 3D spinto e altri scenari non sono coperti da Html5 ma la stragrande maggioranza di scenari web non richiedono queste caratteristiche, meno che mai in applicazioni LOB.
Developer experience.
Se oggi un cliente che deve sviluppare una applicazione enterprise in cui i dispositivi Microsoft sono gli unici a dover essere supportati (Win, WP7) non c'è alcun dubbio che Silverlight ha la migliore developer experience, punto. Usare Blend, Visual Studio, C# e gli altri tool sono il paradiso dello sviluppatore.
Se oggi prendete in mano un editor di javascript e cominciata a scrivere, la vostra produttività sprofonda.
Ma … quando si decide di sviluppare una applicazione si parte dai requisiti del cliente e non dalle "comodità" dello sviluppatore (che pure incidono sui costi totali di sviluppo). Se oggi il front-end di una applicazione deve girare su più device (e tenere conto di quelli che verranno) la risposta è jQuery + Html5, oppure un lungo e faticoso sviluppo "custom" di applicazioni su ciascuna piattaforma (che è un'opzione validissima dal momento in cui i numeri si fanno alti).
Sul fronte Visual Studio, se guardate bene l'Extension Manager, vedete che Microsoft ha pubblicato le prime estensioni all'editor di javascript e questo mi fa pensare che stiano lavorando ad una "developer experience" migliore per la prossima release. D'altra parte se investono nelle librerie l'editor all'altezza di Visual Studio non può mancare a mio avviso.
E Silverlight?
Silverlight è cool prima di tutto perché ha un logo e un bel nome e non è un caso che molte tecnologie toste non siano cool per la mancanza di un logo.
Silverlight è sulla cresta dell'onda quindi il prodotto che va bene non si tocca (ed è per questo che l'uscita di Bob Muglia era tragicamente infelice).
Silverlight in certi scenari è imbattibile ma il suo ambito si sta restringendo invece che allargarsi.
Allora mi chiedo quanto dobbiamo ancora aspettare prima di sentire un annuncio che faccia convergere Silverlight e WPF in un unico prodotto, considerato anche che la client version del full framework è di dimensioni non esageratamente più grossa rispetto al runtime di Silverlight?