Se connecter avec
S'enregistrer | Connectez-vous

Microsoft veut du HTML 5 au lieu de Silverlight

Par - Source: ZDnet | B 36 commentaires

Microsoft a confirmé que Silverlight serait une plateforme de développement pour Windows Phone et un outil de distribution multimédia sur Internet, mais sa stratégie pour une solution cross-platform a changé pour privilégier le HTML 5.

De la nécessité de composer avec ses concurrents

C’est un aveu très intéressant de la part de Microsoft qui explique que le langage hypertexte est le seul à être réellement commun à toutes les plateformes, « iOS inclu ». Cette volonté de vouloir composer avec le système d’exploitation à la pomme est un grand changement par rapport à l’attitude de la marque sur le marché des OS de bureau où ses parts de marché lui permettent de mener la danse sans faire cas de ses concurrents.

De la nécessité du HTML 5

C’est aussi un changement de discours de la firme qui affirmait il n’y a pas si longtemps que Silverlight serait son environnement cross-platform (web, PC, outils mobiles). Redmond a confirmé qu’il travaillait sur une nouvelle version  mais il est vrai que depuis la présentation d’IE9, la société est très attachée au HTML 5 et on ne peut que se féliciter de ce dévouement vers ce standard au lieu d’une technologie propriétaire.

Afficher 36 commentaires.
Cette page n'accepte plus de commentaires
  • dark-sorrow , 1 novembre 2010 11:49
    Il ne manque plus que leur navigateur suive bien les normes W3C :o 
  • zeroweb , 1 novembre 2010 13:25
    c'est surtout que silverlight ne pénètre pas
  • -2 Masquer
    ultrabill , 1 novembre 2010 13:26
    Citation :
    Il ne manque plus que leur navigateur suive bien les normes W3C :o 
    Ce sera le cas avec IE 12 :o 
  • scandinave , 1 novembre 2010 16:01
    Sérieusement au lieu de raler, vous avez testé la nouvelle version?
    Je suis pas un expert en norme W3C mais développant pas mal de site, IE9 ne me pose plus de problème de compatibilité. Et l'interface est largement à la hauteur des autres concurrents.
    Faudrait arrêter de tirer à boulet rouge dessus en permanence
  • Daweb , 1 novembre 2010 16:21
    Idem.
    Seuls les utilisations très poussées des CSS 3 par exemple ne sont pas encore parfait.
    Mais pour le reste, ca va bien.
  • ultrabill , 1 novembre 2010 16:31
    Citation :
    Sérieusement au lieu de raler, vous avez testé la nouvelle version?
    Je suis pas un expert en norme W3C mais développant pas mal de site, IE9 ne me pose plus de problème de compatibilité. Et l'interface est largement à la hauteur des autres concurrents.
    Faudrait arrêter de tirer à boulet rouge dessus en permanence
    Je vais être tatillon : ce n'est pas la "nouvelle" version mais la "prochaine" version
    MS a déjà fait un effort avec IE8, encore trop lourd mais techniquement moins à la ramasse que ses ancêtres.
    IE9 est effectivement pas mal, il faudrait qu'il soit moins "pataud" en fait :p 
  • popopow , 1 novembre 2010 20:34
    zerowebc'est surtout que silverlight ne pénètre pas

    Silverlight banderait-il mou ?

    Ok je sors....
  • TheStarvingStudent , 2 novembre 2010 11:41
    et IE9 gère le RGB? non? ah bon.
  • -1 Masquer
    vardon , 2 novembre 2010 13:45
    Tiens... Microsoft aussi? Et Flash alors?
  • Kenelm , 2 novembre 2010 14:27
    Je trouve ça con.

    On est en train de faire du HTML5 un machin qui fait tout, mais ceux qui sont derrière ont l'air d'oublier qu'on a jamais réussi à faire un truc qui fait tout et qui fait ça bien. Le HTML aux dernières nouvelles c'est pour faire des documents, et ça devrait s'en tenir à ça.

    Si certains sites font plus que des documents, genre Facebook qui aujourd'hui n'est rien d'autre qu'un truc de communication avec un serveur, faudrait laisser tomber le HTML pour passer à autre chose, comme Flash, Silverlight, ou AIR, un autre truc d'Adobe.
    Suffit de voir cette mode sur Android et iOS de faire des "applications" qui reproduisent essentiellement la même chose que le site web sont une très bonne idée : parce que ce qu'elles fournissent sort clairement du cadre d'un document. Et quand on voit ce qu'il faut pondre en HTML rien que pour faire un truc comme un système de commentaire comme celui-ci, on se dit qu'il y a clairement un problème, parce que d'autres technos font ça bien mieux, et ça se met en place bien plus rapidement.
    Et si c'est pas convaincant, suffit de comparer les ressources nécessaires pour afficher une page web d'un site "moderne", avec les ressources nécessaires pour une application native qui fait la même chose : la différence est phénoménale.

    On fait tout et n'importe quoi avec une techno qui a même pas ça pour but, mais qui se contente de suivre aveuglément comme un moustique attiré par une ampoule. Faudrait p'tet commencer à tracer une limite et cloisonner les choses, parce que Flash et Silverlight ont carrément leur place sur internet.
  • vardon , 2 novembre 2010 14:55
    KenelmJe trouve ça con.On est en train de faire du HTML5 un machin qui fait tout, mais ceux qui sont derrière ont l'air d'oublier qu'on a jamais réussi à faire un truc qui fait tout et qui fait ça bien. Le HTML aux dernières nouvelles c'est pour faire des documents, et ça devrait s'en tenir à ça.Si certains sites font plus que des documents, genre Facebook qui aujourd'hui n'est rien d'autre qu'un truc de communication avec un serveur, faudrait laisser tomber le HTML pour passer à autre chose, comme Flash, Silverlight, ou AIR, un autre truc d'Adobe.Suffit de voir cette mode sur Android et iOS de faire des "applications" qui reproduisent essentiellement la même chose que le site web sont une très bonne idée : parce que ce qu'elles fournissent sort clairement du cadre d'un document. Et quand on voit ce qu'il faut pondre en HTML rien que pour faire un truc comme un système de commentaire comme celui-ci, on se dit qu'il y a clairement un problème, parce que d'autres technos font ça bien mieux, et ça se met en place bien plus rapidement.Et si c'est pas convaincant, suffit de comparer les ressources nécessaires pour afficher une page web d'un site "moderne", avec les ressources nécessaires pour une application native qui fait la même chose : la différence est phénoménale.On fait tout et n'importe quoi avec une techno qui a même pas ça pour but, mais qui se contente de suivre aveuglément comme un moustique attiré par une ampoule. Faudrait p'tet commencer à tracer une limite et cloisonner les choses, parce que Flash et Silverlight ont carrément leur place sur internet.

    je suis bien ton raisonnement, mais peut-être qu'HTML5 offre à terme plus de possibilités?
    Pourquoi des boites comme Apple ou Microsoft vont-elles dans ce sens? Tu me diras que ce ne serait pas la première fois que des "gros" se plantent...Mais au-delà des modes, ils ont (je suppose!) etudié la question?
  • magellan , 2 novembre 2010 15:12
    Citation :
    je suis bien ton raisonnement, mais peut-être qu'HTML5 offre à terme plus de possibilités?
    Pourquoi des boites comme Apple ou Microsoft vont-elles dans ce sens? Tu me diras que ce ne serait pas la première fois que des "gros" se plantent...Mais au-delà des modes, ils ont (je suppose!) etudié la question?

    En fait, je rejoins totalement Kenelm.

    Le problème n'est pas tant que le HTML5 soit un mauvais principe, mais qu'il va le devenir à terme. Pour comparer, c'est le concept du tuning: "donne la chance à monsieur tout le monde de faire du custom... et sens tes yeux pleurer du sang en observant le résultat".

    A tout vouloir embarquer dans une seule technologie, on rend la chose de moins en moins simple à maintenir. L'avantage concret de dissocier le conteneur (HTML) du contenu (Flash/silverlight/applet... peu importe quoi d'ailleurs), c'est de pouvoir manipuler "sainement" le contenu de manière séparée du conteneur. Là, le HTML5 ouvre une boîte de pandore qui est de sur accumuler les fonctionnalités dans un seul et même code.

    Autre chose dérangeante, c'est l'idée même du "standard". Rappelons nous que le HTML est supposé être LE standard, LA norme qui doit mettre tout le monde d'accord. Est-ce le cas? Hélas non, tant parce que MS a massacré la norme à travers des versions scandaleuses de IE, que parce que même les plus proches de la normes interprètent celle-ci de manière quelque peu douteuse. Donc, de fait, on en arrive à des absurdités comme l'obligation de valider un même code sur X navigateurs, ce qui est techniquement débile! Cela reviendrait, sur un terrain industriel, de dire ceci:
    "J'ai fabriqué une vis au standard M8, à tête BTR... mais je dois la tester dans les filetages effectués par les tarauds de chez Tartampion, Toto, BozoInc. etc etc, parce que chacun voit la norme comme il l'entend".

    Aussi stupide qu'impossible à tolérer dans le monde industriel. Et pourtant, nous le tolérons sur le web. Va comprendre.

    Dernier point:
    Celui qui crée de la "richesse" à travers le flash par exemple, recherche à en permettre l'exportation sur tous les sites. Ce n'est pas pour rien que Youtube file le code à balises HTML pour embarquer leur lecteur, que l'on peut aisément intégrer des jeux flash sur les pages... etc etc. Là, avec le code "intégralement" présent dans la page, plus de possibilité de partage et de notoriété, rien qu'un bousin imbuvable à traiter pour les devs sans compétence. Pire encore: une erreur de copier coller, et plus d'application fonctionnelle, ou alors comble de la connerie, une appli déformée et buggée au possible. N'oublions jamais que le HTML n'est pas du compilé, mais de l'interprété, et que les interpréteurs sont très (trop?) permissifs.
  • dodutils , 2 novembre 2010 16:17
    Ce qui me plait dans HTML5 c'est la possiblité offertes par les API file et database, on peut à partir de là faire une application "complète" sans avoir besoin d'un serveur, donc pas besoin de Objective C sur iOS ou JAVA sur Android, ensuite on couple ça à du jQuery pour l'interface et hop.

    Beaucoup "d'applications" iPhone ne sont en fait que de simples interface HTML en liaison avec un serveur que l'ont pourrait très bien faire tourner à partir de Safari sous d'autres plateformes.

    Après il restera toujours le problème de l'inter-opérabilité toute théorique entre les navigateurs qui complexifie pas mal les développements, il faut en permanence s'assurer que ce que ce qui est fait affiche réagit de la même façon sous IE/FF/Safari/Opera/Chrome et c'est une perte de temps phénoménale !
  • magellan , 2 novembre 2010 16:26
    Citation :
    Ce qui me plait dans HTML5 c'est la possiblité offertes par les API file et database, on peut à partir de là faire une application "complète" sans avoir besoin d'un serveur, donc pas besoin de Objective C sur iOS ou JAVA sur Android, ensuite on couple ça à du jQuery pour l'interface et hop.

    J'ai un peu de mal à comprendre ce que tu dis.
    1) Une "application" complète? J'ai un peu de mal à saisir ce que tu veux dire, car soit tu localises tes composants sur ta machine (pseudo client lourd), soit tu déportes ton contenu côté serveur (client léger). Entre les deux, quoi qu'il arrive, tu dois héberger de la donnée (sauf à avoir des produits finis sans évolution, comme les jeux par exemple).
    2) Si tu passes par du Jquery, c'est que tu attaques une BDD, donc... un serveur, non? Quel est alors l'intérêt de tout embarquer dans un HTML complexe à mort? Autant séparer le conteneur (formulaire), du contenu fonctionnel (ajouts d'applets/silverlight ou peu importe quoi), c'est plus simple à tous points de vue:
    - Maintenance plus aisée: tu as les sources séparés pour chacun de tes composants, pas tout accumulé dans un formulaire imbuvable
    - Livraison simplifiée: tu ne livres que le composant touché, par toute la page qui, en conséquence, doit être entièrement réévaluée
    - Délais de réponse raccourci: évident, puisque tu n'as pas un temps énorme pour simplement piger le code vérolé qui s'est inséré dans ton code HTML

    Je n'y vois que peu d'intérêts, si ce n'est que pour quelques acrobaties sympas (graphique notamment, pour ne pas avoir ces abominations plein écran en flash par exemple). Ajouter de l'ergonomie, de l'esthétique, et même du contenu, ok... mais rendre la page impossible à maintenir, je passe mon tour.
    Et quid des performances de l'interpréteur? Comme tu le dis ici
    Citation :
    près il restera toujours le problème de l'inter-opérabilité toute théorique entre les navigateurs qui complexifie pas mal les développements, il faut en permanence s'assurer que ce que ce qui est fait affiche réagit de la même façon sous IE/FF/Safari/Opera/Chrome et c'est une perte de temps phénoménale !

    On obtiendra jamais (je crains) une chose unifiée, propre et fiable. Cela dure depuis plus d'une décennie ce cirque, et ça n'a pas réellement progressé, même si MS pousse à la roue pour améliorer son IE.

    Donc, pourrais tu expliquer ce que tu voulais dire? J'ai peur d'avoir mal compris.

    Sinon:
    http://www.korben.info/wallaby-convertir-du-flash-en-html5.html
    Ou comment fournir un code bien pourri aux devs qui vont devoir mettre le nez dans du généré...
  • dodutils , 2 novembre 2010 17:15
    @magellan pour répondre à tes questions :

    Quand je parle d'application complète je veux dire application non client-serveur autonome donc "complète" à elle toute seule.

    jQuery est une librairie Javascript bien pratique pour gérer une interface HTML au niveau DOM/Events/Ajax tout en générant une interface HTML "agréable" via jQuery-UI, pas grand-chose à voir avec les bases de données dont la gestion se fait côté serveur en JAVA/PHP/ASP.

    Pour ce qui est de la maintenance ça peut se faire proprement, en séparant bien les fichiers .html .js .css sachant que grâce à jQuery tu peux gérer tous les DOM/Event depuis des .js et laisser tes HTML "propre" sans mélange avec du code javascript, après tu peux aussi éclater tes .js en leur donnant des noms explicites avec un contenu minimum spécifique à telle ou telle gestion d'évènement ou tel ou tel .html par exemple.

    Quand à la vitesse d'interprétation, cela suffit pour la plupart des applications de type "gestion" (gestion de contact, bibliothèque de livres avec jaquettes, gestion de compte etc...) où la vitesse n'est pas importante.

    Après c'est sûr que je peux aussi faire des .EXE ou des .JAR mais tout dépend du besoin et de la cible.
  • magellan , 2 novembre 2010 18:10
    Whoops... j'ai rattaché le nom d'un package qui est présent dans un de mes projets (que mes prédécesseurs ont nommés visiblement à tort Jquery) et qui me sert à accéder à mes BDD.... j'ai eu la bêtise de croire que ce bastringue était une librairie standard de la Jvm!


    Et merci pour ces précisions. :hello: 
  • magellan , 2 novembre 2010 18:12
    Sinon petite remarque: le temps d'accès est justement chronique sur une app de gestion, car cela altère notablement le travail des personnes qui accèdent aux données, et qui plus est, cela dépend aussi de la volumétrie. tu me parles d'une petite biblio perso avec quelques milliers d'enregistrements, ok, petite volumétrie, mais quand tu as la gestion d'un stock de références, là, difficile de tolérer les secondes qui s'accumulent. Note qu'en plus, si tu es client d'outil de gestion (ie les sites d'achat en ligne par exemple), tu ne saurais accepter du retard et du délai lors des recherches... d'où un travail d'indexation fort et de bonne réflexion sur le modèle de données en amont;)
  • dodutils , 2 novembre 2010 18:32
    @magellan : j'ai bien précisé "non-client serveur", donc on reste dans le domaine de l'application de gestion locale personnelle, mais même comme ça le moteur de la base de donnée utilisé par l'API (SQlite je crois) est relativement rapide et donc la requête sera gérée par SQLite, du coup HTML5/Javascript n'aura la plupart du temps qu'à mettre en forme le résultat de la requête.
  • Kenelm , 2 novembre 2010 20:18
    Citation :
    Ce qui me plait dans HTML5 c'est la possiblité offertes par les API file et database, on peut à partir de là faire une application "complète" sans avoir besoin d'un serveur, donc pas besoin de Objective C sur iOS ou JAVA sur Android, ensuite on couple ça à du jQuery pour l'interface et hop.
    On prend ça, on couple à ça, à partir de ça... et on pond une tonne de code. Putain suffit de voir tout ce qu'il y a comme code derrière des trucs à la con, alors qu'en trois ligne on fait la même chose en mieux sur une autre techno.

    Rien qu'avec Visual Studio n'importe quel teubé fait une appli plus performante, plus stable, plus compatible, et plus rapidement. Regarde Adobe AIR, et tu vas pleurer. Et regarde le méconnu Microsoft Expression, et là tu vas te pendre. Ça fournit un outil de design d'application Silverlight qui me laisse juste sur le cul. Pour tester, je me suis lancé le défi de faire une appli Silverlight qui récupérait des infos de bourse, avec affichage des courbes et tout en tout. Ça m'a pris vingt minutes, et j'ai pas tapé une ligne de code. Et quand je dis vingt minutes, c'est montre en main, auquel il faut ajouter la découverte du logiciel.

    Mais non, on continue de vouloir tout rassembler sur un format qui ressemble de plus en plus à rien. Quand je vois que y'a plus moyen de faire tourner un navigateur sur un PC qui y'a dix ans avait aucun problème à aller sur internet, je me dis que y'a un problème. Mon appli Silverlight par contre, elle tourne au poil sur ce vieux PC, et elle est carrément au-delà de ce que j'aurais pu faire même en HTML5 dans le même délai de temps.

    Sinon j'en ai franchement j'en ai rien à taper des possibilité du HTML5. Le HTML4 permet déjà de formater tous les documents dont on peut rêver, et rien que le javascript c'est déjà de trop. DOCUMENT, c'est le mot à retenir. Faire un truc interactif avec tout le bordel, faut laisser ça à une autre techno, le HTML est pas fait pour ça, et suffit de voir la complexité de la chose pour le comprendre.
  • dodutils , 2 novembre 2010 22:25
    @Kenelm : Visual Studio ? tout dépend quel langage car VB.NET C++ C# ? quand à la compatibilité à part sous Windows c'est plutôt vide.

    C'est sûr que je peux aussi faire plus simple plus rapide avec d'autres langages, sauf qu'ici on parle de langage et d'interface accessibles depuis n'importe quelle plateforme "grand public".

    Et quoi de plus "universel" aujourd'hui que le HTML ? il est donc normal de vouloir faire le faire évoluer pour y inclure des technologies récentes.

    Quand à ton argument de ne pas pouvoir faire tourner un navigateur sur un ancien PC... ce n'est pas la faute du HTML mais le plus souvent du Flash présent dans les pubs qui est une vrai calamité.

    Et pourtant Flash est lui aussi un outil plutôt "universel", sauf que la plupart du temps Flash est utilisé pour faire des animations et que côté performances il n'a jamais été à la hauteur pour ça.

    Ceci dit, faire tourner des applis .NET ou JAVA sur d'anciennes machines ce n'est pas mieux non même si .NET est plus rapide et que les deux sont très gourmands en mémoire (pour une ancienne machine).

    Faire du HTML pur et dur aujourd'hui c'est revenir des années en arrière, sans interactivité, et ça personne ne le veut, donc même si tu sembles bien énervé à propos de HTML5, son utilisation va continuer à se propager, lentement mais sûrement je pense, moi même je ne suis pas un afficionados mais les API de HTML5 me plaisent bien et me permettront de faire un certain nombre d'applications fonctionnant aussi bien sous Windows, MacOS, Linux, iPhone, Android...
Afficher plus de commentaires