Flex vs. Silverlight - Conclusion

Certains aspects de Flex et de Siverlight n'ont pas été évoqués dans cette série d'article. En particulier, je vous ai épargné les comparatifs concernant les formats vidéo et audio, les codecs pris en charge, les capacités 3D ou encore les mécanismes de streaming qui sont évidement important pour ces deux technologies mais qui compte surtout dans des contextes d'intégration de données multimédia, ce qui n'était pas tout à fait le propos de mes articles. En effet, j'ai évoqué en priorité le développement d'application d'entreprise et je vous laiise consulter les nombreux sites web qui traitent volontiers de ces sujets.

Pendant des années, et encore aujourd'hui, Flex/Flash a démontré sa maturité, sa performance et sa capacité à adresser de nombreux types d'application. Silverlight, malgré le retard avec lequel la première version est sortie, a sû le rattraper en réutilisant la CLR du framework .Net, plus avancée que le Player Flash, mais surtout qui s’appuye sur tout l’ecosystème .Net tant en terme de langage avec C#, qu’en terme d’outillage.

Ainsi, les deux technologies ont aujourd’hui (en version 3) des capacités équivalentes et quand une fonctionnalité n’existe pas dans l’une, la version suivante comble rapidement le vide. Les perspectives de la version 4 beta de l'une et de l'autre le démontre bien.
En terme de développement, Flex semble plus simple à aborder lorsque l’on s’attarde sur le code écrit, tant en XML (MXML est globalement moins verbeux que XAML), qu’en AS et C# (pour l’appel de services par exemple ou la création/le parsing de XML en C# qui utilise une API plus complexe qu’en AS).

Même si l'usage d'APIs comme celles d'ArcGIS Server rendent cette question moins cruciale (car pas ou peu de développement coté serveur), l’écosystème dans lequel ces applications seront déployées est souvent le critère déterminant. En effet, même si Flex et Silverlight s’intègrent parfaitement partout où il est possible de faire au moins du XML / HTTP, leur technologie de communication respective avec le serveur facilite grandement le développement mais, du coup, elle relie la technologie cliente avec la technologie serveur. Ainsi, la culture et les choix technologiques de l'entreprise en termes de plateforme de développement deviennent un critère essentiel. On verra plus rarement des développeurs Java ou PHP s'orienter vers Silverlight alors que Flex s'intègre plus naturellement avec ces environnements. De la même manière, le choix de Flex sera moins naturel dans un contexte où la plateforme de développement .Net est déjà largement adoptée.

Enfin, la cible des utilisateurs est egalement un critère déterminant sachant que pour une cible grand public, le Flash Player reste le plus déployé à l’heure actuelle alors que pour des applications internes, la disponibilité du plugin Silverlight ou Flash est beaucoup plus maitrisable et peu plus facilement s'anticiper.

En conclusion

Outre le caractère difficile de la tâche, trancher de manière définitive sur ces technologies serait quelque peu péremptoire et au final un mauvais conseil. Choisir l'une ou l'autre de ces deux technologies n'est de toute manière pas une erreur. Flex comme Silverlight sont des solutions complètes, éprouvées et évolutives. La vrai question est donc: quelle est la bonne technologie RIA pour mon projet ? Au-delà des critères techniques évoqués dans mes différents articles, c'est sans aucun doute la culture et l'expérience des équipes qui travailleront sur le projet qui sera décisif.

Les technologies de RIA vont encore évoluer dans les prochaines années et dans ce domaine les tendances et les leaderships peuvent rapidement changer. JavaFX est récent mais peut encore séduire et JavaScript avec HTML 5 n'a probablement pas fini de surprendre sur ces capacités. Le développement des RDA (Rich Desktop Application) est également un axe de développement à suivre avec une volonté des éditeurs, à assez court termes, de faire converger les deux environnements.

Dans les prochains mois, arcOrama reviendra sur ce vaste sujet en se recentrant sur les enjeux plus spécifiques aux APIs web ArcGIS.