Intel mise sur le HTML5 pour le développement multiplateforme

Les rubriques (actu, forums, tutos) de Développez
Réseaux sociaux

 Discussion forum

Retrouvez le dossier complet de la rédaction
28/12 - "Facebook ne sait pas utiliser le HTML5" pour Sencha, qui sort une application HTML5 meilleure que les solutions natives de la société
12/09 - "Notre plus grosse erreur a été de trop miser sur le HTML5" pour le PDG de Facebook : le standard est-il vraiment prêt pour le mobile ?
Sur le même sujet
21/09/2012 - Le HTML 5 sera publié en 2014, le HTML 5.1 en 2016, le W3C sortira une nouvelle norme tous les 2 ans
Le 14/09/2012, par Hinault Romaric, Responsable Actualités
Mise à jour du 14/09/2012

Alors que Facebook a clamé haut et fort son divorce avec le HTML5 (lire ci-devant), un autre géant de l’IT a déclaré son amour pour le langage la même semaine.

Le standard du Web a fait l’objet d’une attention particulière lors de l’événement annuel d’Intel pour les développeurs «Intel Developer Forum » qui s’est déroulé à San Francisco.

Présentant son concept « d’informatique transparente», Renée James, vice-présidente senior d’Intel, lors de sa keynote, n’a pas manqué de vanter les mérites du HTML5 qui représente le socle de la vision de la société qui se résume en « écrire une fois, exécuter partout ».



Bien qu’agacée par les déclarations de Mark Zuckerberg la veille sur le langage, James a reconnu que le HTML5 avait peut-être été surévalué. Mais, il reste actuellement la seule technologie qui permette aux développeurs de cibler plusieurs plateformes tout en réduisant les coûts de développement.

Mettre tous ses œufs dans un seul panier est extrêmement risqué pour les développeurs. Ceux-ci sont obligés de faire un choix dans la large gamme actuelle de systèmes d’exploitation (Windows, Android, iOS, etc.) sans toutefois être sûrs de pouvoir monétiser leurs applications sur une plateforme particulière, remarque James.

L’avantage du HTML5 est qu’il permet de cibler une multitude de plateformes, tout en permettant au développeur de garder la même expérience utilisateur partout. Intel mise donc sur le langage comme un moyen sûr pour l’exécution des applications sur de nombreux dispositifs, y compris les smartphones et les tablettes.

Pour justifier l’importance du HTML5, la société révèle que 40 % des développeurs exploitent déjà le langage et autant désireraient s'y mettre.

Comme la plupart des technologies, le langage a quelques problèmes à ses débuts, admet Intel, qui compte contribuer à son évolution en optimisant la prise en charge de celui-ci sur ses équipements et en publiant avant la fin de l’année des outils de développement pour HTML5 sur le site Web Intel Developer Zone, ainsi que des outils cross-plateformes pour iOS, Android, Windows Phone et iOS.

Source : IDF 2012


 Poster une réponse

Avatar de GATEN GATEN
Membre du Club
le 14/09/2012 17:26
Merci pour la citation exacte Flaburgan. A mon avis, il y a une mauvaise traduction en français qui a été reprise par tous les sites web car Zuckerberg est bien plus nuancé que les articles en français le laisse penser.
Avatar de camus3 camus3
Membre émérite
le 14/09/2012 17:41

Citation:




Comme la plupart des technologies, le langage a quelques problèmes à ses débuts, admet Intel, qui compte contribuer à son évolution en optimisant la prise en charge de celui-ci sur ses équipements et en publiant avant la fin de l’année des outils de développement pour HTML5 sur le site Web Intel Developer Zone, ainsi que des outils cross-plateformes pour iOS, Android, Windows Phone et iOS

.
Quels outils ? ils auraient au moins pu les montrer ces soit-disant outils. Tout le monde les attend , ces soit disant outils ... en fait pas besoin , un simple éditeur de texte suffit.
Avatar de alex_vino alex_vino
Membre Expert
le 14/09/2012 18:26

Citation:





Envoyé par Hinault Romaric
Voir le message

Source : IDF 2012

Serait-il possible d'avoir la source exacte de l'article.
J'ai beau chercher mais ne trouve pas grand chose.
Merci
Avatar de air-dex air-dex
Membre Expert
le 14/09/2012 22:34
Pas étonnant de la part d'une des 2 entreprises derrière l'OS mobile Tizen dont les applications seront développées en HTML5.
Avatar de Malkavia Malkavia
Invité de passage
le 15/09/2012 12:24
Je trouve ça un peu facile d'accuser le html5

Dans mes potes, ceux qui ont arrêté FaceBook l'ont fait pour une raison très simple : la nouvelle Timeline/wall, qui est juste immonde. Leurs mises à jour "design" font rarement l'unanimité. Je préférais Facebook dans ses premieres versions. Il n'y a qu'à regarder le nombre de gens qui ont pesté quand on leur a imposé ça. Et sur Android, j'ai toujours trouvé ça super lent, html5 ou pas
Avatar de alex_vino alex_vino
Membre Expert
le 15/09/2012 13:18

Citation:





Envoyé par Malkavia
Voir le message

Je trouve ça un peu facile d'accuser le html5

Dans mes potes, ceux qui ont arrêté FaceBook l'ont fait pour une raison très simple : la nouvelle Timeline/wall, qui est juste immonde. Leurs mises à jour "design" font rarement l'unanimité. Je préférais Facebook dans ses premieres versions. Il n'y a qu'à regarder le nombre de gens qui ont pesté quand on leur a imposé ça. Et sur Android, j'ai toujours trouvé ça super lent, html5 ou pas



Les gens n'aiment pas le changement.
Tout le monde a détesté l'UI de Windows Vista mais tout le monde adore celle de 7, etc...
Il nous faut du temps pour nous y habituer, mais une fois que les gens s'y sont fait apres un certain temps et qu'ils reviennent a une ancienne version ils veulent tout de suite réutiliser la toute derniere.
Oublie pas que nous francais on est raleur, mais ce n'est pas parce qu'on peste qu'on a raison. S'il y a 100 000 personnes a se plaindre et alors, ce nombre représente quel pourcentage des utilisateurs de Facebook?
Si ca se trouve les 100% - 100 000 utilisateurs utilisaient avec impatience cette Timeline.

Si Facebook doit se plier a tous leurs utilisateurs raleurs ils n'ont pas fini, s'ils ne sont pas content qu'ils aillent chez Google + & Co.

Tu préferais Facebook dans ses premieres versions: Donc pour toi l'esthétique (du moins l'esthétique qui te conviens mieux a toi) est plus important que le respect de la vie privée
Avatar de Uther Uther
Expert Confirmé Sénior
le 17/09/2012 14:27

Citation:





Envoyé par Flaburgan
Voir le message

O_o euh excuse moi mais là tu te plantes complètement, Javascript est interprété, il a donc un interpréteur mais pas de machine virtuelle, à la différence justement du Java que l'on trouve dans Android...

Il faudrait que tu précise tes définitions de VM et interpréteur, parce que pour moi une VM est un interpréteur.


Citation:





Envoyé par Flaburgan
Voir le message

Oui et non. Tout dépend de l'interpréteur, mais en règle générale, une VM a de moins bonnes performances, car même si le langage est compilé en partie, tout l'environnement VM est très lourd (pense au garbage collector et tout ça...).

La aussi je voudrait bien des explications sur en quoi c'est meilleur, parce qu'un l’interpréteur Javascript à les même besoins qu'une VM classique (Garbage collector, API, ...).


Citation:





Envoyé par Freem
Voir le message

C'est certes totalement hors-sujet, mais ce n'est pas parce que JAVA est le modèle habituel des langages fonctionnant sur une VM et qu'il utilise effectivement des GC que tout langage utilisant une VM doit utiliser un GC.

Dans le cas qui nous interesse à savoir Javascript, il faut aussi un Garbage Collector donc c'est un très bon point de comparaison.


Citation:





Envoyé par Freem
Voir le message

Mais comme tu dis, il faudrait des benchmark. Le souci de ces trucs étant que les fanatiques du langage qui perd diront que le bench n'est pas équitable car les optimisations du code ont pas coûté le même temps, ou que le bench est pourri de par son concept



Techniquement je ne vois pas comment le Javascript pourrait entrer en compétition avec le Java en terme de performance brutes, il souffre de plusieurs défauts, qui sont intrinsèques à sa nature :
- Java est fortement typé ce qui permet des optimisation qui sont complexes et couteuses en temps de compilation voire parfois impossibles en Javascript.
- Java est compilé en bytecode en amont, alors que javascript doit le faire à la volée
Avatar de Freem Freem
Expert Confirmé
le 17/09/2012 16:32

Citation:





Envoyé par Uther
Voir le message

Il faudrait que tu précise tes définitions de VM et interpréteur, parce que pour moi une VM est un interpréteur.

Un interpréteur reçoit du code source, le compile et l'exécute.
Une VM reçoit un binaire destiné à une machine qui n'existe pas, traduit ce code pour la machine réelle, qui va l'exécuter.

Je t'accorde que la nuance est fine, cela dis, dans le cas de la VM, il y a la possibilité d'effectuer des optimisations très coûteuses en temps sans que la première exécution depuis le dernier démarrage de la machine virtuelle ne s'en ressente (quoiqu'il y ait aussi des optimisations faites à la 1ère exécution, ce me semble).
Hors, l'interpréteur, lui, doit procéder directement à la compilation. S'il cherche a atteindre les performance d'un binaire compilé puis traduit, cela implique des optimisations qui peuvent avoir un fort coût au lancement (l'optimisation, on sens pas mal son coût à la compilation d'un programme C++. Je doute que ça ne soit pas le cas sur un langage de VM...).

Dans les deux cas, si le logiciel sous-jacent est correctement conçu, ce coût n'aura lieu qu'une fois, mais JS étant plutôt utilisé pour des choses dont on veut une exécution immédiate, je doute très fortement que des optimisations non triviales soient effectuées avant l'exécution: ce serait contre productif.

Voila pourquoi je doute extrêmement fortement qu'un langage interprété puisse offrir de meilleures performances qu'un langage basé sur une VM, tout comme il est extrêmement peu probable qu'un langage basé sur une VM soit plus rapide qu'un langage natif.
A mon humble avis, naturellement.
Avatar de supergeoffrey supergeoffrey
Membre actif
le 17/09/2012 16:38
Pour revenir au sujet, je ne pense pas que seul les mauvais choix technologiques, soit la seule raison pour laquelle, l'action en bourse de facebook en bourse a perdu la moitié de sa valeur.

Je pense qu'elle est plutôt dû à la surestimation monétaire de facebook à 30 Milliards de dollars au lieu de 15!

Cette annonce de Mark Zuckerberg est simplement une mascarade afin de cacher la vérité aux investisseurs qui lui ont racheté 72% des actions de l'entreprise au double de leur prix réel.
Avatar de Uther Uther
Expert Confirmé Sénior
le 17/09/2012 23:16

Citation:





Envoyé par Freem


Un interpréteur reçoit du code source, le compile et l'exécute.

A l'origine la notion d'interpréteur est complètement opposée à la notion de compilation en langage machine. L'interpréteur est censé être un programme qui déroule entièrement l’exécution du programme.
Les premières JVM étaient d'ailleurs de pur interpréteurs, et il existe encore dans les JVM modernes une option pour les forcer a fonctionner ainsi.

Citation:





Envoyé par Freem


Une VM reçoit un binaire destiné à une machine qui n'existe pas, traduit ce code pour la machine réelle, qui va l'exécuter.

La notion de représentation intermédiaire, ce n'est pas un concept nouveau qui est apparu avec la JVM. La plupart des interpréteurs ont recours depuis bien longtemps des formes intermédiaires, comme par exemple la "tokenisation", pour améliorer les performances.

Bref je pense que vouloir séparer les notions de "VM" et 'd'interpréteur" est à éviter car elles se recoupent complètement dans le contexte d'aujourd'hui.

On peut difficilement dire que le Javascript d'un navigateur est seulement interprété. Les moteurs JavaScript modernes tels que V8, IonMokey ou Nitro ont tout d'une JVM. Le Javascript est transformé en bytecode interne et l’interpréteur a recours à la compilation JIT en natif.
Inversement la JVM java a un fonctionnement hybride. Certaines parties du bytecode sont interprétés alors que d'autres sont compilés en fonction des besoins.
Avatar de unBonGars unBonGars
Membre éprouvé
le 20/09/2012 8:15
Bizarre que cela fasse débat : HTML5 est effectivement en bas de la liste des perfs. Tout en haut , on trouve ASM et C, non seulement ils sont compilés et proches de la machine mais aussi statiques (link) ce qui leur permet d'optimiser le mode d'adressage.
En outre l'organisation de la mémoire (code et data) est accessible ce qui autorise les traitements d'ensemble et les pointeurs natifs accélèrent drastiquement certains traitements. D'un autre coté , on hérite de bugs plus contrariants et d'un temps de dev plus long..

A l'autre bout de la liste, on trouve javascript, ses variables typées à l'utilisation, sa garbage collection, sa compilation tardive, ses IO dans le DOM HTML, ses contraintes de compatibilité entre navigateurs..

J'en oublie surement, HTML javascript ne sera jamais au niveau d'un java ou .net, qui eux même ne pourront jamais rivaliser avec les statiques ASM C Pascal...

Par contre , on gagne effectivement sur l'indépendance à la plateforme : les multiples indirections qu'on impose au code avant d'être converti en exécutable permettent quand même de l'adapter sur la machine hôte. C'est un vieux débat et un dilemme de toujours pour les développeurs.

Pour ce qui est du cas Facebook, il est quand même possible que les ratés du HTML5 tout neuf et pas vraiment mature aient pu lui causer un grand tord dans l'année écoulée, question de timing, HTML5 sera bien plus robuste dans quelques années.

Mais si on le compare à Objective-C ou Java-droid, la cause est entendue, les languages natifs sont définitivement plus fluides et moins consommateurs de ressource.

Je sais qu'il y a toujours de grands défenseurs des solutions hyper-évoluées comme Javascript , je respecte ça mais le vieux C est toujours le langage le plus employé au monde , ça aussi , c'est respectable
Objectivement , on ne pourra jamais faire en javascript ce qu'on fait dans un IDE complexe de dev natif, cela va bien plus loin que la seule vitesse d'execution. L'accès direct aux librairies de l'OS a aussi une grande importance
Avatar de Hinault Romaric Hinault Romaric
Responsable Actualités
le 28/12/2012 11:40
Facebook ne sait pas comment utiliser le HTML5 pour Sencha
qui sort une application HTML5 meilleure que les solutions natives de la société

Fastbook : la réponse de Sencha, un fournisseur des outils et applications Web open source à Facebook, qui trouve le HTML5 pas encore mature.




Pour rappel, le réseau social avait abandonné ses applications HTML5 pour mobile pour s’orienter vers le développement natif à cause des piètres performances et de la lenteur de celles-ci sur les dispositifs des utilisateurs.

Mark Zuckerberg, le patron de la société, avait même déclaré que leur plus grosse erreur a été de trop miser sur le HTML5 par rapport au natif (confer section « Retrouvez le dossier complet de la rédaction » ci-dessous).

Cependant, les mauvaises performances des applications HTML5 Facebook seraient plus à imputer à la société qu’au langage, selon Sencha.

« Quand une équipe à des problèmes avec le HTML5, ils proviennent généralement du fait qu’elle adopte une approche de développement site web, et n’utilise pas souvent les bons outils et les architectures de développement », écrit Sencha dans un billet de blog. « C’est ce que nous soupçonnions à propos de l’application HTML5 Facebook. La façon dont cette application s’exécute, la lenteur du chargement, l’expérience utilisateur, sont les symptômes habituels. »

Alliant la parole à l’acte, Sencha a publié Fastbook, sa propre application Facebook qui repose entièrement sur le HTML5. Les résultats comme on peut le voir dans cette vidéo de comparaison avec les solutions natives de Facebook, sont assez impressionnants.



Tester fastbook (il est recommandé d'utiliser un smartphone moderne)

Source : Blog Sencha

Et vous ?

Qu'en pensez-vous ?
Avatar de CapFlow CapFlow
Membre régulier
le 28/12/2012 12:14
Qu'en pensez-vous ?

J'en pense que Facebook s'est pris une grande rouste

Blagues à part, je trouve que c'est une très belle performance de Sencha.
Avatar de camus3 camus3
Membre émérite
le 28/12/2012 12:33

Citation:




Tester fastbook (il est recommandé d'utiliser un smartphone moderne)

Bah oui, parce que sinon le résultat est pourri vu les mauvaises perfs de html+js sur mobile...
Avatar de stailer stailer
Membre Expert
le 28/12/2012 12:41

Citation:




Blagues à part, je trouve que c'est une très belle performance de Sencha.

C'est vrai, néanmoins j'émettrai un petit bémol : après de nombreux tests avec Sencha 2.0 j'ai pu constater une énorme différence entre IOS et Android.
Sur Android j'ai eu de nombreux problèmes de lags sur les animétions et c'était nettement plus lent... Le problème semble résolu (mais pas complétement surtout quand l'appli contient des graphes) depuis la 2.1.

Ce qui veut dire, qu'il y a tout juste 1 mois le résultat aurait été nettement différent. Voir pas montrable sur Android.
Avatar de Grabeuh Grabeuh
Membre éclairé
le 28/12/2012 13:00
Ils devraient quand même préciser que ça ne marche QUE sur des navigateurs Webkit, et à la rigueur IE si on fait fi des bugs graphiques nombreux...
Avatar de kdmbella kdmbella
Expert Confirmé
le 28/12/2012 13:17
Il est évident que la qualité d'une application ne dépend pas seulement de la technologie utilisée, mais de comment elle est utilisée : architecture, qualité de développement, choix technique ... Donc lorsque Facebook déclare que le HTML5 est la cause de son échec dans le développement des applications indiquées, c'est sous réserve du fait qu'il a effectivement la maîtrise de la technologie utilisée hors Sencha vient de montrer que cette maîtrise Facebook ne l'a pas au vu de cette démonstration. Alors un training de Sencha pour les développeurs de Facebook sur la technologie HTML 5 ne serait pas une mauvaise chose
Avatar de kolodz kolodz
Membre Expert
le 28/12/2012 13:29
J'ai testé avec Firefox sur le Galaxie S2 :
Ca fonctionne pas !
Par contre... Avec l’application "Internet" de base, les performances sont au rendez-vous.
J'avais un doute à un moment sur ma connexion internet, car je trouvais l’application facebook très très longue à charger. Maintenant, je sais que c'est juste l'application !

La vraie question que je me pose, c'est :
Application native mal codé ou fait d'autres trucs en plus ?
Avatar de Tryph Tryph
Membre chevronné
le 28/12/2012 13:50
perso je trouve assez balaise que Sencha arrive à faire une application en HTML5 qui soit aussi réactive (voire plus) qu'une application native...

et je trouve ça plutôt embarrassant pour Facebook.

alors après, l'application de Sencha ne tourne peut être pas sur tous les navigateurs et n'est donc sans doute pas tout à fait mature, mais je doute pas que ça puisse être corrigé.
Avatar de stailer stailer
Membre Expert
le 28/12/2012 14:50

Citation:




J'ai testé avec Firefox sur le Galaxie S2 :
Ca fonctionne pas !

Normal, comme dit plus haut ça fonctionne uniquement avec des navigateurs à base de Webkit.
Avatar de Grabeuh Grabeuh
Membre éclairé
le 28/12/2012 15:01

Citation:





Envoyé par stailer
Voir le message

Normal, comme dit plus haut ça fonctionne uniquement avec des navigateurs à base de Webkit.

Ca fonctionne à peu près sur IE10, mais de nombreux bugs graphiques son quand même présents, sans pour autant empêcher d'utiliser l'application (animations qui laissent des trainées, icones mal placés, etc...)

Donc les WP7 c'est mort, les WP8 devraient arriver à faire tourner l'engin.
Avatar de stailer stailer
Membre Expert
le 28/12/2012 15:31
Ok, je viens de tester sur mon IE10 Desktop et en effet ça marche.

Ce qui renforce un peu ce que je disais plus haut : ils ont clairement "bataillé" à développer cette application pour casser Facebook car ce n'est pas du tout représentatif de leur framework (Sencha Touch)

La preuve en est, les exemples : http://dev.sencha.com/deploy/touch/examples/

Rien ne fonctionne sur un navigateur qui n'est pas webkit, c'est une catastrophe...
Avatar de ValCapri ValCapri
Membre du Club
le 28/12/2012 17:00
Oui, HTML5 est peut-être plus rapide que ce FaceBook pensait. Mais, il ne faut pas oublier que Fastbook est certainement basé sur la dernière version du trunk de Sencha touch et qu'il s'agit ici d'un projet marketing pour montrer leur Framework et casser Facebook par la même occasions.
Comme dit plus haut, ce framework vient d'être optimisé avec la version 2.1

Cette vidéo a été faite sur des iPhone 4S, on ne connait pas la version de Facebook utilisée, ni la version d'iOS utilisé. Car Facebook vient de seulement rendre disponible sa version Java Android de son App et vient de publier sur l'App Store une mise à jour qui contient des optimisations notamment sur la timeline.

Ici, l'équipe de Sencha semble utiliser le cache HTML5 tandis qu'on ne sait pas si Facebook met en cache ses données. Je suis persuadé qu'Apple pourrait faire eux aussi, une app' Facebook bien plus rapide que l'actuel si il le voulait.

Je doute toujours de l'HTML5 sur Mobile pour l'instant. Le JS ne pourra prétendre à être plus rapide qu'un code natif. Et le code once, run anywhere n'est pas vérifié non plus.

Pour moi l'HTML5 doit venir en plus des applications natives créé (WebApp , Objective-C/Cocoa iOS, Java/Dalvik Android et C#/.Net Windows (Phone) 8). Certes cela a coût, mais on touche presque tout le monde.
Avatar de Freem Freem
Expert Confirmé
le 28/12/2012 17:18

Citation:





Envoyé par kolodz
Voir le message

La vraie question que je me pose, c'est :
Application native mal codé ou fait d'autres trucs en plus ?

Réponse: application native mal codée.
Je sais pas si elle en fait plus, mais il suffit de voir un simple détail pour comprendre pourquoi l'appli sencha est plus rapide, et ils le disent dans la vidéo: ils gardent en cache les données, ce qui évite de les recharger pour rien. Moins de bande passante consommée aussi, d'ailleurs, je pense que les utilisateurs de 3G apprécient ce genre de "détails".

Après, je n'ai pas testé ces applications et ça ne risque pas d'arriver, puisque je n'ai ni smartphone, ni compte facebook
Je me base donc entièrement sur les commentaires et la vidéo...

A noter que quand ils sortent que "html5 marche" et quand les gens disent que ça ne marche que sur les navigateurs basés sur webkit et IE10, on se dit qu'il ya p'tet comme un souci. A la rigueur, ça marcherait pas pour opera, mais serait ok pour firefox, je dirais, bon, opera est à la bourre sur certains points et il est "normal" de pas s'emmerder pour 2% de PdM, mais firefox c'est plutôt 25%-30%, non? Soit un utilisateur du web sur 3...

Pour une techno censée être portable, ça la fout mal, moi je dis.
Avatar de chiv chiv
Rédacteur
le 28/12/2012 19:20
C'est un peu des rigolos.

Sur le chargement des données et la manière d'afficher les commentaires, je veux bien que leur travail ait des performances meilleures que l'application Facebook mais ils passent la moitié de la vidéo à montrer des fonctionnalités qui n'ont rien à voir avec le développement web. Toutes les manipulations d'images avec les différents gestes (zoomer etc…) c'est les fonctionnalités standards de l'UIScrollView qui embarque la page web. Pour le changement d'orientation à la fin pareil c'est du standard iPhone c'est pas la page web qui le gère.

De plus ils montrent les fonctionnalités principales de facebook et qu'ils ont développés mais il y a fort à parier que leur application est très loin d'implémenter les très nombreuses fonctionnalités de facebook moins utilisées. Forcément moins de fonctionnalités, moins de code qui tourne, moins de choses en mémoire… plus facile d'avoir de bonnes performances dans ces conditions.
 Poster une réponse  Retrouvez la suite de la discussion

 
 
Developpez.com

Nous contacter

Participez

Informations légales

 
Services

Forum d'entraide

Blogs

Hébergement

 
Partenaires

Hébergement Web