Il ne se passe pas un jour sans qu'on ne parle d'un fait lié à HTML 5, que ce soit pour encenser ces vertus multiplateformes, enterrer ses principaux concurrents ou annoncer une n-nième spécification. Le dernier en date et non des moindres est la présentation officielle de Windows 8 par Microsoft. Difficile de rester insensible à ce mouvement de fond, que dis-je ce tsunami technologique qui secoue en ce moment la firme de Redmond. Quelle histoire rocambolesque que celle de la stratégie RIA d'un éditeur qui ne sait clairement plus vers quel saint se vouer. Pour bien comprendre l'ampleur du désastre, faisons un petit retour en arrière.
Nous sommes en 2004, le monde du RIA est dominé par les technologies dites « Smart Client ». C'est la mode du vectoriel, de Flash entre autre, insaisissable. Dans le même temps émerge une approche concurrente plus tournée vers JavaScript et HTML, c'est le règne d'AJAX. Microsoft cette année là, doit faire un choix, soit redonner de l'air frais à sa technologie client lourd maison (Windows Forms) soit jouer sur le même registre que son ennemi juré Google en pariant sur HTML.
2005, le choix est entériné, ce sera du Smart Client Vectoriel façon plugin. Et pour cause, à la même époque, IE est légion et ses performances sont désastreuses, notamment JavaScript. Les fondations de WPF sont posées fin 2005 puis complétées quelques mois plus tard par la petite soeur « Web compatible » : Silverlight. La première version de Silverlight 1.0 est un loupé d'un point de vue technologique, les suivantes seront bien plus cohérentes dans leur intégration du Framework .NET. A cette époque, bien peu d'entre nous auraient parié sur l'éclosion du standard HTML. Pour l'immense majorité des développeurs, le futur se jouait entre Microsoft et Adobe, Sun ayant largement perdu sa place avec JavaFx.
Tout naturellement donc, Microsoft a investi massivement pendant plus de cinq ans dans WPF et Siverlight, au point de refondre l'interface graphique de Visual Studio ou de réécrire de nombreux produits de son portefeuille (l'étau s'étant même resserré à un moment sur la gamme Office)
C'était sans compter le mouvement de fond qui se tramait en coulisse. Dans les années qui suivirent Apple sortait iOS sur iPhone puis l'iPad. Google planchait sur ChromeOS et Android. Difficile d'imaginer à cet instant que Apple et Google encenseraient HTML 5 jusqu'à menacer les smart clients. Quatre années plus tard, Microsoft a renforcé ses équipes WPF et Silverlight au point de délaisser totalement sa stratégie mobile et d'en oublier son navigateur fétiche.
Nous sommes en Juin 2011, l'annonce de Windows 8 et de sa nouvelle interface graphique à base de HTML 5 est un coup de tonnerre. Invraisemblable, ubuesque. Microsoft se voit brusquement remobiliser des équipes ayant pris fait et cause pour une technologie clairement affichée comme l'anti-HTML. Lorsqu'il sont en concurrence, HTML 5 et JavaScript doivent être préférés à WPF et Silverlight dans Windows 8.
Une pilule d'autant plus difficile à passer lorsqu'on sait qu'aujourd'hui HTML 5 n'est pas outillé ! On l'oublie trop souvent, HTML 5 est encore un brouillon, HTML 5 ne sortira (peut-être) réellement qu'à la fin 2014 pour espérer un support uniforme aux alentours de 2015. Il existe encore une myriade de spécifications en cours d'élaboration et de zones non couvertes par l'actuel standard. Que ce soit CSS 3, le support des outils média (WebCam, Micro, Scanner, etc .) ou la gestion du placement (CSS Flexbox, etc.).
Imaginez un instant les équipes WPF habituées pendant de longues années aux vertus de l'intégration Visual Studio, aux délices du databinding via Drag & Drop, aux miracles de la programmation parallèle via les threads, ouvrir un pauvre éditeur texte et commencer à coder en JavaScript la couche IHM de Windows 8. Les dégâts seront considérables.
Attention, bien loin de moi l'idée de dire ici que HTML 5 n'est pas une technologie utilisable aujourd'hui. Bien au contraire. Mais gardez à l'esprit que coder en HTML 5 se résume essentiellement à coder en JavaScript. Je ne peux imaginer un instant écrire un logiciel contenant des centaines de milliers de lignes de code dans ce langage ô combien puissant et dynamique, mais ô combien inmaintenable et indéboggable. Depuis 2006, nous utilisons GWT justement pour pallier aux innombrables lacunes inhérentes à JavaScript et HTML. Les différences de support entre navigateurs, la taille croissante des scripts et des ressources, les fuites mémoire, les performances, . Au fur et à mesure que les spécifications HTML 5 arrivent à maturité, Google les intègre dans GWT et les développeurs en bénéficient en toute simplicité. JavaScript est devenu au fil du temps d'une certaine manière notre assembleur. Imaginer que Microsoft va découvrir les joies du développement . en Assembleur après avoir connu la Rolls Royce VS/WPF est tout bonnement édifiant.
Dans ce contexte abracadanbresque, Il ne reste plus à espérer une chose, que Script#, Volta et toutes ces technologies qui se sont à un moment donné frottées à GWT soient remises au goût du jour, et ce, même si c'est avec 5 ans de retard sur Google. Il n'est jamais trop tard pour bien faire.
Articles à lire absolument (via twitter de Pierre) :
Flux XML
