Discussion :

[sekaijin]

Encore une fois, ça n’a pas de sens.

Les perfs d’une appli se mesurent à l’usage.
Et il est bien rare que le ralentissement soit dû à la génération de l’affichage.
Le plus souvent c’est le traitement, la recherche de donnée ou la communication qui sont les plus chronophages.

il existe bien évidemment des cas où l’affichage est complexe à réaliser et là effectivement une routine dédiée sera toujours beaucoup plus performante que du HTML

Mais il ne s’agit ici pas de ça. facedebouc affiche 4 textes et images qui se battent en duel ce n’est pas ça qui bouffe les perfs même en HTML
Même la plus naze des VM fait ça avec des perfs acceptables.

alors si les perfs obtenues par facedebook avec HTML 5 sont mauvaises il y a fort à parier qu’ils n’ont pas utilisé la techno pour ce qu’elle fait très bien
Afficher 4 textes et images.

Dans une appli comme celle-là je dirais que plus de 80% du temps de réaction est hors du HTML/JS soit donc dans la com et le traitement côté serveur.

Pour afficher un texte formaté en natif ou en HTML ne prends que quelques cycles d’horloge même si la différence entre les deux se compte en milliers de cycles à 3 GHz c’est pinuts.

Franchement si la diff de perf et telle que facedebouc le dit, il faut qu’ils virrent tous leurs ingénieurs.

Pour moi c’est un groupe d’ingénieurs qui maitrise une techno et pas l’autre et qui donc à juste titre choisissent celle qu’ils connaissent. ça n’a rien à voir avec les perfs d’une techno ou d’une autre

A+JYT

[kolodz]

Franchement si la diff de perf et telle que facedebouc le dit, il faut qu’ils virrent tous leurs ingénieurs.

Pour moi c’est un groupe d’ingénieurs qui maitrise une techno et pas l’autre et qui donc à juste titre choisissent celle qu’ils connaissent. ça n’a rien à voir avec les perfs d’une techno ou d’une autre

Quand on voit les performances de l'application native... (Qui est logiquement plus rapide que le prototype de Facebook en HTML5.) Par rapport aux résultats de la démonstration.
Je me demande si les ingénieurs de Facebook maitrisent l'une de ces technologies.

Cordialement,
Patrick Kolodziejczyk.

[sekaijin]

Je viens de relire un peu tout ce qui c'est dit et je ne comprends pas en quoi un développement web serrait plus difficile à maintenir qu'un autre.

Quand je lis "en Natif lorsque tu as fait une fonction et que tu l'as testé c'est une fois pour toute lorsqu’en appli HTML ..."

Heu excusez moi je suis peut être naïf, mais les tests ce n'est pas que pour le Natif. La non-régression, ça existe dans toute maintenance.

Que celui qui n'a jamais eu à subir un changement d'API dans un système quelconque me jette la pierre.

Là franchement j'ai besoin d'explication, car en plus de 30 ans de carrière je n'ai jamais vu une seule techno qui change quoi que ce soit à la maintenabilité.

Ça seule chose qui change quelque chose à la maintenabilité d'un dev c'est ce point ait été pensé dès la conception sans ça c'est le foutoir.

A+JYT

[camus3]

Les perfs d’une appli se mesurent à l’usage.

Les perfs d'une appli se mesurent de différentes façon ,si il a un retard de 500 ms entre le moment ou on touche un écran, et l'apparition d'un menu, l'utilisateur ne va pas ressentir que le programme est très réactif.

Et il est bien rare que le ralentissement soit dû à la génération de l’affichage.

si tu as une page web avec 100 images , combien même elles seraient hébergée en local il y aura bien une incidence sur la vitesse d'affichage.

Le plus souvent c’est le traitement, la recherche de donnée ou la communication qui sont les plus chronophages.

On est d'accord il semblerait que l'app facebook n'utilisait pas ou peu de techniques de cache des données, et en plus tirait ses données de fragments html et pas d'une source de données "épurée" comme xml ou json

Mais il ne s’agit ici pas de ça. facedebouc affiche 4 textes et images qui se battent en duel ce n’est pas ça qui bouffe les perfs même en HTML
Même la plus naze des VM fait ça avec des perfs acceptables.

On est sur mobile pas sur desktop avec 8 coeurs 2.5ghz , un proc graphique dédié et 16 gigs de mémoire. une web app avec des perfs moyennes est loin d'être acceptable.
Mon point de vue est qu'il est plus facile d'optimiser une app native qu'une web app , dont on ne contrôle pas grand chose niveau usage de mémoire). Et javascript n'arrange rien( pas de support des constantes, des tableaux typés , etc ... sur la plupart des navigateurs mobiles déployés actuellement )

[raimbow]

Mouais, c'est un peu cheaté leur truc à mon avis...

La plupart du temps la différence de performance se voit sur les changements de fenêtre. Sauf que les deux applications utilisent des transitions, donc il suffit de régler le délais des transitions pour qu'il soit plus court et ça donnera une impression de rapidité alors que ça n'a pas grand chose à voir.

Je soupçonne en faite la version HTML5 d'avoir un système de cache important et de précharger pas mal de donnée. Pour le cache c'est certainement une bonne idée dans tous les cas, pour le préchargement de donnée c'est très discutable (ça bouffe des ressources côtés FB mais surtout ça consomme de la BP, ce qui peut être très pénible en 3G)

[sekaijin]

je trouve toujours très étonant que lorsque une techno réputé lente fait une demo de rapidité on la soupçone de tricher.

et si simplment aujourd'hui les machines virtuelles avaient fait suffisememnt de progrès pour utiliser au mieux les ressources ?

je maintiens dans une app type facebook l'affichage c'est au plus 10% du temps
alors si on est à 10,01 ou à 9,98 l'oeil humain ne voit de différence.

A+JYT