ton développeur doit sûrement avoir raison, silverlight c’est peut être bien !!!
mais comme on est pas expert je te renvoie vers une mine d’infos ;
http://www.interfaces-riches.com...

PS : pour du XAML en action :
http://www.danslesruesdavignon.c...

"Le principe de Flex c’est:

Fichier Flex => Compilateur Flex (en Java) => Génération d’un SWF =>
Transfert sur le navigateur => Exécution

Principe de Silverlight:

Fichier XAML => Transfert sur le navigateur => Exécution

Moi je vois les avantages suivants:

– Comme le fichier XAML (de Silverlight) est du XML, il peut être lu par
des machines et permettre son référencement par exemple (par de
GoogleBot par exemple). Pour Flex, ce qui passe sur le réseau, c’est un
binaire que l’on ne peut pas indexer. Bref, si on utilisait que cela,
c’est la fin de Google.
(ndYAM : bon Ok Adobe vient d’annoncer le référencement de flash dans Google).

– Comme le fichier XAML et du XML, et c’est ce que l’on envoi au
navigateur, cela veut dire que côté serveur, on peut très facilement le
générer dynamiquement avec PHP, Perl… ou n’importe quoi d’autre. Dans
le cas de Flex, si on veut faire cela, il faut créer un fichier Flex sur
le serveur, le compiler et envoyer le résultat (bref, cela coûte très
cher). On verra peut être apparaître des servlets J2E pour faire ça,
mais ça limite à Java et ne change rien à la lourdeur de la tâche.

– Dans le cas de Silverlight, on peut développer ses propres balises (en
incluant des DLL .Net écrite avec ce que l’on veut). Cela veut dire
que l’on peut écrire de chose très complexes (même dynamiquement en PHP)
en enrichissant le langage. Avec Flex, il faut modifier le compilateur
pour arriver au même résultat. Du coup, on doit avoir son propre
compilateur (et on ne suit plus le Flex officiel).

– Avec Silverlight, on peut modifier dynamiquement son arbre d’affichage
en chargeant des nouveaux bout de XAML et cela même depuis JavaScript.
Bref, on peut programmer un peu comme en AJAX aujourd’hui. Avec Flex,
c’est pas possible puisqu’il faut passer par le compilateur.

– Avec Silverlight, on peut choisir son langage de programmation (pour
les extensions pas exemple). Avec certains langages il faut compiler,
mais pour d’autre même pas besoin, c’est à la charge du navigateur
(Javascript par exemple).

– Personnellement, je trouve qu’ActionScript est bien en dessous de C#.
D’ailleurs l’utilisation des langages (et même des binaires .Net) permet
de réutiliser du code provenant d’application de bureau par exemple. On
peu même partage du code entre le serveur et le navigateur (alors qu’en
ActionScript…).

– Flash commence en se libérer (en tout cas il y a des annonces en ce
sens), mais aujourd’hui, il n’y a pas vraiment de lecteur Flash libre
qui tiennent la route (peut être la faute aux spécifications de Flash
qui on beaucoup changé depuis le début)."
Ne vous attachez pas à la forme, c’est juste un échange de mail.
Merci,

Yam

Aussi géniale et puissante soit elle, pour percer, il faut proposer des outils adaptés et c’est là où Adobe fait fort, le framework Flex et l’environnement auteur Flash sont simples à aborder.

PS : on remarque que chez Sun aussi ils utilisent des Mac !

En fait, au tout début je pensais que Air permettrait de le faire du jour où j’ai entendu parler de leur histoire de badge. Le pire c’est que ça serait possible mais il faudrait que Air utilise la même librairie que celle du lecteur Flash, or il embarque la sienne propre. Par contre, rien n’empêcherait au passage du badge vers l’application Air, de préciser que le runtime doive préférer la librairie du lecteur en cours d’utilisation et de conserver le fenêtrage utilisé par le navigateur. Probablement complexe à mettre en œuvre, surtout en multi-plateformes, mais clairement pas impossible.

Ensuite il faudrait un bac-à-sable béton pour garantir que la sécurité de l’exécution soit strictement identique dans Air et dans le navigateur.