[Autre] « Notre plus grosse erreur a été de trop miser sur le HTML5 », pour le PDG de Facebook

[Malkavia]

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

[alex_vino]

Envoyé par Malkavia

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

[Uther]

Envoyé par Flaburgan

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.

Envoyé par Flaburgan

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, ...).

Envoyé par Freem

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.

Envoyé par Freem

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

[Freem]

Envoyé par Uther

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.

[supergeoffrey]

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.

[Uther]

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.

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.

[unBonGars]

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

[Hinault Romaric]

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.

Fastbook

Fastbook

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


Source : Blog Sencha


Et vous ?

Qu'en pensez-vous ?

[CapFlow]

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.

[camus3]

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...

[stailer]

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.

[Grabeuh]

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...

[kdmbella]

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

[kolodz]

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 ?

[Tryph]

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é.

[stailer]

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.

[Grabeuh]

Envoyé par stailer

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.

[stailer]

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...

[ValCapri]

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.

[Freem]

Envoyé par kolodz

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.