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 2012-11-02 11:29:21, par Hinault Romaric, Responsable .NET
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 ?
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 ?
-
LutarezMembre chevronnéla possibilité d’écrire une fois et déployer partout
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ésune communauté de millions de développeursl’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.
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 !le 02/11/2012 à 12:10 -
FreemMembre émériteComme 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.
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.le 02/11/2012 à 15:03 -
LutarezMembre chevronné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.le 02/11/2012 à 14:01 -
VoyvodeMembre émériteC'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é.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.
L'analyse de Heilmann ressemble surtout à de l'auto-persuasion dans la désillusion générale.le 02/11/2012 à 13:58 -
stailerMembre chevronné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.
Voir l'API ici :http://docs.phonegap.com/en/2.2.0/index.html
Pour IOS,Android, Blackberry et Windows 8le 02/11/2012 à 12:29 -
UtherExpert éminent sénior
Envoyé par Lutarez
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.Envoyé par Lutarez
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.Envoyé par Lutarez
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.
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.
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
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.
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.le 03/11/2012 à 11:36 -
rimram31Membre avertiUne 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.le 05/11/2012 à 9:03 -
FreemMembre émériteD'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.le 05/11/2012 à 9:25 -
notiaMembre confirmé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.le 05/11/2012 à 15:17 -
rimram31Membre avertiLe '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.le 06/11/2012 à 11:47