Mai 2012
HTML : le mythe universaliste
par Arnauld de La Grandière le Lundi 05 Avril 2010 à 09:50
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.
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.
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.
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.
|
4
3
2
1
Vos réactions (51 réactions)
Yohmi
[05/04/2010 10:21]
via MacG Mobile
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.
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.
Dr_cube
[05/04/2010 10:30]
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.
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.
Dambo
[05/04/2010 10:48]
via MacG Mobile
Article très intéressant !
Mais doucement les gars... C'est ferié aujourd'hui....
Article très intéressant !
Mais doucement les gars... C'est ferié aujourd'hui....
tdml
[05/04/2010 10:50]
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.
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.
Yohmi
[05/04/2010 10:56]
via MacG Mobile
@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. ;)
@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. ;)
Caramel10
[05/04/2010 10:57]
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.
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.
Un Vrai Type
[05/04/2010 11:06]
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 !
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 !
DualG4
[05/04/2010 11:07]
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...
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.
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...
Alex56
[05/04/2010 11:09]
Très mauvais article !
Très mauvais article !
Un Vrai Type
[05/04/2010 11:21]
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...
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...
Un Vrai Type
[05/04/2010 11:28]
@ 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...
@ 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...
Brewenn
[05/04/2010 11:34]
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.
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.
fcb
[05/04/2010 11:58]
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...
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...
GerFaut
[05/04/2010 12:13]
via MacG Mobile
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
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
4
3
2
1
Réagir
Cinq consignes avant de réagir :
- Rester dans le cadre de la dépêche. Pour des discussions plus générales, vous pouvez utiliser nos forums.
- Développer son argumentation. Les messages dont le seul but est de mettre de l'huile sur le feu seront modifiés ou effacés sans préavis par la rédaction.
- Respecter les acteurs de l'informatique et les autres lecteurs. Les messages agressifs, vulgaires, haineux, etc. seront modifiés ou effacés sans préavis par la rédaction.
- Pour toute remarque concernant le contenu de l'article, pour nous signaler une erreur, une faute d'orthographe, une omission, merci de nous contacter exclusivement par e-mail.
- Relisez-vous, et pour les utilisateurs de Safari profitez de l'aide du navigateur : activez le menu édition > Orthographe > Vérifier l'orthographe lors de la frappe.