Discussion :

[Hinault Romaric]

Quels Mythes sur le HTML5 se révèlent être vrais ?
Un Web évangéliste de Mozilla remet en cause les fausses hypothèses sur le langage


Le HTML5, bien qu’étant encore en cours de standardisation a déjà fait l’objet de beaucoup de débats et d’affirmations.

L’un de ces débats populaires est de savoir si le langage peut rivaliser ou remplacer les applications natives.

Dans un récent billet de blog, Chris Heilmann un Web évangéliste principal de Mozilla, remet en cause plusieurs des fausses hypothèses formulées sur le futur standard du Web.

Par exemple, les problèmes de performances du HTML 5. Pour Heilmann, « la comparaison des performances du HTML 5 avec celles d’une application native est comme comparé un costume taillé sur mesure avec celui acheté en boutique ». Comme pour dire que les applications natives sont développées et optimisées pour un environnement unique, alors que HTML5 doit être aussi souple que possible, indépendamment de la plateforme.

La seconde fausse assertion sur le HTML5 est qu’il ne peut être monétisé. Considérer qu’une plateforme basée sur « les technologies du Web ouvertes n’a pas de modèle de monétisation, c’est comme dire que le Web ne peut être monétisé » estime Heilmann.

Heilmann cite comme autres non-mythes, le fait que le HTML5 ne peut pas être utilisé hors-ligne et le manque d’environnement de développement pour le langage.

Enfin, l’évangéliste de Mozilla pense que bon nombre de mythes du HTML5 sont liés à la comparaison des solutions développées avec le langage aux solutions natives, pourtant celui-ci offre beaucoup plus d’avantages comme : la possibilité d’écrire une fois et déployer partout ; le partage sur le Web ; la mise à jour simple des fonctionnalités ; une communauté de millions de développeurs, etc.

En fait, le véritable problème du HTML5 – qui entraine son rejet par certains – est l’accès au matériel pour Heilmann, qui prend pour exemple les terminaux iOS qui ne permettent pas au HTML5 d’accéder à la caméra, au carnet d’adresses, etc.

Mais, la fondation Mozilla espère briser ces barrières et a déjà mis au point un ensemble d’API permettant d’accéder à ces éléments. De plus, la société travaille sur une galerie ouverte pour les applications Web et un OS mobile qui permettra d’exploiter le plein potentiel d’un dispositif en utilisant les standards du Web ouverts.



Source : L'article de Chris Heilmann


Et vous ?

Que pensez-vous de l'analyse de Heilmann ?

Quels autres mythes sur HTML5 se révèlent vrais ou faux ? Pourquoi ?

[Lutarez]

la possibilité d’écrire une fois et déployer partout

Oui, reste qu'il faut prendre en considération tous les navigateurs et leurs implémentations "maisons", souvent la version de ces navigateurs, ainsi que les préférences utilisateurs (JS activé ?). Sans oublier la taille des écrans et les versions mobiles.

En ce sens, je ne voit clairement pas où est l'atout car on peux faire strictement la même chose en C/C++, Java, .Net, Python, Delphi, Ruby, etc,

le partage sur le Web; la mise à jour simple des fonctionnalités

Je ne vois pas d'atout particulier ici. Les distributions Unix, via leur gestionnaire de paquets, font un boulot parfait pour cela. Et pour les autres systèmes, les Stores tendent maintenant à occuper ce rôle.

une communauté de millions de développeurs

Comme tout langage à son public, et dans la mesure où il n'existe pas d'alternative au HTML, heureusement qu'il a le "monopole".

l’accès au matériel pour Heilmann, qui prend pour exemple les terminaux iOS qui ne permettent pas au HTML5 d’accéder à la caméra, au carnet d’adresses, etc.

Heureusement j'ai envie de dire ! J'ai pas envie de me faire contaminer le PC en ouvrant une page web moi !

Sérieusement, je peux comprendre qu'on veuille améliorer les navigateurs, mais de là à en faire des remplaçants d'OS, ça me sidère ! Je préfère télécharger et installer une petite application qui interroge des Web Services que devoir laisser les pleins pouvoirs à un navigateur !

[stailer]

En fait, le véritable problème du HTML5 – qui entraine son rejet par certains – est l’accès au matériel pour Heilmann, qui prend pour exemple les terminaux iOS qui ne permettent pas au HTML5 d’accéder à la caméra, au carnet d’adresses, etc.

Mais, la fondation Mozilla espère briser ces barrières et a déjà mis au point un ensemble d’API permettant d’accéder à ces éléments.

Ben comme PhoneGap, grâce à qui on peut développer une appli HTML5 capable d'accéder aux contacts, à la caméra etc.

Voir l'API ici :http://docs.phonegap.com/en/2.2.0/index.html

Pour IOS,Android, Blackberry et Windows 8

[grunk]

Je ne vois pas d'atout particulier ici. Les distributions Unix, via leur gestionnaire de paquets, font un boulot parfait pour cela. Et pour les autres systèmes, les Stores tendent maintenant à occuper ce rôle.

Pour côtoyer régulièrement des utilisateurs "lambda" pour qui une mise à jour est juste un truc chiant à faire (et du coup ne les font jamais), une appli hébergé à quand même un gros avantage.
Tu fais ta mise à jour sur le serveur et tout le monde l'a reçue sans avoir rien d'autre à faire.

Pour le coup avec une appli lourde à part faire un process de maj invisible à l'utilisateur (pas forcément top) qui imposera sans doute un redémarrage de l'appli y'a pas de solution.

[Voyvode]

« la comparaison des performances du HTML 5 avec celles d’une application native est comme comparé un costume taillé sur mesure avec celui acheté en boutique ».

C'est sûr qu'il y a un monde entre un portage de Doom et une app pour consulter Facebook… Heu non, c'est un mauvais exemple.

La seconde fausse assertion sur le HTML5 est qu’il ne peut être monétisé.

Faux débat. S'il n'est pas forcément évident de créer une app lucrative en HTML5 façon iPhone, cette technologie sera encore longtemps utile pour vendre quelque chose en ligne.

En fait, le véritable problème du HTML5 – qui entraine son rejet par certains – est l’accès au matériel pour Heilmann, qui prend pour exemple les terminaux iOS qui ne permettent pas au HTML5 d’accéder à la caméra, au carnet d’adresses, etc.

Non. Le véritable problème est que le HTML5 (+ Javascript) veut faire comme du natif alors qu'il n'a pas était conçu pour cela. Dévier une chose de sa fonction primaire permet de découvrir et d'évoluer, mais cela ne marche pas à tous les coups.

L'analyse de Heilmann ressemble surtout à de l'auto-persuasion dans la désillusion générale.

[Lutarez]

Pour côtoyer régulièrement des utilisateurs "lambda" pour qui une mise à jour est juste un truc chiant à faire (et du coup ne les font jamais), une appli hébergé à quand même un gros avantage.

Autant dans un contexte professionnel, cela peut être gênant (dans les petites entreprises surtout), autant pour un particulier, si l'utilisateur ne se met pas à jour, ce n'est pas le problème du développeur. Certes, il manquera des mises à jours/sécurité, mais il n'y aucune solution au "problème humain" Et pis faire un système de mise à jour automatique est loin d'être sorcier et (assez) rapide.

De plus, je ne dis pas que le web c'est le mal et je reconnais volontier qu'il y a des situations ont où, effectivement, c'est vraiment la meilleure solution. Mais pas TOUTES les situations.

Ce que je critique le plus au final, c'est cette volonté de tout vouloir faire faire aux navigateurs, alors que les OS sont conçus pour ça à l'origine.

[Freem]

Comme tous les évangélistes, il voit sa religion comme la panacée.
Ce mot est excellemment bien choisi...

Les web-app, ça a un intérêt, par exemple les webmails sont vraiment quelque chose de pratique. Mais ils n'ont pas besoin d'accéder au matériel, et les performances sont correctes parce qu'il n'y a que de l'envoi de texte (ou presque, vu qu'il y a aussi quelques images selon le webmail).

Par contre dans le genre super mythe, la portabilité du html se pose.
Au final, en terme de portabilité, en C++ j'utilise très très peu de "#ifdef WIN32" dans mon code, alors qu'a lire les posts sur ce forum, on constate que les dev web sont obligés de recourir à des tests sur le navigateur exécutant le code quasiment tout le temps.
Ok, C++, il faut recompiler (parce que jusqu'a présent, je ne connaît pas de VM pour faire tourner C++) mais alors on peut utiliser java: compiler un coup, exécuter partout, il le fait bien.

Java (que je n'aime pourtant pas trop) à de meilleures perf et a ce que je sais n'impose pas de vérifier que la machine virtuelle à été fournie par tel ou tel fournisseur (parce que le problème de version se pose, naturellement, mais il existe aussi pour HTML5) ...

Pour le coup avec une appli lourde à part faire un process de maj invisible à l'utilisateur (pas forcément top) qui imposera sans doute un redémarrage de l'appli y'a pas de solution.

Pas tout à fait vrai.
On peut faire une maj partielle d'un logiciel sans le redémarrer, si celui-ci est conçu via une architecture de plug-ins (ce qui est très faisable de façon portable, il existe des lib pour ça en fait, y compris pour C ou C++ pourtant très liés à leur système hôte).
Et comme certains disent qu'on peut utiliser HTML5 en hors-ligne, dans cette situation, il est bel et bien nécessaire de redémarrer l'application pour la mise à jour.
Donc, à mettre entre guillemets, ce genre d'assertions.

La problématique des mises à jour automatique ne se pose pas pour linux grâce aux systèmes de dépôts. Bien sûr, tout le monde n'a pas linux, mais comme dis précédemment, avoir un système de mise à jour transparent n'est pas si difficile. (un coup de cron sur un apt-get update / upgrade c'est pas sorcier, et je suis persuadé que des distros le fournissent en standard comme windows avec win update)
Le fait qu'une maj puisse casser les choses n'a rien à voir dans le problème puisque ce souci est aussi présent pour une webapp, et le choix d'une distribution stable l'évite (histoire de citer un nom reconnu pour sa stabilité: debian par exemple).
Certes, linux only pour le moment, mais comme dit précédemment, les autres OS s'y mettent via les "appstore".

Ce qui m'agace avec les navigateurs, c'est que ce sont des logiciels que l'on patche, repatche et surpatche avec de plus en plus de rustine pour leur faire faire ce qui n'est pas leur boulot.
Et selon moi quand on demande à une machine à laver de faire du café, ça ne peut qu'amener à de sacrés problèmes de santé publique!
Mais bon, les entreprises pensent qu'il y a gain de temps ainsi...

Moi, je trouve qu'il existe une autre problématique, c'est celle de la saturation du web.
On peut dire ce que l'on veut, mais une webapp implique de se plier aux caprices de nombreux fournisseurs supplémentaires:
_ FAI qui peut merder
_ réseau téléphonique pouvant être endommagé (par la neige par exemple)
_ fournisseur de l'application qui peut merder une maj
_ fournisseurs des serveurs hébergeant l'application qui peuvent se manger un DDOS, une montée en charge mal gérée ou un matériel qui flanche (un orage est si vite arrivé chez amazon...)
Alors qu'une appli locale, si elle n'a pas besoin d'envoyer des données sur le réseau (comme un jeu ou un logiciel de traitement de texte) n'a que la problématique d'avoir assez de ram et de processeur sur la machine locale.
Préoccupations que la webapp à aussi puisque les navigateurs étant de plus en plus gros, leur occupation des ressources est devenue loin d'être anodine (sans compter les OS et les environnement graphiques).


Conclusion: oui, les webapp, ça peut servir. Mais clairement, un browser ne remplacera pas un OS sur mes machines de sitôt.

[tittoto]

Il y a un autre aspect qui n'est pas étudié : le coût de développement !

Ok, une application native est, à mon sens, mieux qu'une appli HTML 5, mais si vous voulez cibler un max d'users, ça vous coûtera BEAUCOUP plus cher de développer/maintenir une appli spécifique android+iOS+Windows mobile, etc.

Je pense que les applis HTML 5 sont excellentes pour se positionner sur les différentes plateformes en limitant les coûts. Une fois qu'on a plus de moyen, on peut progressivement développer des applis natives.

[Uther]

En ce sens, je ne voit clairement pas où est l'atout car on peux faire strictement la même chose en C/C++, Java, .Net, Python, Delphi, Ruby, etc,

Le seul qui pourrait prétendre à ça est Java car il est le seul qui ait à la fois une plateforme assez complète, soit conçu pour marcher sur différents OS et architectures, sans recompilation et qui soit très activement supporté.
Malheureusement, JavaSE pour mobile commence à peine à montrer le bout de son nez et arrive bien trop tard pour percer sur le marché, d'autant plus qu'il sera automatiquement exclu de certains systèmes fermés comme iOS et Windows Phone.
Je ne parles pas de JavaMe qui a toujours été un Java castré et bourré d'incompatibilités.

Théoriquement .Net pourrait lui aussi y prétendre, mais malheureusement Microsoft ne se préoccupe que du coté Windows laissant a Mono qui a déjà des moyens limités, un statut bâtard.

Je ne vois pas d'atout particulier ici. Les distributions Unix, via leur gestionnaire de paquets, font un boulot parfait pour cela. Et pour les autres systèmes, les Stores tendent maintenant à occuper ce rôle.

Moi je vois au contraire un gros défaut au système des gestionnaires de paquets Linux. La création et la maintenance des milliers de paquets d'une distribution est un travail colossal. Multiplié par le nombre de distributions, ça devient juste titanesque et ça absorbe malheureusement une bien trop grosse partie de la force de travail des distributions, et rend complexe la vie des applications qui n'ont pas les moyens de faire entretenir un paquet pour chaque distribution.
Je dirais même que c'est probablement la principale raison pour laquelle Linux a du mal a se développer dans le grand public.

Sérieusement, je peux comprendre qu'on veuille améliorer les navigateurs, mais de là à en faire des remplaçants d'OS, ça me sidère ! Je préfère télécharger et installer une petite application qui interroge des Web Services que devoir laisser les pleins pouvoirs à un navigateur !

Une application web qui a recours à ce genre de fonctionnalité doit bien évidement être installée via un système comparable à un market et qui présente les mêmes avertissements de sécurité.

Ben comme PhoneGap, grâce à qui on peut développer une appli HTML5 capable d'accéder aux contacts, à la caméra etc.

En effet le but est comparable, la différence est que Mozilla essaye d'éviter autant que possible de reposer sur des technologies non standard.
Le but des WebAPI est de faire standardiser tout, ça par le W3C.

Non. Le véritable problème est que le HTML5 (+ Javascript) veut faire comme du natif alors qu'il n'a pas était conçu pour cela. Dévier une chose de sa fonction primaire permet de découvrir et d'évoluer, mais cela ne marche pas à tous les coups.

Oui et non, c'est vrai que je préférerais une technologie prévue pour au départ, mais il faut avouer qu'on peut faire actuellement presque tout en pur JavaScript.

Java (que je n'aime pourtant pas trop) à de meilleures perf et a ce que je sais n'impose pas de vérifier que la machine virtuelle à été fournie par tel ou tel fournisseur (parce que le problème de version se pose, naturellement, mais il existe aussi pour HTML5) ...

Il m'est arrivé d'avoir des problèmes avec une JVM en particulier, mais il est vrai que c'est très rare, les spécifications de Java étant assez strictes et plutôt bien contrôlées

Pas tout à fait vrai.
On peut faire une maj partielle d'un logiciel sans le redémarrer, si celui-ci est conçu via une architecture de plug-ins (ce qui est très faisable de façon portable, il existe des lib pour ça en fait, y compris pour C ou C++ pourtant très liés à leur système hôte).
Et comme certains disent qu'on peut utiliser HTML5 en hors-ligne, dans cette situation, il est bel et bien nécessaire de redémarrer l'application pour la mise à jour.

C'est en effet plus ou moins faisable en C/C++, mais c'est tellement complexe à mettre en œuvre et ça risque d'entrainer tellement de problèmes, que ça ne se fait quasiment jamais.
Pour le HTML hors ligne, il peut tout à fait se mettre à jour automatiquement dès que la connexion est retrouvée, à mois qu'il ne repose que sur une seule page jamais rafraichie.

Conclusion: oui, les webapp, ça peut servir. Mais clairement, un browser ne remplacera pas un OS sur mes machines de sitôt.

C'est là où je pense qu'il y a une incompréhension. Le principe de la la spécification des WebApps est de pouvoir sortir l'application du contexte du navigateur.
L'avantage d'une webb-apps est de pouvoir être utilisée dans un environnement séparé, qui est en fait un navigateur minimal réduit a un rôle d'une JVM.
La plupart des fonctionnalités avancées ne seront pas disponibles dans un navigateur utilisé normalement.

[cbleas]

Bonjour,
est ce que Microsoft n'est pas en train de résoudre en mettant le HTML5 au centre du développement natif?
NB: Ce n'est qu'une question et non une affirmation. Evitez les Troll

[SylvainPV]

Autant dans un contexte professionnel, cela peut être gênant (dans les petites entreprises surtout), autant pour un particulier, si l'utilisateur ne se met pas à jour, ce n'est pas le problème du développeur. Certes, il manquera des mises à jours/sécurité, mais il n'y aucune solution au "problème humain"

Il n'y a pas de "problème humain". Déclarer l'utilisateur comme fautif est la bonne excuse de nombreux développeurs face aux contraintes des technologies qu'ils utilisent et à leurs propres erreurs (fonctionnelles, ergonomiques, communicatives). Tout comme dire qu'un système non à jour n'est pas du ressort du développeur, c'est se laver les mains bien trop facilement.

Les applications web permettent de mettre à jour l'applicatif aussi facilement que le contenu, de manière automatique et transparente. On n'impose plus à l'utilisateur de devoir gérer des installations, des versions ou des mises à jour, puisque l'application est localisée côté serveur. On a donc un contrôle total sur le déploiement des correctifs et évolutions. C'est donc un grand avantage en faveur des applis web.

[rimram31]

...Déclarer l'utilisateur comme fautif est la bonne excuse de nombreux développeurs face aux contraintes des technologies qu'ils utilisent et à leurs propres erreurs ...

Une parole censée pour ce qui est des mises à jour a distance de logiciels embarqués, il faut avoir connu la réalité du problème de software upgrade pour savoir que c'est loin d'être aussi simple que ça (dépendances version d'OS, d'API, composants additionnels, garantie de retour arrière en cas d'erreur ...) + les problèmes de compatibilité des éventuelles données de l'application stockées localement pouvant laisser le terminal dans un état incohérent. Bref, facile a dire, une toute autre histoire dans la réalité.

Finalement, si on prend du recul, le modèle navigateur + HTML5 reprend les ambitions de HotJava il y a quelques années où le navigateur joue le rôle de VM + sandbox. Souhaitons a la techno plus de succès que Java a l'époque qui n'est pas parvenu a avoir des environnements "compatibles" (version de JVM, API propriétaires genre Nokia ...) même si finalement, il y a eu de relatifs succès (jeux Java par exemple).

Il est évident que cette approche permet de répondre, peut-être pas a tout, mais a une large gamme de besoins qui, ne l'oublions pas, ont pour objectif de fournir un service le plus facile d'utilisation.

[Freem]

Les applications web permettent de mettre à jour l'applicatif aussi facilement que le contenu, de manière automatique et transparente. On n'impose plus à l'utilisateur de devoir gérer des installations, des versions ou des mises à jour, puisque l'application est localisée côté serveur. On a donc un contrôle total sur le déploiement des correctifs et évolutions. C'est donc un grand avantage en faveur des applis web.

D'un autre côté, les entreprises apprécient pour certaines moyennement de ne pas avoir le contrôle sur les outils utilisés. Cette fameuse MaJ automatique et transparente est dont un défaut dans ce cas la, puisqu'une entreprise utilisant, par exemple, google docs, aura besoin d'un déploiement sur un serveur local. Comme une application native, quoi.
Sauf que rien ne garantit que toutes les applications web aient ce potentiel, et du coup le problème des applications maison et leur maintenance se pose réellement avec les outils en html5 et leurs mise à jour transparente.

Pour ce qui est des problèmes de mises à jour qui ne sont pas le problème du développeur... ok, on est plus ou moins tous dans le même bateau, mais il me semble que dans un contexte d'entreprise, ce rôle est attribué à la production?
Reste ensuite, naturellement, le problème des utilisateurs type "loisir" ou en entreprises sans service informatique.
D'un autre côté, dire que ce problème reviens principalement aux développeurs, c'est un peu comme dire que le problème d'entretien d'une tuyauterie ou d'une voiture reviens principalement aux plombiers et garagistes: moi j'appelle ça se décharger des responsabilités sur le dos des autres.
Je sais que les gens "n'ont pas les compétences" pour le faire, mais je n'ai pas les compétences pour entretenir ma voiture / plomberie, et pour autant, il me suffit de demander à un professionnel de s'en occuper.
Et d'ailleurs, dire que "les gens ne savent pas faire" est de plus en plus faux: qui ne connaît personne sachant faire une mise à jour? D'autant plus que de plus en plus de softs se mettent à jour seuls et sans rien demander sous windows si je ne m'abuse. Bon, ok, il faut redémarrer... mais dans ces utilisateurs, je doute que beaucoup fassent des concours de celui qui reboote le moins souvent dans l'années, donc les logiciels finissent de toute façon par être redémarrés.

[notia]

Il y a un autre aspect qui n'est pas étudié : le coût de développement !

Ok, une application native est, à mon sens, mieux qu'une appli HTML 5, mais si vous voulez cibler un max d'users, ça vous coûtera BEAUCOUP plus cher de développer/maintenir une appli spécifique android+iOS+Windows mobile, etc.

Je pense que les applis HTML 5 sont excellentes pour se positionner sur les différentes plateformes en limitant les coûts. Une fois qu'on a plus de moyen, on peut progressivement développer des applis natives.

Entre le natif pur et le tout web, il y a d'autres solutions.
Comme par exemple, utiliser une solution qui générerait un binaire pour tel ou tel plateforme avec le même code source. Approche choisi par xamarin.

D'autre part le gain que tu auras en faisant du HTML, tu le perdras sur 3 choses:
1) le HTML propose une compatibilité/nivellement vers le bas. Tu ne pourras pas proposer une UI équivalente au natif
2) Tu développes une fois mais le code est bien plus compliqué à maintenir à cause de la nature du javascript. Les couts de dev explosent dès que tu veux faire quelque chose d'un peu plus compliqué. Le dev HTML5+ JS est mal outillé.
3) Avec une application, comment proposer quelque chose qui s'intègre à l'identité de la plateforme de l'utilisateur. Surtout quand on voit les divergence entre android, windows et son modern UI, iOS ???

Pour moi le tiercé gagnant, c'est une application native pour l'UI + un webservice.

[rimram31]

Entre le natif pur et le tout web, il y a d'autres solutions...

Le 'nivellement par le bas" comme tu dis ou l'intégration a "l'identité de la plateforme utilisateur", ne sont pas nécessairement de mauvaises, ou bonnes choses. Il peut être souhaitable, pour le succès de ton produit/service, de s'intégrer plus a l'identité du web qu'à celle de ton terminal, nombre d'utilisateurs sont lassés de devoir tout réapprendre à chaque changement de terminal, surtout quand ça n'apporte rien de plus.