Le site officiel de Silverlight disparaît au profit d’une section dans MSDN
Encore un signe évident ?
Le 10 décembre 2012 à 12h21
2 min
Logiciel
Logiciel
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)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/12/2012 à 14h57
Le 10/12/2012 à 14h59
Le 10/12/2012 à 15h00
Le 10/12/2012 à 15h00
@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.
Le 10/12/2012 à 15h05
Le 10/12/2012 à 15h14
Le 10/12/2012 à 15h20
Le 10/12/2012 à 15h24
Le 10/12/2012 à 15h29
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 ! " />
Le 10/12/2012 à 15h31
Le 10/12/2012 à 15h44
Le 10/12/2012 à 16h22
Le 10/12/2012 à 16h23
@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…
Le 10/12/2012 à 16h26
Le 10/12/2012 à 16h43
Le 10/12/2012 à 16h51
Le 11/12/2012 à 10h02
Le 11/12/2012 à 11h27
Le 11/12/2012 à 14h52
Le 11/12/2012 à 15h19
Le 11/12/2012 à 15h38
Le 11/12/2012 à 20h47
Le 11/12/2012 à 23h51
Le 12/12/2012 à 23h05
Le 13/12/2012 à 00h05
Le 10/12/2012 à 14h13
Le 10/12/2012 à 14h14
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.
Le 10/12/2012 à 14h15
Le 10/12/2012 à 14h18
Le 10/12/2012 à 14h19
Le 10/12/2012 à 14h25
Le 10/12/2012 à 14h25
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.
Le 10/12/2012 à 14h25
Le 10/12/2012 à 14h27
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.
Le 10/12/2012 à 14h29
Le 10/12/2012 à 14h32
Le 10/12/2012 à 14h35
Le 10/12/2012 à 14h36
Le 10/12/2012 à 14h42
Le 10/12/2012 à 14h48
Le 10/12/2012 à 14h54
Le 10/12/2012 à 12h35
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. " />
Le 10/12/2012 à 12h49
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.
Le 10/12/2012 à 12h50
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).
Le 10/12/2012 à 12h57
Vivement que Flash suive la même voie que Silverlight pour les sites web. " />
Le 10/12/2012 à 12h58
Le 10/12/2012 à 13h23
nous nous sommes engagés à supporter Silverlight jusqu’en 2021
Et pendant ce temps, on achève bien les chevaux… " />
" />
Le 10/12/2012 à 13h48
Le 10/12/2012 à 13h57
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).
Le 10/12/2012 à 14h04
Le 10/12/2012 à 14h06
Le 10/12/2012 à 14h07
Le 10/12/2012 à 14h12
Le 10/12/2012 à 17h36
Le 10/12/2012 à 19h02
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.
Le 10/12/2012 à 19h08
Le 10/12/2012 à 19h59
Silverdark " />
Le 10/12/2012 à 21h34
Le 10/12/2012 à 21h47
Le 10/12/2012 à 22h10
Le 10/12/2012 à 22h24
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
Le 10/12/2012 à 22h57
Le 11/12/2012 à 00h32
Le 11/12/2012 à 07h14
Le 11/12/2012 à 07h14
Le 11/12/2012 à 08h01
Le 11/12/2012 à 09h29
Le 11/12/2012 à 09h49
Le 11/12/2012 à 09h52