Windows 8, Metro, HTML 5 et le futur de Silverlight

Rien de mieux qu’un cours, une formation ou, dans mon cas aujourd’hui, un entretien avec un journaliste pour se forcer à mettre ses idées en ordre. En l’occurrence, sur l’avenir de Silverlight dans Windows 8.

Pour résumer ma pensée, deux choses :

1) Silverlight est effectivement mal barré.

2) Mais ce n’est peut-être pas un problème.

Que je m’explique : j’adore le concept même de Silverlight et je trouve que c’est une technologie super aboutie, facile à programmer et extraordinairement riche de fonctionnalités. J’ai personnellement eu maille à partir avec Flex et il n’y a pas photo… C’est un peu comme programmer iOS ou Windows Phone : le choix est entre le burin ou le laser

Ce n’est donc pas de gaieté de cœur a priori que je constate que l’évolution de Silverlight est mise en danger par l’adoption d’HTML5 dans l’interface Metro de Windows 8. Ce qui m’a amené à modifier mon avis sur ce point est une lecture sur InfoQ (un de mes sites informatiques préférés), qui renvoyait sur une page extrêmement intéressante, avec une analyse des types communs entre WinRT et Silverlight 5.

Une énorme partie des API de Silverlight se retrouve dans WinRT !

Or, si on revient aux origines de Silverlight, quel était le but de la technologie, sinon combler le fossé entre le développement “riche” pour les applications Desktop et le développement d’applications web “légères” ? Je mets “légères” entre guillemets parce que quand on voit la taille de certaines pages web, on se demande pourquoi on appelle encore ça du client léger, mais bon… c’est un autre débat.

Silverlight a très bien comblé ce fossé entre le client riche et le client web, en utilisant un plugin qui permettait d’utiliser des technologies de développement riche (WPF, WCF, XAML, DataBinding, etc.) dans un navigateur web.

Mon idée est que Silverlight va disparaître non pas parce que la technologie est mauvaise, mais tout simplement parce que ce besoin de rapprocher le développement web du développement Windows va désormais être intégré directement dans le système d’exploitation : tout ce qui est nécessaire sera dans l’API WinRT. Il n’y aura donc pas besoin d’un plugin pour gérer ceci.

Quand on y pense, d’ailleurs, ça faisait un bout de temps que Microsoft avait mis des ponts en place entre les deux : Script#, la possibilité d’appeler des API .NET en JScript, le hosting de ControlUser dans IE (l’équivalent des applets Java), les applications en mode Page de WPF intégrées dans le navigateur… Ca faisait pas mal de tentatives, quand même ! Le fait que Microsoft ne démente pas la disparition de Silverlight tend à faire penser que cette fois-ci, ils ont préparé le coup de longue haleine.

On peut imaginer un Windows 8 avec une interface Metro légère dans lequel HTML5 est utilisé pour structurer les applications, avec des appels à WinRT pour les traitements.

En effet, il ne faut pas se voiler la face : malgré tout le battage médiatique autour de HTML5, il ne s’agit que d’un langage de structuration de contenu. Le seul élément portant sur du traitement est la prise en compte de la validation côté client : c’est un peu léger pour imaginer qu’on va pouvoir réaliser des applications avec HTML5. Il y aura encore beaucoup de JavaScript, JQuery, appels à des services web ou des API comme WinRT justement.

J’imagine que l’adoption d’HTML5 dans cet interface répond pour Microsoft à deux objectifs :

1) Ne pas se planter en laissant passer le train HTML5 comme ils l’ont fait avec l’internet il y a 10-15 ans.

2) Pouvoir offrir une interface utilisateur réactive sur les tablettes Windows 8, afin d’être au niveau des iPad (ce qui est loin d’être le cas aujourd’hui pour les tablettes Windows 7).

Maintenant, tout ceci n’est qu’anticipation de ma part, et si ça se trouve, dans un an ou deux, je serai mort de honte d’avoir écrit ceci. Mais bon, le ridicule ne tue pas… On en saura certainement un peu plus aux TechDays 2012 !