Olivier Dahan

Microsoft MVP Silverlight 2013, 2012,
2011, MVP CAD 2010, MVP C# 2009


Membre du Developer Guidance Advisory Council Microsoft

Audit, Conseil, Formation, Développement
[WPF, Silverlight, WinRT, MonoDroid]

Historique

De Silverlight à WinRT : Mesurez les différences grâce au “WinRT Genome Project”

Lire ce post dans une autre langue IT | EN | DE | ES

Passer de Silverlight à WinRT est encore plus simple que depuis WPF tant les deux plateformes se ressemblent. Les deux sont sandboxées, et pour développer de Windows Phone 8 à Windows 8 Pro en passant par RT, C# et Xaml sont aujourd’hui clairement poussés par Microsoft (contre tout ce qui a été dit auparavant sur Html...). Mais quelle distance sépare Silverlight de WinRT ? C’est tout l’intérêt du “WinRT Genome Project” de répondre, au moins partiellement, à cette question.

WinRT Genome Project

Il s’agit d’un projet visant à comprendre le cœur de WinRT. Et puisque Silverlight en est si proche, le mieux est de comparer ces deux plateformes.

La question qui se pose d’emblée est de savoir jusqu’à quel point ces plateformes sont similaires ? Quelle est la quantité de choses nouvelles qu’il faudra apprendre pour qui connait Silverlight ou WPF ?

Tim Greenfield a tenté de répondre à ces questions. Il a commencé par écrire un programme qui balaye tous les assemblages par défaut de WinRT pour les comparer à leurs équivalents Silverlight.

Vous pouvez lire son analyse (en anglais) sur son blog “Programmer Payback”.

Types en commun

La première comparaison consiste à voir combien de types sont communs. Tim résume la situation par le schéma suivant :

image

WinRT est farci de milliers types différents ! 5978 comptés par Tim, ce qui est beaucoup au vu des 2189 que compte Silverlight, plus du double.

Mais cela est trompeur. Silverlight peu compter bien plus de types que cela dès qu’on ajoute toutes les librairies utiles à une vraie application : WCF Ria Services, le Toolkit, toolbox MVVM, etc.

Sur les 2189 types de base de Silverlight, 1582 sont commun avec WinRT et 607 ne se retrouvent pas dans ce dernier. Presque tout Silverlight se retrouve donc dans WinRT. Ici encore il faut nuancer les choses, 607 types non portés dans WinRT c’est par exemple toutes les classes servant à la gestion de la passerelle avec DOM ou l’Out of brower qui n’ont plus aucun sens sous WinRT. De même, les 4396 types de plus de WinRT intègrent de nombreuses nouvelles API pour gérer l’accéléromètre, les caméras, etc.

Membres en commun

Parmi les 1582 types communs, Tim s’est attaché à pousser la comparaison plus loin pour voir si la proximité de ces types est totale ou partielle, et quantifier la différence si elle existe.

Bien entendu, tout comme de nombreux types communs entre Silverlight et WPF possèdent des différences, on va retrouver des différences entre les types Silverlight et WinRT, ce que résume le graphique suivant :

image

Ici la nuance est plus faible, ce qui est naturel. Si un type est commun on peut supposer que le besoin l’est aussi et que les différences seront légères. S’il y a trop de différences alors le type n’est tout simplement pas commun...

Sur les 14597 membres recensés de WinRT, 10375 sont communs avec les membres équivalents de Silverlight (c’est la version 5 qui est prise comme base de calcul). Seuls 651 membres Silverlight ne sont pas dans WinRT. En revanche, les types communs entre les deux plateformes sont souvent mieux pourvus sous WinRT. 4222 membres apparaissent en plus sous WinRT pourtant sur des types communs à la base.

Pousser la comparaison plus loin

Bien entendu tout cela reste assez général. Mais ça donne tout de même une bonne idée de l’ensemble. De la distance entre Silverlight et WinRT, ce fameux delta qu’il faudra acquérir pour connaitre le second quand on connait le premier.

Mais Tim est allé beaucoup plus loin dans les comparaisons en produisant une différentiel classé par espace de noms et groupé selon que les types appartiennent à WinRT exclusivement ou à la partie commune avec Silverlight.

Cela se présente sous la forme suivante (exemple ici de l’espace de nom System.IO, avec la colonne SL5 et la colonne WinRT) :

image

 

Pour accéder au site de comparaison et à tous les espaces de noms, cliquez sur l’image ci-dessus...

Conclusion

Je vous ai déjà proposé récemment d’approcher WinRT par ses API. C’est le meilleur moyen de prendre connaissance d’une nouvelle plateforme quand on sait programmer. On y trouve des types, des membres, dont les noms parlent immédiatement, on apprend à se situer comme avec la carte géographique d’un nouveau lieu à découvrir.

Aucun pilote de rallye, aucun cycliste, aucune troupe armée, aucun randonneur sérieux ne se lance sur le terrain sans avoir étudier des cartes au préalable.

C’est aussi l’avis de Tim visiblement...

Aborder les choses par le gros bout de la lorgnette en plongeant dans des exemples de code sans avoir déjà une bonne idée du terrain sur lequel ils se reposent est une méthode facile, accrocheuse certes, mais pédagogiquement sans valeur.

Alors avant d’aborder WinRT par l’exemple, commençons par nous imprégner de ses espaces de noms, des types que propose son API, des similitudes et des différences avec Silverlight et WPF.

C’est une bonne entrée en matière. Sans la surévaluer, et malgré son austérité, ne négliger pas cette première approche. Quand nous verrons du code dans quelques temps vous apprécierez cette sensation de déjà vu...

Stay Tuned !

Comments (12) -

Nathanael Marchand
Nathanael Marchand
6/27/2012 12:28:20 PM

On pourra juste regretter que le Binding n'est pas aussi puissant en WinRT qu'il ne l'est en Silverlight et WPF Smile
StringFormat est notamment absent de BindingBase et c'est dommage Frown

Olivier
Olivier
6/27/2012 3:01:59 PM

@Nathanael: Il n'y a pas que les types qui font la différence, il y a aussi de vraies différences de philosophie (comme le tombstoning façon smartphone même sur un PC). Et bien entendu il y a aussi des différences dans le Xaml.
C'est la même équipe qui a fait le Xaml de WinRT que celle qui s'occupait de Xaml pour SL ou WPF, et je pense que "dans l'urgence" ils ont été obligé de repartir sur un noyau central de fonctionnalités qu'ils étaient surs de pouvoir livrer dans les temps.
Je pense, et j'espère !, qu'au fil des mises à jour de Windows 8, Xaml va réintégrer certaines possibilités comme le formatage. J'adorerai aussi le retour des indispensables Behavior...
Toutefois je pense que soit beaucoup de choses seront déjà là dans la finale, soit il faudra attendre plus que d'accoutumée : Xaml fait partie de l'OS désormais, ce n'est pas un SDK dont on peu télécharger des MAJ comme ça... Et on sait en plus à quel point Sinofsky n'aime pas tout ce qui tourne autour de Xaml, de là à ce qu'il ne mette pas les améliorations de Xaml dans les priorités, il n'y a qu'un pas..
Mais l'essentiel est là quand même. J'ai réussi à passer des contrôles et des UserContrôles, des templates, etc, sans trop de soucis, sauf les behavior... et ça ça manque vraiment quand on a fait beaucoup de SL.
Mais sinofsky aurait pu écraser totalement Xaml et  ne plus nous laisser le choix que de c++ et javascript avec de l'Html bidouillé qui ne marche même pas sur le Web... On a eu chaud ! Smile

Julien Dollon
Julien Dollon
6/27/2012 11:58:54 PM

Non Olivier, XAML/C# n'est pas + pousse que HTML/JavaScript ou C++.
Aujourd'hui il n'y a personne a l'interieur de MS capable de te dire qu'elle plateforme va etre le golden language direct.
Les trois langages sont au memes niveaux et seul le temps et la politique de Microsoft nous montrera quel chemin suivre.
En tout cas, en interne, la plupart du temps c'est du HTML/JS.
Bon article sinon Smile
Bisoux

Olivier
Olivier
6/28/2012 12:48:17 AM

@julien: je veux bien te croire mais lors de la dernière présentation de Windows phone 8 il y a quelques jours le type responsable du dev (j ai oublié son nom mais c est un gars bien enrobé tu dois voir de qui je parle) à clairement dit que pour du cross plateforme c est C# et xaml! Tu as du louper cet épisode récent... Et c est évident. Même MS n y crois plus au buzz... Mais fais moi plaisir réécoute cette présentation... Et on en reparle après. Wink

Julien Dollon
Julien Dollon
6/28/2012 2:58:41 AM

Je peux te dire que Windows Phone 8 a clairement du retard sur le developpement HTML5 et que, je pense, que ce sera rattrape dans la prochaine version.
Ils n'avaient juste pas le temps de tout mettre.
Et oui ils ont raison de dire que aujourd'hui C#/XAML est la meilleure chose pour du cross platform puisque HTML n'est pas encore supporte dans WP8.
Je suis sous NDA donc je ne peux rien dire, mais je maintiens ma position qui etait la mienne avant d'etre sous NDA:
C#/XAML c'est bien et ca sera pas abandonne
JS/HTML est le golden language pour dev sur Windows 8.

J'ai du mal a comprendre pourquoi tu prends autant en grippe cette techno. Tu as le droit de ne pas aimer, tu as le droit de douter de son future mais ne generalise pas le fait que MS n'y crois plus.
En terme d'emploi, on doit avoir autant de gens dans la partie HTML5 que C#/Directx/Jupiter cumule... Smile

Olivier
Olivier
6/29/2012 1:45:09 AM

@Julien: Tu vois, finalement C#/Xaml c'est un bon choix... Smile

Du coup, soyons lucides, petit à petit MS cherche à se sortir de ce cul de sac stupide, tombé dans le panneau de Jobs : "il n'y a que Html 5".

Il y aura Html 5, bien sûr. Mais "pas que". Et je dirais même certainement pas majoritairement en tout cas chez les pros.

Je suis sous NDA aussi et cela n'empêche pas de dire que MS infléchit doucement mais surement sa ligne du "tout html 5", pas trop vite histoire de ne pas passer (trop) pour des idiots grugés par le bateau monté par Jobs qui voulait tuer Flash et protéger son App Store...
Un vrai HTML 5 universel aurait été la mort de l'App Store, c'est une évidence. Et ça serait bien entendu aussi la mort du market place Windows 8 ou celui d'android.
Aucun des trois ne veut d'un Html 5 universel. Mais il y en a un qui a été très malin et à réussi à tromper les deux autres, enfin surtout MS, qui a du mal à se sortir de ce bourbier en gardant la tête haute...

Qu'il y ait plein de dev en Html 5 chez MS je n'en doute pas une seconde. Chez MS quand un truc nouveau sort "on" ne doit plus parler que çà et la techno qui était géniale hier devient un gros mot le lendemain.
Beaucoup de sites de MS avaient été refaits en intégrant du Silverlight par exemple, et à cette époque oser prononcer le nom de XBap était le meilleur moyen de se faire fusiller... Alors que la veille c'était la meilleure techno du monde...

Donc MS utilise Html5/JS, c'est bien, qu'ils s'amusent, qu'ils refassent des sites etc.

Mais de quel Html 5 parle-t-on ici ???

Du vrai, de celui du Web ou du truc bâtard de Windows 8 qui ne tourne pas sur le Web ???

Car le problème est en partie là...

Le problème n'est pas d'aimer ou non HTML 5, je m'en moque comme de ma première ligne de code en assembleur (quoi que.. ça c'est nostalgique au moins).

Le problème c'est que le Html 5 de Windows 8 n'est pas du vrai Html 5 et qu'il ne tourne pas sur le web ce qui le rend inutile. Car le couple C#/Xaml est bien plus musclé pour faire du dev Windows que Html/js. Ou pour les durs, les tatoués, c++ est carrément le grand pied... loin des fadaises html/js/css le trio infernal où tout s'embrouille sans logique. Le trio spaghetti...

Et quant à Html 5 sur le web, ce n'est pas que je n'aime pas là non plus, c'est juste que c'est une vieille techno embrouillée avec CSS, un truc qui a juste été maquillé comme une bagnole volée en lui rajoutant un Canvas et ce bon vieux SVG dont personne n'a voulu pendant 15 ans... Désolé mais ça ne me transcende pas du tout. Ai-je le droit d'être lucide et de ne pas me pâmer sans pour autant qu'on dise que je "prend en grippe cette techno" ?

Si on ne se met pas à genou devant le nouveau dieu on est forcément coupable ou bien est-on simplement clairvoyant ?

Il ne s'agit donc pas d'aimer ou non Html/js, il s'agit juste de ne pas tomber dans une idolâtrie ridicule.

Html 5 n'est pas et ne sera pas "universel", c'était l'essence du "buzz" et c'est juste ça que je combat : une fausse idée bien vendue, mais fausse quand même.

Le reste... il y a bien plein de gens qui trouve php ou Ruby ou Pearl ou python ou d'autres trucs exotiques de ce genre tout à fait intéressant. Ca ne me gêne pas.
Mais j'attends toujours de voir des applis pros de qualité et d'un peu d'envergure, qui se vendent et qui sont maintenables écrites dans ces langages...

J'attends donc de voir un jour des grosses applis bien joufflues, des vraies, écrites par des pros, qui soient maintenables écrites en html/js, pas seulement des jeux sur le web et pas seulement des gadgets WinRT genre lecteur de flux rss ou la météo... car ça, ça se fait en 10 lignes de C# et de Xaml depuis très longtemps déjà. Il en faudra donc plus pour m'impressionner et encore plus pour me faire changer d'avis.

C'est technique, c'est pro, rien à voir à avec aimer ou pas aimer, ni "prendre en grippe" quoi que ce soit.

Mais bon, parle-nous plutôt de surface, sans trahir ton NDA, ça c'est surement plus intéressant comme sujet Smile

Julien Dollon
Julien Dollon
6/29/2012 2:25:59 AM

OK Olivier je te reponds dans un article de blog tu l;auras voulu copain!

Olivier
Olivier
6/29/2012 4:49:49 AM

Whaaa ça va chauffer Smile
J attends ton article de doigts fermes (J essaye d éviter les pieds pour développer....)
Fais moi rêver avec html !
Si tu y arrives tu gagnes un bisou.

Nathanael Marchand
Nathanael Marchand
6/29/2012 2:11:17 PM

Un truc à noter quand même concernant le HTML5 sous Windows:
Ok le HTML5 de Windows 8 n'est pas portable vers le web mais la réciproque n'est pas vraie. Le HTML5 du Web se porte bien sur Windows 8 et je pense que c'est le sens là qui est le plus intéressant Smile

Olivier
Olivier
6/29/2012 2:52:33 PM

@Nathanael: bien joué, tu as raison sur ce point, mais j'attends de voir une vraie appli Web être portée complètement sous Windows 8 sans problème...
Un site Web n'est pas une appli téléphone, ni pc, ni tablette, gérer notamment les différentes vues en fonction de l'orientation n'existe pas dans le web alors qu'elle est indispensable sur une unité mobile. Le zoom sémantique de WinRT n'existe pas sur le Web non plus, ni les barres d'outils, les barres contextuelles, l'intégration dans le moteur de recherche, etc... Au final reprendre du html Web pour faire une appli WinRT c'est 95% de réécriture ou d'ajouts nouveaux... quitte à tant faire de code nouveau, autant utiliser d'emblée un vrai langage comme C#.

Alors oui, bien sur, on peut reprendre le design de l'appli et dire qu'on la portée. Mais en réalité le design d'un site Web c'est avant tout du photoshop fourni par le graphiste, et on peut en cinq minutes le réutiliser sous Blend pour faire du Silverlight ou du C#/Xaml sous Win8...

Je pense que l'intérêt reste donc mineur car au final un code Web ne se porte pas plus facilement sous Win8 qu'un code html Win8 ne se porte sur le Web..

C'est une illusion, une de plus. Bien tenté malgré tout Smile

juliend
juliend
6/29/2012 8:00:10 PM

Bon vivement disqus...
Pour info j'ai deja migre mon site home.dollon.net sur une app WIn8 et j'en ai fais un webcast:
http://julien.dollon.net/post/Conference-How-to-migrate-a-HTML5-web-page-to-Windows-8-Metro-app.aspx

Olivier
Olivier
6/30/2012 1:33:10 AM

@julien: disqus c'est pratique mais le problème c'est que tu perds tout contrôle sur les commentaires qui ne sont plus stockés sur ton site mais chez disqus.
Je gère mon propre serveur qui héberge, entre autre, mon blog. Je suis le boss. je ne dépends de personne.
Passer par disqus ça serait un "abandon de souveraineté" qui ne me plait pas vraiment. Ou bien je passe aussi le blog sur un hébergeur extérieur, histoire d'être cohérent. Et c'en est fini de la liberté absolue.
Je n'aime vraiment pas dépendre d'autrui à ce point, certainement un mauvais réflexe de loup solitaire, ou d'ours, voire les deux Smile
Donc j'étudie le cas disqus mais tant que c'est tout ou rien (tout chez eux ou tout chez moi, sans position mixte) je garde tout chez moi...

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading