Microsoft a supprimé le site consacré à Silverlight pour intégrer les informations sur sa technologie au sein de son MSDN (Developer Network). Un mouvement qui ne va pas sans poser certaines questions sur l’avenir d’un environnement qui était encore, voilà peu, la seule méthode pour créer des applications Windows Phone.
ZDnet a remarqué la disparition du site Silverlight.net qui servait jusqu’à maintenant à concentrer les ressources liées à la technologie Silverlight. Cette dernière est surtout utilisée pour le développement de plateformes multimédia en ligne et surtout pour la création des applications sur Windows Phone 7. Or, depuis un certain temps, la technologie semble largement en perte de vitesse et les applications Windows Phone 8 se développent désormais avec un framework proche de WinRT (le JavaScript ne peut pas être utilisé).
Interrogée, Microsoft a répondu qu’il ne s’agissait que d’une opération de « consolidation » pour rassembler l’ensemble des ressources développeurs dans un lieu unique. Seulement, la firme a brisé au passage de nombreux liens pointant vers l’ancien site : « Nous réalisons que certains de nos clients ont pu rencontrer des problèmes pour accéder aux liens pointant vers du contenu qui résidait sur le site Silverlight original. Nous nous excusons pour la gêne occasionnée et travaillons à résoudre ces soucis ».
L’éditeur précise en outre : « La consolidation de ce contenu n’impacte pas l’offre Silverlight de Microsoft. Nous avons lancé Silverlight 5 en décembre 2011 et nous nous sommes engagés à supporter Silverlight jusqu’en 2021 ».
Une phrase relativement floue et qui n’engage à rien. D’une part, elle ne fait pas référence à une version en particulier, la mouture 5.1 étant d’ailleurs sortie entre temps. D’autre part, « support » ne signifie pas que de nouvelles versions seront lancées et que la technologie évoluera. Mary-Jo Foley de ZDnet rappelle d’ailleurs que les rumeurs pointent un abandon à plus ou moins long terme de la technologie.
Commentaires (69)
#1
nous nous sommes engagés à supporter Silverlight jusqu’en 2021
Enfin, ça va être de plus en plus facile pour eux quand dans 5 ans plus personne ne l’utilisera. Parce que ç’a bien l’air parti pour.
#2
Tant que le site de Silverlight Taiwan et Hikaru reste, ça me va.
" />
Mais évidemment, ça fait mal que Microsoft enterre ses propres technos, surtout quand on est développeur dessus (WP7 pour ma part).
ps : traduire consolidate en consolider c’est moche, ça serait plutôt réunir, fusionner dans le contexte.
#3
Mouais, les rumeurs vont dans tous les sens pour l’arrêt ou pas du développement de nouvelles versions de Silverlight.
Par exemple ici un exemple qui tendrait à prouver qu’une version 6 est bel et bien prévue. Il y a d’autres exemples qui pourraient montrer le contraire, personne ne sait au final (pas même Marie Jo Foley).
Sinon en tant que développeur, je peux dire que Silverlight nécessite certes un plugin, mais pour une application web (je dis bien application et non site web) de type LOB, il n’y a pas d’équivalent en termes de vitesse de développement, réutilisabilité, maintenabilité, confort de debug, et pour le résultat final, de réactivité côté client…
Pour développer en ce moment même en HTML5 (backoffice ASP.Net MVC, comme PCInpact), je peux dire que je regrette vraiment, mais alors vraiment Silverlight pour un tas de raisons techniques (support multi-browser horrible du HTML5, Javascript illisible et pas maintenable…). HTML5 c’est “hype”, c’est vendeur, mais au final c’est immonde à développer.
Pour moi le seul inconvénient de Silverlight, c’est de n’avoir pas été porté officiellement par MS sur Linux via Mono et Moonlight (Miguel de Icaza a fait son possible, mais sans soutien c’était un chantier trop important). Et je rappelle que Mac OS est officiellement supporté (donc 95% des machines dans le monde le sont).
#4
Vivement que Flash suive la même voie que Silverlight pour les sites web.
" />
#5
#6
nous nous sommes engagés à supporter Silverlight jusqu’en 2021
Et pendant ce temps, on achève bien les chevaux…
#7
#8
un petit lien vers les “web components” et Dart qui préfigure ce que sera la norme HTML 5 :
http://www.dartlang.org/articles/dart-web-components/
Pour tout ceux qui n’aime pas javascript (langage pourri par IE).
#9
#10
#11
#12
#13
#14
exacte unixorn, je comparais avec dot Net… Je préfère de loin l’original (java), il y a largement plus de FW composant dans le monde Java.
#15
#16
#17
#18
#19
Donc, MS a laissé tombé les activeX. Maintenant il laisse tomber Silverlight. Y a pas à dire, avec Microsoft, bonjour la pérennité des technologies de développement.
#20
#21
Une application qui n’est pas exécutée PAR (Et pas DANS) le navigateur n’est pas une application Web. Un application Flash n’est pas une application Web. Une application web est développée à partir des standards du Web. Il n’y a pas besoin de Wikipedia pour comprendre ça.
Maintenir une application web (pour Mac/Linux/Windows/autres) est genre 100 fois plus simple qu’une application “installée”, surtout c’est 10 fois plus simple à développer. Plein d’application Web sont utilisées en entreprise, et ça ne fait qu’augmenter.
AIR (flash) aussi marche très bien, la version 11 n’a rien à voir avec la version 6, comme Sylverlight.
#22
#23
#24
#25
#26
#27
#28
#29
#30
#31
#32
@hadoken : Dans certains navigateur, les plugins s’exécutent dans une sandbox, voir un process séparé, dans certains OS cela signifie que ce n’est pas le même espace mémoire. Flash utilise maintenant PPAPI sous Chrome et a aussi accès aux objets du navigateur (comme avant). Une application Native Client (comme le future flash sous Chrome) est une applications Native. Tant que Native Client n’est pas une norme, on ne peut pas les considérer les applications Native Client comme des applications Web.
Dart est compilé en javascript et c’est aussi un candidat au remplacement de Javascript donc en phase de normalisation. Dart n’utilise pas de Bytecode, mais est directement présent comme un script. Tout le monde peut reprendre le code de Dartium pour l’intégrer, ça aide.
#33
#34
#35
#36
#37
Bon j’ajoute mon témoignage de développeur:
" />
Je suis développeur depuis les années 80, j’ai pratiqué un grand nombre de langages y compris l’assembleur… jusqu’au C# depuis sa création avec lequel je réalise des applications diverses.
En // je monte des sites web depuis 1995 et chaque année je me demande quand on va bien pouvoir se débarrasser de cet infâme couple HTML/Javascript qui est lourd fastidieux, ancestral, illisible et générateur de bugs à gogo…
Les récentes améliorations du HTML5 et la profusion des frameworks javascript ne font qu’ajouter des couches plus ou moins réussies et de l’anarchie à un système qui ne tient pas la route face aux vrais langages que peuvent être Java, C++, C# etc.
Ok le HTML/JS rend de grand services mais pitié ne comparez pas ça à des solutions type C#/XAML infiniment plus robuste et moderne !
Depuis quelques mois je développe des applis pour Windows Phone 8 et plus récemment pour Windows 8 et bien je peux vous garantir que je vais bien plus vite avec le couple C#/Silverlight qu’avec le couple HTML5/Javascript ! On ne devrait même pas être autorisé à comparer !
Je pèse le pour et le contre depuis quelque temps pour faire des portages vers Android/iOS et j’ai donc testé PhoneGap qui est une bonne idée à la base… sauf que je pense que j’irai plus vite à recoder en Objective C ou Java/XML que de me faire mal avec HTML5/JS !!!
Le seul intérêt pour Microsoft d’avoir mis une solution de codage HTML5/JS pour ses nouvelles plateformes c’est de pouvoir attirer rapidement plus de développeurs… pour le reste HTML5/JS est bien pratique mais pour faire des apps de haut niveau c’est une technologie pour développeurs du dimanche !
#38
#39
#40
#41
@hadoken: merci de ton soutien ;-) et pour ton lien… Oui j’ai regardé Xamarin depuis le tout début mais je ne suis pas certain de gagner réellement du temps avec ça même si c’est tentant.
Car pour les applis c’est quand même la partie design/layout qui bouffe bcp de temps à mettre en place or on ne peut pas garder XAML pour faire de l’iOS ou de l’Android ! Résultat, quitte à utiliser les objets natifs de l’UI de chaque OS autant tout refaire sur l’OS en question… Après est-ce que vraiment ça me ferait gagner du temps d’avoir un tronc commun en C# au lieu de transcrire mon C# en Java ou Objective C, là je suis pas bien sur…
#42
#43
#44
#45
#46
Ca me fait toujours rire ceux qui me disent que Silverlight est une application Web.
Si Silverlight est du Web, est-ce que WPF l’est aussi ? Non ? Vous-êtes sur, c’est bien un client lourd ? Pourtant il s’execute aussi dans le navigateur (XBAP…).
Et sinon, Hadoken, t’es au courant que une des plus grande force de Silverlight c’est de n’avoir RIEN A FOUTRE du navigateur sous jacent ? Peu importe ses moteurs (html, js, WebCL, api de cryptage…), Silverlight travaillant totalement seul dans son coin.
Ah, oui, c’est vrai, tu l’as dit toit même que tu aimais cette aspect de SL. Mais c’est une application Web. Ca doit être sympa à relire un code écrit par un gars aussi logique, dommage que j’ai plus assez d’aspirine en stocke pour me lancer dans ce genre d’aventure :)
Sinon +1 pour dire que le HTML5 et les moulte FW JS qui se chamaillent autour ne sont pas encore assez mature. Quand t’essaye d’en faire t’as vraiment mal… Ok tu peux faire des trucs puissants, mais le nombre de contraintes (courbe d’apprentissage, outillag, supports des navigateurs, instabilité de la norme…) le rende rentable que dans de très rare cas.
#47
#48
Silverdark
" />
#49
#50
#51
#52
Je pense qu’on parle de la même chose entre system.data et system.ling.
Le problème est qu’il ont voulu concilier une approche object et une approche bdd. En plus avec des classes synchronisées (au niveau des méthodes,…) avec une base relationnelle. Les mécanismes d’héritages sont subtilement différents, et puis il n’y a pas de méthodes dans une table de bdd.
C’est clairement pas encore mure comme sujet. Un peu comme ajouter les design pattern en C++, cela marche mais cela rentre quand même un peu au forceps
#53
#54
#55
#56
#57
#58
#59
#60
#61
#62
#63
#64
#65
#66
#67
#68
#69