HTML : le mythe universaliste

Arnaud de la Grandière |
L'information fait parler d'elle : on a porté Quake II en HTML5. Tout y est, la 3D accélérée à l'aide de WebGL, le multijoueur avec Websockets… Tout ça entièrement en HTML5. On s'émerveille face à la vidéo de démonstration. Il ne s'agit là rien de moins que la promesse de la fin des plug-ins !


Car s'il est bien un domaine où les plug-ins règnent en maîtres, c'est celui des webgames, qui par définition nécessitent l'exécution de code dynamique du côté client : si les applications web s'appuient plus ou moins sur du code exécuté du côté serveur, les jeux sont ceux qui exigent le plus du côté client. Si HTML5 s'avérait capable de s'affranchir de cette tâche sans encombre, sachant que qui peut le plus peut le moins, alors ce serait la fin des plug-ins. Armé de son navigateur, on se précipite pour essayer soi-même la démonstration.




Et là, on déchante quelque peu. Déjà, ça ne fonctionne que sur Safari et Chrome. Bon, Internet Explorer n'a jamais brillé pour son support du HTML 5. Quant à Firefox…, son support de WebGL, encore tout récent, est peut-être à blâmer. D'ailleurs, Safari et Chrome en eux-mêmes ne sont pas à la hauteur : il vous faudra télécharger la dernière nightly build de WebKit et Chromium. Mais ça ne s'arrêtera pas là : sur Mac OS X, il vous faudra installer MacPorts et Mercurial, faire diverses incantations dans le terminal pour installer des bibliothèques sonores, en faire d'autres pour récupérer un clone local du projet, d'autres encore pour mettre en place un serveur local, et récupérer les données du jeu, sans oublier de taper la commande dans le terminal pour activer WebGL dans WebKit, pour enfin espérer voir la démo fonctionner dans le navigateur. Quand ça ne coince pas tout simplement lors d'une des "six étapes faciles" d'installation décrites sur la page du projet, comme en témoignent les nombreux commentaires plus bas. On est très loin du simple chargement d'une page web autonome sur un serveur distant dans un navigateur lambda.

Peut mieux faire

Le premier Quake avait également servi de démonstration pour Native Client, le plug-in de Google permettant d'exécuter du code compilé dans le navigateur (lire : Google NaCl : du code natif dans le navigateur), toutefois au prix de quelques incantations, là encore.

À côté de cela, vous pouvez trouver un portage fidèle de Quake (premier du nom) en Flash, en allant simplement sur cette page. Mieux encore, vous pouvez installer le plug-in de Quake Live, qui n'est rien d'autre que le moteur de Quake III dans un plug-in.

Plus loin de Quake, mais tout en restant dans le cas d'école du FPS, on pourrait citer Phosphor avec Shockwave (qui ne fonctionne hélas toujours pas sur Safari en mode 64 bits), ou encore Interstellar Marines avec Unity, sans oublier InstantAction qui proposait un plug-in intégrant le Torque Engine, mais le portail est actuellement en cours de refonte pour proposer rien de moins que de véritables jeux complets du commerce, tels que Braid ou l'édition spéciale du Secret de Monkey Island, dans une page web.

Capture%20d%E2%80%99e%CC%81cran%202010-04-02%20a%CC%80%2017.35.20


La comparaison est sans appel pour les plug-ins : ils ne se limitent à aucun navigateur, les contenus qui en tirent parti sont autrement plus véloces et techniquement supérieurs, (nos tests de la démonstration de Quake II en HTML5 nous ont donné un framerate situé entre 13 et 40 images par seconde) même dans le vénérable Shockwave, et à plus forte raison dans la très prometteuse prochaine version d'Unity (lire : Unity enclenche la troisième). Par-dessus tout, ils sont commercialement exploitables tels quels, dès maintenant, sans autre manipulation que d'avoir à les installer une fois pour toutes. Sachant en outre que l'exécution de code au sein d'un plug-in est rigoureusement identique d'un navigateur à l'autre, alors que les différents moteurs JavaScript intégrés dans chaque navigateur disposent de leurs spécificités propres qui ne garantissent aucune homogénéité d'une configuration à l'autre, il faut se rendre à l'évidence : HTML5 n'est pas près de supplanter les plug-ins de sitôt.

Mariage forcé

Si certains voulaient voir dans la démonstration technique de Quake II en HTML5 l'illustration de lendemains qui chantent, débarrassés de toute contrainte propriétaire et fermée, il ne s'agit là en fait que de la preuve manifeste du contraire, et de la supériorité indéniable des plug-ins pour certaines tâches. Il faut admettre la réalité des faits : les plug-ins sont là pour durer, et continueront de remplir des tâches spécifiques qui resteront longtemps hors de portée des navigateurs à eux seuls. On pourrait arguer, à juste titre, que les jeux web sont loin d'être représentatifs de tout ce qu'on peut attendre d'un site web et qu'il ne s'agit là que d'un marché de niche. Mais précisément, ils sont symptomatiques de la faille dans la forteresse HTML : ce standard ne peut répondre à tous les besoins, alors qu'on pourra toujours créer un plug-in de toutes pièces pour proposer une réponse technologique à ce qui serait autrement une voie sans issue pour une simple page web.

Alors que tout laissait à croire que Google se rangeait résolument du côté du HTML5, la firme de Mountain View a dévoilé récemment avoir mis au point un nouveau système de gestion des plug-ins qui permet de les intégrer à son navigateur Chrome, avec Flash en tête de file (lire : Google, Adobe et Mozilla réinventent le plug-in).

Il nous faut donc sortir de l'opposition stérile entre HTML et plug-ins : ils sont voués à collaborer main dans la main, les uns palliant aux manques des autres et réciproquement. Certaines applications pourront fort bien se passer de tout plug-in, comme on espère que ce sera le cas un jour de la vidéo en ligne, et d'autres ne pourront jamais en faire l'économie.

Investir sur l'avenir

Et puisqu'il est question d'économie, les plug-ins disposent d'un autre avantage indéniable sur le code en JavaScript : ils permettent de protéger le code et les contenus, quand un JavaScript forcera de facto la distribution libre du code source. Tout au plus est-il possible de rendre la lecture du code plus absconse, mais c'est là une bien maigre consolation. Si l'on peut se satisfaire du partage des connaissances que ce procédé induit, il ne faut pas omettre pour autant que la liberté implique également la possibilité de choisir ou non de distribuer son code. Or la valorisation de la propriété intellectuelle est un élément crucial dans un certain nombre de domaines pour justifier des investissements, et cette valorisation devient impossible lorsque n'importe qui est susceptible de piller le fruit de votre travail, que vous soyez d'accord ou non. En admettant que HTML5 permette un jour de mettre sur pied des jeux du niveau de ceux cités ci-dessus, nul investisseur ne se risquera à monter un portail exploitant cette technologie si n'importe quel concurrent à l'autre bout du monde peut impunément se contenter de reprendre le code pour faire la même chose à moindres frais.

On mesure d'autant mieux ce besoin à l'aune de l'enthousiasme des éditeurs à se jeter sur l'App Store. Nombre d'applications qui y sont proposées ne sont rien d'autre qu'une nouvelle façon d'accéder au contenu en ligne, loin de toute notion de standard ouvert. Plus de HTML, plus de JavaScript, ces applications sont des plug-ins qui ont avalé un navigateur, et non l'inverse. Précisément parce que l'iPhone, l'iPod touch et l'iPad isolent leurs contenus de toute manipulation indésirable pour les éditeurs, le tout intégré à une solution de paiement. Voilà qui ouvre enfin la voie à une économie de l'information dématérialisée, et qui explique l'engouement de la presse et du monde de l'édition pour l'iPad.


Un voyage sans gouvernail

Lorsque le HTML est né en 1991, il avait pour objectif d'être un format de description simple et accessible d'un document formaté, intégrant images et texte stylé, et la forme la plus minime d'interaction à l'aide des liens hypertextes. À mesure de ses évolutions, il a été amené à prendre en charge des formes de plus en plus évoluées d'interaction, posant la question cruciale de l'exécution de code arbitraire côté client. Cette question porte en elle un paradoxe : le HTML a une vocation universaliste, sachant qu'il doit être susceptible d'être consulté depuis n'importe quel appareil capable d'accéder à un site web, mais l'exécution de code est au contraire, et par définition, spécifique à chaque configuration matérielle.

Le HTML répondait à des besoins dans un contexte donné, qui a incroyablement évolué. Les machines se sont multipliées et diversifiées, certaines sont très puissantes et d'autres beaucoup moins, l'accès au haut débit s'est généralisé, et il est clair que si nous devions repartir d'une page blanche pour concevoir un standard libéré de tout héritage pour être le plus adapté au contexte actuel, nous aurions quelque chose de très différent de ce qu'est le HTML aujourd'hui. Et qui peut dire en quoi consisteront les besoins de demain ?

Quant à elle, l'architecture des plug-ins pour navigateurs, introduite dans Netscape Navigator 2.0 à l'initiative d'Adobe pour son format PDF, a eu dès l'origine pour vocation d'offrir une solution aux fonctionnalités manquantes du HTML. Il devenait ainsi possible d'intégrer dans une page web n'importe quel format de fichier, un privilège jusque-là réservé aux seules images. Avec Shockwave, puis Flash, l'interaction s'étendait bien au-delà de ce qu'offrait le web des premiers temps. Et depuis se pose la question du bon équilibre à trouver, entre l'application native et le code interprété, pour répondre à tous les besoins de la meilleure façon possible.

Naissance du Web protéiforme

On aurait pu croire que l'absence de plug-ins sur la plateforme mobile d'Apple aurait pu renforcer HTML5, ce qui est vrai pour partie, mais c'est oublier à quel point la forme et la fonction sont intimement liées. C'est bien la diversité des machines qui a amené à une nouvelle évolution par la force des choses : à quoi rime le concept de rollover (l'événement généré par le passage du curseur sur une zone donnée de l'écran) lorsqu'il n'y a précisément plus de curseur ? À quoi rime le pilotage dynamique d'un objet à l'écran sur la pression maintenue d'une touche du clavier lorsqu'un clavier virtuel ne génère aucun événement qui puisse être surveillé par du code ? À l'inverse, même depuis que Windows 7 supporte les interfaces multitouch, aucune fonction standard de JavaScript ne permet d'utiliser plus d'un doigt. Firefox intègre le support des accéléromètres et du GPS (lire : Firefox prêt à utiliser l'accéléromètre des MacBook) : qu'adviendra-t-il des machines qui n'intègrent pas ces fonctions sur les sites qui en tirent parti ? On peut déplorer cet état de fait, mais il faut bien l'admettre : si l'on tient à faire appel à certaines fonctionnalités, on accepte que celles-ci ne soient plus accessibles à tous les terminaux, ou à l'inverse, on fait le choix du nivellement par le bas, du plus petit dénominateur commun, et on en revient au HTML des origines.

À vrai dire, la vocation universaliste du Web n'aura été mise en application dans les faits que bien peu de temps. Internet Explorer étant resté longtemps le mètre étalon des webmestres, nombre de sites ont refusé de fonctionner dans Safari et autres navigateurs alternatifs. Linux est longtemps resté le parent pauvre de Flash. Que dire du désarroi de Lynx, un navigateur internet exclusivement textuel, face aux sites Internet actuels, ou du navigateur intégré à la Freebox, ou encore des nombreux plug-ins qui n'ont jamais existé que sur Windows ?…

Quoi qu'il en soit, il est trop tard pour faire machine arrière : le web a déjà été scindé, morcelé, compartimenté. Certains contenus en ligne ne sont accessibles exclusivement qu'à partir d'un iPhone. D'autres ne le sont qu'à partir d'un PC, et qui sait encore quels contenus seront demain exclusifs à tel ou tel nouveau terminal. Pour l'heure, c'en est fini de l'universalisme du web. Si certains standards ouverts on rendu de bons et loyaux services, si d'autres standards propriétaires (par exemple la multiplicité de messageries instantanées) ont tendu avec plus ou moins de succès vers l'interopérabilité, nous sommes aujourd'hui face à une multiplicité de "bac à sables", et désormais en choisissant une famille de terminaux on fait également le choix des contenus auxquels on pourra ou non accéder, ou au mieux la manière dont on pourra les utiliser. Aujourd'hui, selon que votre navigateur sera un logiciel libre ou non dépend votre accès aux vidéos au format H.264. Selon que Flash est disponible ou non sur votre terminal, certains contenus pourront vous être inaccessibles. Si votre terminal n'a ni clavier ni souris, certaines applications, pourtant en HTML le plus pur, fonctionneront plus ou moins bien.

Au lieu d'opposer ces différents visages du web, peut-être nous faut-il au contraire apprendre à en tirer parti pour en faire une force. À chaque point d'accès, le web peut offrir une forme adaptée, utile, pratique, conviviale. Certains contenus n'ont de sens que s'ils sont utilisés à partir d'un iPhone, d'autres en revanche ne riment à rien sur cet appareil. Il en va de même pour le HTML5, les plug-ins, et tout ce qui transite par Internet : utilisons-les chacun pour ce qu'ils nous apportent. En les combinant, le résultat devient supérieur à la somme de ses parties. De Chrome OS qui mise tout sur les webapps à l'iPhone qui fait le pari de l'application locale et native, aucune voie n'a tort ou raison dans l'absolu. Réduit à sa forme la plus pure, Internet n'est guère qu'une série de tuyaux, à vous de choisir lequel correspond le mieux à votre besoin du moment.

avatar Anonyme (non vérifié) | 
Très bon article!!
avatar Yohmi | 
Article intéressant, mais je suis en désaccord avec certaines choses. D'une part, oser parler d'expérience utilisateur alors qu'il s'agit d'une expérimentation technique sur des bases non finalisées me parait absurde, d'autre part, et c'est surtout là où mon avis s'oppose, c'est de vouloir faire du navigateur web la chose à tout faire. Et de remercier les plug-un propriétaires qui sont donc des sortes d'applications à installer pour tourner ensuite dans le navigateur web. Là où ça coince, pour moi, c'est que je ne comprends pas pourquoi il serait indispensable, voire utile, de faire des choses aussi complexes via un navigateur web (hormis en réseau local d'entreprise peut-être), un navigateur étant fait pour naviguer. On se plaint des logiciels qui font trop de choses à la fois, et la promesse des plug-in c'est de faire encore plus de choses avec un seul et même logiciel… qui voudrait un éditeur de texte riche dans iTunes ? Même paradoxe. Je ne trouve même pas l'idée de faire tourner un jeu en HTML5 intéressante (à part juste d'un point de vue prouesse), et j'espère bien que si éviction des plug-in il y a, ce ne sera pas pour se retrouver avec les mêmes erreurs et horreurs en HTML5. Le web a besoin de texte, d'images, de menus, et de vidéos. C'est basiquement ce que devrait faire un navigateur, du mieux qu'il le peut (performance, police, mise en forme, etc.), et pas s'etaler sur plein de trucs qu'une application ferait forcément mieux mais "regarde c'est dans la même fenêtre. Bon, je dois fermer les autre car ça bouffe de la ressource, mais c'est formidable, non ?" Il n'y a que pour Chrome OS où cette vision a du sens, vu qu'il ne gère aucune application en dehors de son navigateur, et les applications seraient alors les plug-in. Pertinent ici car on a pas la possibilité de faire mieux ni autrement. Mais on est pas sur Chrome OS.
avatar Dr_cube | 
Il y a clairement un problème d'interfaces. Comme évoqué sur la deuxième page de l'article, certaines interfaces sont adaptées au PC et ne sauraient fonctionner sur iPhone, et vice versa. La solution vient de la plasticité des IHM : il faut que les interfaces soient pensées pour s'adapter au contexte d'utilisation. Si Apple autorisait Flash sur iPhone, dans l'état actuel des choses, la plupart des applets Flash seraient inutilisables : pas de clavier, pas de vrai drag, pas de curseur, etc. Pour moi la solution devrait être d'autoriser Flash sur iPhone, mais d'interdire la lecture d'absolument tous les applets Flash con!us pour PC. A la charge des développeurs de créer une IHM "compatible iPhone". Et il faudrait alors qu'Adobe et/ou Apple publie des design guidelines précises sur lesquelles les développeurs pourront s'appuyer pour créer des IHM homogènes et adaptées aux spécificités de l'iPhone. Quoi qu'il en soit, pour le moment je ne crois pas en la disparition de Flash, et encore mois en son remplacement par HTML5. Le plus gros avantage de Flash, c'est qu'il permet aux graphistes et aux programmeur de travailler main dans la main sur un même outil. Flash a tout misé sur la description visuelle de l'interface. L'outil graphique de conception est très puissant, et permet à des graphistes de travailler dans de bonnes conditions. Les programmeurs peuvent directement travailler sur les objets graphiques conçus par les graphistes. On n'a pas de SDK aussi puissant et permettant d'intégrer les graphistes dans la boucle en HTML5 ou JS. Pour aller un peu plus loin, on peut rappeler qu'avec l'iPhone Apple a tout misé sur les applications web. Steve Jobs pensait que c'était le moment. Palm aussi. Mais il était encore trop tôt. Ni la techno ni les utilisateurs ne sont prêts pour passer aux applications web et abandonner les applications natives. Il va falloir attendre encore quelques années et un produit clé pour porter cette évolution.
avatar dambo | 
Article très intéressant ! Mais doucement les gars... C'est ferié aujourd'hui....
avatar tdml | 
Comment !? du code compilé serait plus performant que du code interprété !? Ah ben tu parles d'une nouvelle ! Google est dans le vrai : ce qu'il faut, c'est réinventer la façon dont les plug-ins interagissent avec le navigateur, et éventuellement faire en sorte qu'ils se chargent à la demande. Penser à s'en débarrasser est absurde.
avatar Yohmi | 
@tdml Je ne parle que de ce qui est actuel, si les plug-in deviennent formidablement efficaces, je présume que l'on arrivera enfin à la maturité des webapps et ma position actuelle sera évidemment caduque. ;)
avatar Caramel10 | 
Bon article et bon remarque de Yohmi. J'ajouterai pour compléter que les services rendus à l'origine sur Internet n'ont pas forcément été conçus pour un navigateur : e-mail, irc, newsgroups, im. Mais bien pour fonctionner sur des logiciels spécifiques écrits pour remplir leur fonction. Tout cela pour appuyer l'argument selon lequel la réponse à tout les besoins ne se trouve pas forcément dans le navigateur. Le succès de l'appstore est là pour le démontrer.
avatar Un Vrai Type | 
C'est comme si j'avais pondu un article après le test du QuickTake affirmant que jamais la photo numérique pourrait percer... Franchement, comparer une première démonstration - exploit - développée comme un cas d'école à des applications évoluée depuis 20 ans... Au début de flash, personne n'aurait parié un copek pour la vidéo... Comparé à la grande avancée technique et imbattable de RealPlayer... Enfin, l'article est largement biaisé parce que, comme le dit Yohmi, ce n'est qu'une démonstration technique. Il sera une fois finalisé inutile d'installer des librairies ou d'utiliser les webkit et autre chromium. L'apologie du "Installez tous Silverligth pour surfer sur 3 pov' site qui clignotent" c'est juste débile. Ce que vous oubliez dans cet article c'est : "À chaque point d'accès, le web peut offrir une forme adaptée, utile, pratique, conviviale." Sauf qu'ils sont exclusifs !
avatar DualG4 | 
[quote]Mieux encore, vous pouvez installer le plug-in de Quake Live, qui n'est rien d'autre que le moteur de Quake III dans un plug-in.[/quote] L'intérêt du html 5 est d'avoir quelque chose d'universel, en allant sur Quake Live, j'obtiens: "Incompatible browser", "Support for Mac & Linux, along with alternative browsers is under development." Quake Live est un bon exemple des plugins qui ne sont destinés qu'à certaines plateformes...
avatar Alex56 | 
Très mauvais article !
avatar Un Vrai Type | 
par contre les plug-ins permettent de : 1) Faire payer pour l'accès à des technologies distribuées sur internet (ce que le protocole http ne permet pas, mais que le minitel permettait des 2 manières connues : Au temps utilisé ou à l'accès...) - Ce n'est pas une mauvaise chose pour l'industrie, faut bien bouffer - 2) Former des gens à une technologie donnée et accentuer la pression sur les salariés du domaine (voir le fonctionnement des SS2I en France). 3) Rendre responsable l'utilisateur des mauvais fonctionnements 4) Ne pas tenir compte de paramètres comme l'optimisation des plateformes, l'autonomie... 5) on en revient à la gestion multitâche collaborative de Mac OS 9 finalement, le plus gros écrase tout jusqu'au plantage final... :D Bref, il serait intéressant de ressortir cet article dans 3-4 ans. Le vrai problème du HTML5, c'est que au contraire du "web 2.0" le grand public en a prit connaissance AVANT qu'il ne soit utilisable (voir qu'il existe concrètement). Le Web 2.0 existait et était déjà utilisé depuis des années... Lorsque le HTML5 sera mature (dans 5-10 ans, si ça avance aussi "vite") on pourra l'opposer aux plug-ins En attendant, les plug-ins sont le seul moyen de faire de la 3D multiplateforme etc... Et on ne parle que d'un pont entre du code html et openGL... Alors pour le support du SVG (code dans la page web) ce n'est pas demain la veille...
avatar Un Vrai Type | 
@ tdml : Je suis d'accord, ce n'est pas idiot d'utiliser le moteur d'affichage d'un navigateur web comme moteur universel de l'interface. Au contraire, ça prends tout son sens (voir Qt et XUL...) Le problème est que si on utilise WebGL, cette fonctionnalité est native et donc fonctionne partout sans ajout de code. Ça n'oppose donc pas les plug-in au natif. @Dr_cube : On est d'accord pour flash, il a au moins 5 bonnes années devant lui. Parler du HTML5, c'est parler du web pour dans 5 ans...
avatar Brewenn | 
Fondu dans la masse pas facile de voir loin, mais pas certain non plus que celui qui arrive à prendre un peu de hauteur puisse réagir en fonction de ce qu'il voit derrière, sur les cotés et devant et de ce qui se profile à l'horizon, tout dépend aussi des connaissances acquises, du vécu et de la bonne vue de la tête qui dépasse et qui regarde plus loin. Article très réaliste.
avatar fcb | 
Tout à fait d'accord avec Un Vrai Type, cet article est un poil partisan, et ne tient pas compte de l'immaturité du futur nouveau standard qu'est HTML 5. Et flash, perso, je ne lui donne même pas 5 ans, il suffit juste qu'un environnement de dev html 5 bien foutu apparaisse sur le marché. Cela dit, tout n'est pas à jeter (-; C'est intéressant tout de même...
avatar GerFaut | 
Cher Arnaud, d'habitude je suis assez d'accord avec vos articles. Mais ici il y a un présupposé de votre part, voire deux, erroné dans son principe. D'une part vous battez en brèche un peu cyniquement l'essence universelle de l'Internet : si vous connaissiez un peu votre histoire de l'Internet, et je suis sûr que c'est le cas, vous vous rappèleriez justement cet esprit qui soutend ce mode de communication depuis ses origines et qui paraît logique en plus d'être humaniste : pour bien communiquer il faut se comprendre. Plus le langage utilisé est universel, mieux on se comprend. Ce fut l'objectif du html. Malheureus
avatar _HAL_ | 
Quand vous décrivez l'installation de Quake II, vous décrivez l'installation du serveur ce qui n'a rien à voir avec l'html5 et les plugins.
avatar jeanba3000 | 
Alex56, très mauvais commentaire ! La prochaine fois tu développes et tu argumentes. Merci au rédacteur pour cette analyse intéressante et aux commentateurs qui y apportent de vraies réflexions, à l'opposé de la haine ordinaire des imbéciles habituels dès qu'il est question de Flash et des plugins (qu'on soit pour ou contre).
avatar YannK | 
[b]Modéré par la rédaction [/b]
avatar GerFaut | 
Je dis donc (ras le bol de me faire couper dans mes commentaires par l'iPod) : malheureusement les marchands du temple sous les traits de Microsoft sont venus dévoyer ce bel esprit en imposant des formats propriétaires. La mercantilisation du web a continué à pervertir la chose. Au delà de constater, et à vous lire de l'approuver, il faut lutter incessamment contre cet état de fait. La dimention humaniste du web doit être préservée à tout prix. Le html en est un moyen à contrario des plugins qui enferment la création dans des carcans propriétaires et limitatifs. Nous revenons ici insidieusement dans le débat sur la création et le piratage. Et ce débat est éminemment suspect quand il est largement soutenu par des sociétés multinationales (Adobe
avatar manu1707 | 
Bon j'ai lu les lignes en gras Je comprend que dalle En gros ça marche pas et c'est pas prêt d'arriver quoi ...
avatar osc | 
Assez d'accord avec les commentaires critiques : remettre en cause les fonctionnalités proposées par un standard qui n'est pas encore stabilisé sur la foi d'un "exploit" pas si exploit que ça, ça me paraît franchement bordeline. J'admets que HTML 5 va probablement bouffer des PDM à Flash (je pense notamment aux lecteurs vidéos type YouTube), mais je pense que dans l'ensemble il est encore trop tôt pour tirer la moindre conclusion, tant on est encore loin d'une quelconque stabilisation (et comme l'a dit quelqu'un, si demain sort un environnement de développement en HTML 5 de la mort qui tue, ça pourrait aussi profondément remettre en question l'équilibre des forces entre HTML et les plugins propriétaires). Je ne suis partisan de rien (encore que j'apprécie moyennement Flash qui fait hurler mon CPU et par suite mon ventilo), mais je pense très franchement qu'il est encore trop tôt pour tirer la moindre conclusion. Sans compter qu'avec la révolution des webapps qui se profile (et que commence à matérialiser timidement Chrome OS) je doute que toutes ces considérations sur "le-navigateur-à-tout-faire-qui-ne-peut-finalement-pas-tout-faire" puisse demeurer valables encore très longtemps (ou alors on aura un "super navigateur" qui sera l'OS en lui-même, avec de nouveaux protocoles, de nouvelles façons de proposer des webapps, etc., bref, des choses encore franchement hypothétiques...).
avatar Arnaud de la Grandière | 
@ gerfaut : les outils n'ont pas d'idéaux. Les gens qui les créent, et ceux qui s'en servent, éventuellement oui. TCP/IP permet dès son origine la création de protocoles fermés et propriétaires, qui sont loin de se limiter au mail, au web, au ftp et consorts. C'est aussi parce que des entreprises ont pu garantir la pérennité de leurs investissements qu'elles ont contribué au développement et à la popularité d'Internet. S'il avait fallu attendre la finalisation de HTML5 pour profiter de la vidéo dans une page web, imaginez à quoi ressemblerait Internet aujourd'hui…
avatar kubernan | 
@yannK : [i]Ça serait comme de comparer un prototype d'un produit qui sortira dans 3 ans avec un produit abouti qui a pu mûrir pendant 2 ans... [/i] Pas du tout. Je crois que vous n'avez pas compris l'article. Certes la partie introductive est sans doute trop longue et fait tomber certains dans le panneau. Mais le fait que l'HTML 5 soit récent ne change strictement rien à l'argumentaire principal qui confrontent deux architectures différentes.
avatar GerFaut | 
@ nonoche : exact sur la première partie de votre réponse. Erreur sur la seconde : les entreprises ont perverti et récupéré l'Internet (je ne parle pas ici d'informatique mais bien d'Internet). Tous les outils utilisés sur Internet sont issus d'applications libres et ouvertes. Si la réponse à Flash
avatar divoli | 
[b]Modéré par la rédaction[/b]
avatar divoli | 
[b]Modéré par la rédaction[/b] Monsieur Divoli est prié de réviser ses bonnes manières
avatar nlex | 
Je trouve l'article intéressant, même si je ne suis pas d'accord avec tout (et surtout le point de départ de l'argumentation : prendre un jeu vidéo comme point de départ est un peu idiot quand on sait que c'est justement la chose qui sera le plus difficile à réaliser en HTML5 (d'où le challenge, d'ailleurs…) et sur lequel il n'y aucune demande, ce n'est je pense pas assez souligné dans l'article. Je pense aussi que ce genre d'article devrait être signalé comme des éditos, ce qu'ils sont, c'est simplement un point de vue, parmi d'autres. En attendant je pense que personne n'en demande autant à HTML5, s'il pouvait déjà nous amener la vidéo, un peu d'animation, les webfonts etc. ça serait déjà BEAUCOUP.
avatar BKN1 | 
Si seulement Apple pouvait nous pondre un Apple media tool pour html5. En attendant Flash CS5...
avatar divoli | 
Dingue ! Le post de YannK totalement supprimé ! Et les miens également, avec en plus une remarque déplacée ! Bravo la censure !
avatar Arnaud de la Grandière | 
"remarque déplacée", j'adore… surtout ne change rien, Divoli
avatar Florian Innocente | 
[b] @ divoli : Arnauld est passé avant moi pour la modération [/b] mais j'ai été très étonné dans la réaction de YannK que ce dernier ne réclame pas le rétablissement de la peine de mort pour Arnauld qui a commis, disons-le tout net, un véritable crime (voire plusieurs) avec la rédaction de cet article. Il y a des lecteurs qui seraient très intéressants à observer au quotidien pour voir dans quelle mesure la virulence de leurs propos déposés sur Internet (et là le sujet est juste l'HTML 5, on n'a même commencé à parler du Pape, du président, etc…) sont représentatifs de leurs relations avec les gens dans la vie de tous les jours, ou s'ils voient dans les réactions ouvertes sur les sites, une possibilité de libérer la vapeur et de se défaire de frustrations diverses et variées. On devrait vraiment être remboursés par la Sécu pour l'aide qu'on apporte parfois.
avatar jpvz74 | 
Merci pour cet article intéressant … et partial. Sa principale vertu est de lancer un débat. C'est une thèse … à laquelle il manque une « antithèse » et une « synthèse » … … avant de laisser à chacun conclure selon son propre regard sur le web. • HTML 5 est une révolution conceptuelle en marche (un autre regard). • HTML 5 est encore incomplet et perfectible. • HTML 5 n'est surtout "bien traité" par encore aucun navigateur, ni par aucun éditeur. En résumé, il reste du pain sur la planche ! (même s'il est déjà directement utilisable de façon dégradée … … et débloque de nombreux culs-de-sac du XHTML) Si d'autres ne le font pas (et si j'en trouve le temps ? ) … … je m'efforcerais de développer point par point ce "Nouveau Regard" et ses conséquences. Amicalement.
avatar Atlante | 
Pas génial les remarques hors sujets en bas des commentaires censurés parce qu'ils en quotent d'autres. Surtout si vous continuez à developper le sujet censuré ensuite :) Pour la peine de mort, je suis contre et ceux qui sont pour mérite la peine capitale. Mis à part le style d'écriture toujours aussi lourd, c'est 10 x trop tôt tirer des conclusions sur l'HTML5. C'est comme si vous testiez la béta de Windows Live Messenger Mac aujourd'hui, c'est évident qu'on pourra qu'être sceptique à l'idée qu'une telle foutaise puisse fonctionner un jour. xD La conclusion de l'article était posée avant la première ligne écrite, c'est évident qu'en l'état actuel le HTML5 ne peut que collaborer avec les plugins "main dans la main". Je sais pas si ça vaut le coup d'en faire un sujet d'article today, mais dans deux ans pourquoi pas? Si le but était de dire que jusqu'à une certain point les deux collaboreront ensemble, je ne pense pas que cela soit vrai non plus. Quand le HTML5 sera prêt, il remplacera les plugins et tant que ce ne sera pas le cas, il n'existera pas pour le grand public.
avatar Arnaud de la Grandière | 
C'est un faux argument que d'expliquer les manques de HTML5 par son immaturité. Les fonctionnalités utilisées pour la démo de Quake II ne sont pas prévues pour être intégrées à HTML5 à l'avenir, à ma connaissance (les deux seules étapes qui seront supprimées à l'avenir c'est l'activation de WebGL et le téléchargement de WebKit - soit dit en passant il ne me semble pas que WebGL fasse partie des spécifications d'HTML5 pour l'heure, on pourra donc avoir un navigateur HTML5-compliant qui ne supporte pas WebGL). D'autant qu'il y a un peu deux poids, deux mesures dans cet argumentaire, sachant que nombre d'internautes ont réagi à cette annonce comme si ça démontrait effectivement que HTML5 pouvait supplanter les plugins. Et on pourrait citer nombre d'autres fonctions qui ne seront pas intégrées à HTML5, comme par exemple la possibilité de faire de la vidéoconférence, ce que permet Flash. Sans oublier les autres arguments avancés dans l'article.
avatar BioSS | 
Vous parlez de l'immaturité de l'HTML5… Mais ce n'est pas la question. Le truc, c'est qu'un plugin affiche le même résultat sur tous les navigateurs. Installe Unity et tu pourra jouer à ce que tu souhaites sur la plupart des plateformes. En HTML5, à cause de la disparité entre les navigateurs et leurs petites infidélités sur la justesse du rendu, impossible d'avoir un contenu "pixel-perfect" comme on dit. Et avant que tous les navigateurs soient parfaitement syncro, et qu'en plus ils soient suffisamment déployés dans les chaumières, on en a pour 10 ans easy.
avatar fcb | 
Le problème du plugin, c'est qu'il n'est pas normalisé, souvent propriétaire, et qu'il doit être développé plateforme par plateforme (ce qui n'est pas toujours fait avec le même enthousiasme et le même sérieux). Dans un monde idéal, un standard pour tout gérer serait la panacée. Chaque couple OS/navigateur n'aurait plus qu'à réussir un super-acid-test, pour être déclaré "HTMLx-compliant". D'où l'engouement que suscite HTML 5, qui ne va pas, certes, en l'état actuel des choses, proposer toutes les fonctionnalités possibles et nécessaires, mais fait un grand pas dans la bonne direction, celle de l'utilisateur.
avatar Ast2001 | 
Très bon article. D'une objectivité qui fait plaisir. Un petit point qu'il faut signaler: parler de flash en tant que bouffeur de CPU, c'est tout simplement stupide si on ne prend pas en compte le programme qui tourne et la façon dont il a été développé. Dans ma boîte, nous avons un développement flash qui en gros correspond à un éditeur graphique de workflow (que nous n'avons pas imaginé un seul instant développer en autre chose qu'en actionscript). Le développeur d'un des modules a réussi à diviser par 10 la consommation CPU d'une partie de son code en utilisant un nouvel algo. C'est un des drames de flash, selon la façon dont actionscript est utilisé, cela peut totalement changer les mesures. Un autre point à ne pas négliger: la qualité générale de l'environnement Flash Builder ainsi que du modèle de développement associé. Imaginer qu'HTML 5 va remplacer flash en 5 ans, c'est totalement irréaliste.
avatar Anonyme (non vérifié) | 
[quote]À l'inverse, même depuis que Windows 7 supporte les interfaces multitouch, aucune fonction standard de JavaScript ne permet d'utiliser plus d'un doigt.[/quote] Bon, déjà c'est pas une "fonction javascript" mais un évènement DOM mais ça c'est du détail. Ensuite on s'en fout un peu puisque Safari Mobile a ses propres events (et chrome aussi, probablement) http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariWebContent/HandlingEvents/HandlingEvents.html#//apple_ref/doc/uid/TP40006511-SW1 C'est en cours de spécification de toute façon, mais peu importe : on se fiche de Fennec, d'Opera et encore plus d'IE mobile qui sont laaargement en retard. RIM utilisera webkit pour son navigateur, ce qui veut dire iPhone + Androïd + Blackberry. En attendant une spec officielle, qui est prévue : http://www.w3.org/2010/webapps/charter/#aide Je me répète, mais je trouve très bien qu'Apple n'autorise que Safari sur iPhone. Ca évite justement le casse-tête de gestion des navigateurs qui bien sûr permettent moins de chose que Safari. Apple a créé un navigateur pour Safari, avec tout ce qui faut pour créer des vraies webapps, avoir accès à des choses très puissantes, c'est pas pour qu'on se tape des portages de navigateurs qui n'ont rien prévu ou presque. Apple accepte des navigateurs alternatifs du reste, mais pas des moteurs alternatifs et franchement... tant mieux pour ceux qui veulent faire des webapps.
avatar Anonyme (non vérifié) | 
Ce qui est dérangeant avec les plugins c'est qu'on ne sait pas exactement ce qu'ils font et à quoi ils ont accès sur notre machine. Que Flash puisse accéder à ma webcam et à mon micro, désolé, ça me fait peur. Cet HTML5, justement parce qu'il oblige à avoir de la transparence, les sources sont visibles, est une véritable bonne nouvelle. Bien sûr qu'il faut protéger les créations, bien sûr que certains créateurs ne veulent pas montrer leurs sources, bien, qu'ils restent avec leurs plugins fermés. Pour les autres grands paranos qui rêvent d'un web meilleur, utopiste et open source, vive le HTML. Le jour où j'aurai le choix de voir des vidéos, car c'est la base de ce débat, sans aucun plugin, ça sera un adieu définitif et sans regret à Flash. Qu'on laisse la liberté aux gens ! Ceux qui veulent avoir Flash, Unity, Silverlight pour jouer à des jeux dans leur navigateur (!) grand bien leur fasse. Pour les autres qui ne veulent pas ou qui n'ont pas besoin de ça, pour ceux qui veulent juste des pages web modernes avec de la vidéo comme on a aujourd'hui des images, HTML5 est une grande et prometteuse nouvelle. Le choix, laissez nous le choix !
avatar ispeed | 
Pas facile de traiter un article comme celui-ci sans avoir un bon niveau technique en informatique. Mais je pense que tout a été dit et de toute façon on verra dans un avenir proche
avatar sgm | 
@innocente "On devrait vraiment être remboursés par la Sécu pour l'aide qu'on apporte parfois." mdrrr Pour l'exutoire aussi.
avatar Brewenn | 
Peut être une reconversion du site possible, car peut on parler journalisme et objectivité en ces lieux. Mais comme me disait un journaliste d'investigation de mes relations, la ou ..... passe la presse trépasse.
avatar laurange | 
Je trouve l'article bien trop long et fouillis pour finalement dire : ouais ça dépend… Le HTML5 est un nouvel outil, et comme tous les outils il va devenir intéressant quand les utilisateurs sauront comment s'en servir. Perso je parie sur la 3D, une sorte de SecondLife en html à moyen terme. Avec le web qui arrive dans la télé et la 3D à la mode, les constructeurs vont pouvoir attirer les consommateurs sur des nouveautés et relancer les ventes. Il y a une confusion toujours présente entre internet (le réseau) et le web (les applications sur le réseau) à l'heure où la bataille de la neutralité du net (donc d'internet) doit être claire dans les esprits. @ Ast2001 : ton expérience est intéressante mais extrêmement rare pour le grand public. Le flash je le rencontre dans : les pubs, les jeux et les vidéos. Et à part pour des sites de grande marque souvent lourds, le flash n'a pas pris l'avantage sur l'ihm proposée par le html/javascript.
avatar michaelprovence | 
Pour moi le flash c'est très bien et je m'en tape des avis de Steve Jobs ! Pour l'ipad ça sera le mode "stand-by" et si google chrome OS est bien j'irais plutôt vers ça..
avatar Macmmouth | 
Quake II..un jeu de 1997. Les recommandations matérielles de l'époque c'était : Pentium 90, 16 Mo de ram, pas besoin de carte 3D. Juste pour comparer : Super pi 32M prenait 72 H sur P90, aujourd'hui on en est à 7m20s. C'est juste 600 fois plus rapide. 256 à 512 fois plus de mémoire. Les différences de perf en 3D, je n'en parle même pas... Quel est l'exploit de faire tourner quake II sur un ordinateur d'aujourd'hui ? Et en plus ça rame.. 10 fps sur un Macbook.
avatar misterbrown | 
Alala.. Scepticisme sur HTML.. Mais ca me donne juste envie de rejouer à Quake 2 !! :) @Macmmouth.. EUhm.. avec une 3dfx voodoo, une Ati Rage 128 et un Pentium2.. ca marchait qd meme mieux..... " Config jouable : Pentium 133 Mhz, 32 Mo de RAM Config recommandée : Pentium 200 Mhz, 64 Mo de RAM, carte 3D"
avatar lolo57 | 
Oui, ben tout ça c'est du vent, moi mais clients ce qu'ils réclament d'html5 c'est la vidéo et les webfonts. Cela suffirait à leur bonheur. Il y a les 100 gros sites du web qui ont besoin de tout un arsenal technologique, et les millions de sites web associatifs, personels ou de petites boites qui se contentent très bien de la version actuel d'Html. Il ne faut pas oublier que plus la technologie est puissante et plus sont utilisation est compliqué et donc cher. Je crains que la multiplication des technologies ne crée de facto un web à deux niveaux, le web des multinationales, et le web des petites boites et associations auquel on est tous attachés. Ce que je crains c'est que plus personne ne regarde les sites sans 3D et autres effets mirifiques, de la même manière que plus personne ne regarde de film noir et blanc. Si l'on souhaite créer des applications performantes, c'est déjà possible il suffit de voir les milliers d'applications de l'app store qui ne sont pour beaucoup d'entre elles que des lecteurs de flux xml spécialisés. Moi je suis pour qu'un navigateur web reste un outil léger, qui rende possible la diffusion d'information écrite, sonore et vidéo de manière simple. A vouloir en faire un outil universel on va en pervertir le sens. Vive mosaic :-)
avatar Macmmouth | 
@MisterBrown Juste pour ne pas me faire passer pour un menteur : [url=http://www.docmirror.net/fr/linux/howto/apps/Quake-HOWTO/Quake-HOWTO-3.html]Prérequis de quake II[/url] Le scepticisme est plus que justifié. Il y a un gouffre de performance entre plugin et html5. La seule chose que l'on puisse dire c'est que le canvas html5 est totalement inadapté à ce genre d'application. 600 fois plus de puissance nécessaire pour faire la même chose.. et bé. Que faut-il dire de plus ? Et après on va faire un procès à flash parce qu'il est trop gourmand ? Non mais c'est une blague.
avatar omega2 | 
Que je sache, WebGL ne fait pas partie de la norme html5. WebGL est une extension aux canva qui est géré par le "consortium Khronos Group" un groupe qui ne fait pas partie du W3C (le groupe qui gère entre autre la norme HTML) même s'ils ont des membres en commun. Autre détail, pour jouer à quake 2 dans un navigateur, on a quand même besoin de faire tourner un serveur à côté. La vidéo ne dit pas dans quelle mesure le serveur intervient dans l'ensemble. Est ce que ça se limite à la gesion des monstres ou est ce que ça fait du précalcul d'affichage? En plus de tout ça, il faut rajouter des librairies audios ce qui n'est pas non plus très "html5 only". Au final, qu'est ce que quake 2? De l'html + du webgl + des librairies anexes + un serveur en java. Entièrement en html5 dites vous? Je ne vois pas la même chose de mon côté. Finalement, il y a au moins un tier de l'article qui est hors sujet et pour arriver à quoi comme conclusion? Juste qu'un jeux écrit en html5+webGL (norme non finalisé) est moins performant que du code natif et qu'on aura donc toujours besoin de plugin quand la rapidité d'exécution est un critaire majeur ou quand on veut cacher son code. Et ben dites donc c'est de la nouvelle ça. _HAL_ > Donc pour toi c'est le serveur qui gére l'ambiance sonore et pas le navigateur? Donc en fait la moitié du jeux ne serait même pas géré par le navigateur? Diantre.
avatar Arnaud de la Grandière | 
@ omega2 : à en juger par certaines réactions à l'article, l'affaire est loin d'être aussi entendue que vous semblez le dire…

Pages

CONNEXION UTILISATEUR