Facebook passera également au code natif pour l'application Android

Facebook passera également au code natif pour l’application Android

Le HTML5 était une « erreur » pour Mark Zuckerberg

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

12/09/2012 3 minutes
69

Facebook passera également au code natif pour l'application Android

Mark Zuckerberg, fondateur bien connu de Facebook, s’est exprimé récemment au sujet de la puissance montante des smartphones. Il est intervenu en particulier sur la dernière révision de l’application Facebook pour iOS, en affirmant que le HTML5 était une erreur et que la mouture Android bénéficierait du même traitement.

facebook androidfacebook android

« Nous avons gâché deux ans »

Une erreur : c’est ainsi que Zuckerberg a qualifié l’emploi du HTML5 pour créer les applications mobiles de Facebook. Et pourtant, c’est ce même HTML5 qui a permis de créer rapidement plusieurs moutures puisque le code composant le cœur de l’application ne changeait que très peu.

 

Mais pourquoi une telle différence entre le HTML5 et le natif ? Le HTML5 est un langage interprété. Cela signifie qu’avant que les opérations soient passées à la moulinette du processeur, le langage est d’abord traduit dans une forme exploitable. Dans le cas du HTML5, c’est le moteur de rendu qui se charge de sa lecture puis de son interprétation. Dans le cas du natif, cette étape est supprimée : le code est directement exécuté et la différence de performances est visible. On se rappelle d’ailleurs que Mozilla avait fini par abandonner son langage XUL pour Firefox sur Android, à cause là encore d’un souci de performances.

 

Conséquence à venir : l’abandon progressif du HTML5 pour l’ensemble des applications Facebook. Le fondateur de la firme l’a clairement indiqué : « La plus grande erreur que nous ayons faite en tant que société a été de trop parier sur le HTML5 en lieu et place du natif. Nous avons gâché deux ans » avant d’enchainer sur une confirmation : « c’est pourquoi nous avons décidé de passer au natif pour Android et iOS il y a deux mois ».

 

Attention toutefois à ne pas généraliser : les critiques de Zuckerberg concernent uniquement les applications. Les versions web du site, en particulier mobiles, continueront à utiliser le HTML5 qui garde toute la confiance de l'entreprise.

 

 

La version Android bénéficiera du même traitement

Ici, il est important de signaler que cela fait maintenant plusieurs mois que les employés de Facebook sont plus qu’encouragés à migrer leurs smartphones vers des modèles Android. La raison est simple : la direction de l’entreprise a jugé l’application tellement mauvaise sur cette plateforme que le seul moyen efficace d’obtenir des retours concrets est de forcer ses propres employés à goûter leur création quotidiennement.

 

Comme nous l’indiquions dans une précédente actualité, Facebook ne compte donc pas lancer un smartphone maison mais souhaite exploiter au mieux les plateformes existantes. Cela signifie évidemment davantage de travail pour les développeurs : dans la plupart des cas, le code ne pourra tout simplement pas être réutilisé. Ainsi, sous iOS, l’application est rédigée en Objective-C alors que sous Android, il s’agira de C++.

 

Les utilisateurs de smartphones Android pourront se rassurer : le même traitement arrive pour leur plateforme, avec des performances bien meilleurs à la clé. Cela étant, Zuckerberg n’a donné aucune indication sur la sortie de cette nouvelle version. En outre, pas d’informations non plus sur les autres plateformes telles que Windows Phone. Toutefois, les mois à venir pourraient être riches en annonces et sorties, Zuckerberg ayant indiqué que « la première moitié de l’année a été un peu lente en produits, mais pour les six prochains mois je m’attends à de nombreuses choses très sympas ».

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

facebook androidfacebook android

Fermer

Commentaires (69)


sérieux ils en ont mis du temps…



Pour avoir dev en natif et en HTML5 (PhoneGap) pour mobile… la différence de perf est vriament flagrante


Le problème n’est vraiment pas le HTML5, les performances des navigateurs et les performances des mobiles qui suffisent largement aux fonctionnalités offertes par l’application facebook.



Le problème c’est la manière dont ils ont conçu leur application et les problématiques liées au webview…




La plus grande erreur que nous ayons faite en tant que société a été de trop parier sur le HTML5





La plus grande ? tu es bien sûr ? non parce que moi je dirais peut être la deuxième plus grande, au mieux <img data-src=" /><img data-src=" />








Aponhcet a écrit :



sérieux ils en ont mis du temps…



Pour avoir dev en natif et en HTML5 (PhoneGap) pour mobile… la différence de perf est vriament flagrante





Le nombre de questions sur stackoverflow portant sur PhoneGap me fait peur.

Ok si tu veux faire une app la moins chère possible pour le plus de plateformes possibles & que la qualité n’est donc pas ton objectif (par exemple si elle va juste être utilisée en interne), Phonegap est adapté (même si je conseillerai de considérer carrément une vraie webapp tant qu’à faire…).

Pour une app sérieuse, le html5 c’est à jeter aux ordure, point.



J’aimerais plus de précision s’il vous plait. Je me dirige droit vers le développement javascript pour activement contribuer au Mozilla OS (applications et portage). Est-ce que Mozilla aurait parié sur le mauvais filon ?



De plus, quel est le rapport entre l’HTML5 et la bourse ?


ça me surprend toujours de voir que malgré la puissance dont disposent nos appareils actuels, une appli web “rame” autant, en tout cas qu’il y ait autant de différences avec une appli en langage natif. J’ai bien compris ce qu’était un langage interprété, mais ça ne reste après tout “que” du web.


Donc l’époque du “HTML5 permettra de se passer de devoir coder une appli par plateforme” est révolue?




Cela signifie évidemment davantage de travail pour les développeurs : dans la plupart des cas, le code ne pourra tout simplement pas être réutilisé. Ainsi, sous iOS, l’application est rédigée en Objective-C alors que sous Android, il s’agira de C++.



Faudrait arrêter de citer C++ à tout-va quand on parle juste de code natif. Sous Android le natif c’est du java et la version android de firefox est bien codée en java -&gt;https://wiki.mozilla.org/Fennec/NativeUI/CodingStyle et pas en c++ comme indiqué dans la news précédente.



Je sais que l’auteur n’aime pas trop Java mais ça ne doit pas empêcher d’être précis pointu carré <img data-src=" />








L3G0 a écrit :



Donc l’époque du “HTML5 permettra de se passer de devoir coder une appli par plateforme” est révolue?





Si ça pouvait permettre de faire en sorte que le développement web, à tord et à travers, pour tout et n’importe quoi, meurt, je suis preneur … ces technos sont des plaies franchement …



L’internet n’était pas prévu pour être ce qu’il est aujourd’hui et ça ce ressent dans les technologies web, qui sont plein de rustine dans tout les sens …



Internet ça aurait du être des applies natives connectées, ce qui ce fait de plus en plus maintenant, cela n’aurait jamais du être la pour remplacer des applies bureau entière …



Donc franchement si la tendance pouvait s’inversée même sur desktop, moi je vote pour <img data-src=" />









satandierbis a écrit :



Faudrait arrêter de citer C++ à tout-va quand on parle juste de code natif. Sous Android le natif c’est du java et la version android de firefox est bien codée en java -&gt;https://wiki.mozilla.org/Fennec/NativeUI/CodingStyle et pas en c++ comme indiqué dans la news précédente.



Je sais que l’auteur n’aime pas trop Java mais ça ne doit pas empêcher d’être précis pointu carré <img data-src=" />





Sûrement une connerie, mais je suppose que personne ne s’est mis d’accords sur un langage natif utilisable sur toutes les plateformes ?









satandierbis a écrit :



Faudrait arrêter de citer C++ à tout-va quand on parle juste de code natif. Sous Android le natif c’est du java et la version android de firefox est bien codée en java -&gt;https://wiki.mozilla.org/Fennec/NativeUI/CodingStyle et pas en c++ comme indiqué dans la news précédente.



Je sais que l’auteur n’aime pas trop Java mais ça ne doit pas empêcher d’être précis pointu carré <img data-src=" />





ne serait-ce pas l’UI qui est en java, tandis que le coeur de l’appli est en C++ ??









FrenchPig a écrit :



Sûrement une connerie, mais je suppose que personne ne s’est mis d’accords sur un langage natif utilisable sur toutes les plateformes ?





T’as déjà vu Google et Apple d’accord sur un truc ? ^^ Ils arrivent pas à être d’accord sur le format des vidéos à intégrer dans html5 alors le code natif…









FrenchPig a écrit :



Sûrement une connerie, mais je suppose que personne ne s’est mis d’accords sur un langage natif utilisable sur toutes les plateformes ?





Ben non, pourquoi faire du standard quand tu peux verouiller ta plateforme ?? <img data-src=" />









Lafisk a écrit :



Si ça pouvait permettre de faire en sorte que le développement web, à tord et à travers, pour tout et n’importe quoi, meurt, je suis preneur … ces technos sont des plaies franchement …



L’internet n’était pas prévu pour être ce qu’il est aujourd’hui et ça ce ressent dans les technologies web, qui sont plein de rustine dans tout les sens …



Internet ça aurait du être des applies natives connectées, ce qui ce fait de plus en plus maintenant, cela n’aurait jamais du être la pour remplacer des applies bureau entière …



Donc franchement si la tendance pouvait s’inversée même sur desktop, moi je vote pour <img data-src=" />







C’était une vraie question innocente de novice. Parce qu’à un moment HTML5 c’était la panacée (surtout quand ça permettait de taper sur flash) mais on en revient un peu ?



Ce qui m’étonne c’est qu’une boite ayant les ressources de facebook n’ai pas plusieurs équipes travaillant sur des approches différentes de leurs softs. Précisons que l’app facebook ne relève pas du grand art de la programmation et que perdre deux ans là dessus est représentatif de l’incompétence de certaines personnes responsables du développement et par extension de l’équipe dirigeante de cette société.








L3G0 a écrit :



C’était une vraie question innocente de novice. Parce qu’à un moment HTML5 c’était la panacée (surtout quand ça permettait de taper sur flash) mais on en revient un peu ?





ben l’html5 c’est pas encore complètement standardisé etc… donc avant de réellement le voir en marche etc… y va se passer quelques années, vu la lenteur du W3C à faire quoique ce soit.



Après l’HTML5 doit effectivement permettre de ne pas être dépendant de la plateforme etc… mais pour moi, dèv web à contre coeur, c’est pas le flash qui pose le plus de problème, bien qu’il y ai des problème de ressource avec flash, le problème, c’est qu’internet à la base c’est un système de présentation d’information formatée, donc desp ages statiques avec 3 pauvre truc pour t’indiquer la couleur, la font etc…



mais ça a tellement bien fonctionner qu’ils ont tous voulu aller plus loin, dans des périmètres qui n’étaient absolument pas ceux pour lesquelles l’HTML avait été conçu, et donc on à commencer à faire des pages statique avec des liens dans tout les sens, puis des pages dynamiques, et la depuis c’est le drame, le réel problème, pour moi reste javascritp, le cycle de vie des pages (et du coup le cycle de vie des données) dans des technos comme asp.net, qui est très différent du cycle de vie des données d’une applies desktop …



de plus, perso je trouve qu’avec le web, le boulot sur l’interface est tellement plus lourd que je suis pas sur qu’on soit si gagnant que cela, mais il reste quand même des avantages.









Lafisk a écrit :



ne serait-ce pas l’UI qui est en java, tandis que le coeur de l’appli est en C++ ??







D’une appli en particulier ?

Parce que sous Android, le SDK c’est du Java interprété par la machine virtuelle Dalvik.

On peut faire du code natif (c, c++) via le NDK d’Android, pour les applis OpenGL par exemple, qui requièrent un max de perfs.

Sincèrement, Facebook en code natif n’a aucun intérêt sous Android. Elle sera sûrement codée en Java.









Lafisk a écrit :



ne serait-ce pas l’UI qui est en java, tandis que le coeur de l’appli est en C++ ??





Oui exactement, mais pour ce qui est de firefox le coeur de l’appli a toujours été en C et quand ils ont abandonné XUL pour leur interface sous android ils ont parlé de nativeUI et c’est du java car le langage plateforme android c’est le java. Tu peux faire tes propres interfaces en C (ce que faisait firefox avec XUL donc) mais ça n’aura pas la même tête que les interfaces natives et c’est pourquoi je doute que facebook utilise autre chose que java.









JackDaniels93 a écrit :



D’une appli en particulier ?

Parce que sous Android, le SDK c’est du Java interprété par la machine virtuelle Dalvik.

On peut faire du code natif (c, c++) via le NDK d’Android, pour les applis OpenGL par exemple, qui requièrent un max de perfs.

Sincèrement, Facebook en code natif n’a aucun intérêt sous Android. Elle sera sûrement codée en Java.





il parlait de firefox la il me semble donc je parlait pas de fb, qui n’a en effet que peu d’intérêt à être dev en C++







satandierbis a écrit :



Oui exactement, mais pour ce qui est de firefox le coeur de l’appli a toujours été en C et quand ils ont abandonné XUL pour leur interface sous android ils ont parlé de nativeUI et c’est du java car le langage plateforme android c’est le java. Tu peux faire tes propres interfaces en C (ce que faisait firefox avec XUL donc) mais ça n’aura pas la même tête que les interfaces natives et c’est pourquoi je doute que facebook utilise autre chose que java.







Oui, mais l’ui ce n’est que l’interface, ce ne sont pas des opérations couteuse (appui sur un bouton, affichage etc…) mais si le coeur de l’appli était en java, tout serait lent car on devrait interprété 1000 fois plus de code, car java est aussi interprété, donc n’est pas beaucoup plus performant que l’html5 au final et présente les mêmes inconvénient, tout comme le C#.



Si ton appli firefox tourne impec c’est parce que les opérations réellement couteuse, surtout celle concernant les input, socket etc.. je suppose pour un navigateur, sont gérées en C langage qui est très performant pour ce genre de taches, contrairement à java



Donc on délègue à java, l’interface, car oui effectivement, c’est plus joli et souvent mieux foutu au niveau du codage de toute façon, mais le gros de l’appli, le plus couteux niveau opération reste gérer par le C









satandierbis a écrit :



Faudrait arrêter de citer C++ à tout-va quand on parle juste de code natif. Sous Android le natif c’est du java et la version android de firefox est bien codée en java -&gt;https://wiki.mozilla.org/Fennec/NativeUI/CodingStyle et pas en c++ comme indiqué dans la news précédente.



Je sais que l’auteur n’aime pas trop Java mais ça ne doit pas empêcher d’être précis pointu carré <img data-src=" />







N’importe quoi. Le NDK sous Android est en C/C++.

NDK comme Native







FrenchPig a écrit :



Sûrement une connerie, mais je suppose que personne ne s’est mis d’accords sur un langage natif utilisable sur toutes les plateformes ?





C/C++ permettent de coder sous Android, WP8, BB, iOS, Linux, Mac, Windows.

Pour les interfaces, ça ne suffit pas, par contre.







Lafisk a écrit :



ne serait-ce pas l’UI qui est en java, tandis que le coeur de l’appli est en C++ ??





Evidemment.









jb a écrit :



C/C++ permettent de coder sous Android, WP8, BB, iOS, Linux, Mac, Windows.

Pour les interfaces, ça ne suffit pas, par contre.





Quel est donc l’intérêt du HTML5 pour les applis du coup ?









FrenchPig a écrit :



Quel est donc l’intérêt du HTML5 pour les applis du coup ?





HTML est un langage qui sert à définir la présentation…donc pour l’interface.<img data-src=" />









jb a écrit :



N’importe quoi. Le NDK sous Android est en C/C++.

NDK comme Native

Evidemment.





Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.



Native ça prends le sens qu’on veut mon petit <img data-src=" />









jb a écrit :



N’importe quoi. Le NDK sous Android est en C/C++.

NDK comme Native





C/C++ permettent de coder sous Android, WP8, BB, iOS, Linux, Mac, Windows.

Pour les interfaces, ça ne suffit pas, par contre.





Evidemment.







Je pense qu’il peut y avoir une erreur d’interprétation autour du terme “native” utilisé par Zuckerberg. Beaucoup de gens entendent par “native” le fait d’utiliser le SDK de la plateforme auquel cas ça serait du Java. Certes le NDK permet de coder en C/C++ sur Android mais Zuckerberg n’en fait pas mention. Le “native” est à opposer au HTML5 qui lui est multiplateforme.



De plus, je ne vois pas ce qui réclame beaucoup de ressources dans une appli comme fb. Ce sont essentiellement des requêtes http pour afficher du texte, des images… A mon sens, il serait plus simple d’utiliser le SDK. Le gain de performances pour une telle appli codée avec le NDK ne serait pas significatif.









satandierbis a écrit :



Native ça prends le sens qu’on veut mon petit <img data-src=" />







Pas pour Google qui édite Android…



…ni pour ceux qui utilisent leurs outils <img data-src=" />



http://developer.android.com/tools/sdk/ndk/index.html









satandierbis a écrit :



Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.







nativeUI, cela veut dire, je pense (car je suis pas expert dans cette techno) que cela utilise des éléments graphique de langage natifs justement, de la même façon qu’en java tu as JNI et JNA, qui permettent d’utiliser du code natif (C/C++), elles ont bien le mot native dans leur nom mais ce n’est pas du langage natif pour autant.





Native ça prends le sens qu’on veut mon petit <img data-src=" />





non, absolument pas, un langage natif est un langage qui n’est pas interprété, il passe cirect par le compilo et c’est fait, ça n’a pas un sens dans un contexte et un autre dans un autre contexte…









Gontran a écrit :



Je pense qu’il peut y avoir une erreur d’interprétation autour du terme “native” utilisé par Zuckerberg. Beaucoup de gens entendent par “native” le fait d’utiliser le SDK de la plateforme auquel cas ça serait du Java. Certes le NDK permet de coder en C/C++ sur Android mais Zuckerberg n’en fait pas mention. Le “native” est à opposer au HTML5 qui lui est multiplateforme.



De plus, je ne vois pas ce qui réclame beaucoup de ressources dans une appli comme fb. Ce sont essentiellement des requêtes http pour afficher du texte, des images… A mon sens, il serait plus simple d’utiliser le SDK. Le gain de performances pour une telle appli codée avec le NDK ne serait pas significatif.







Je m’autoquote pour étayer mon propos en citant la page d’Android Developers sur le SDK:



Typical good candidates for the NDK are self-contained, CPU-intensive operations that don’t allocate much memory, such as signal processing, physics simulation, and so on. When examining whether or not you should develop in native code, think about your requirements and see if the Android framework APIs provide the functionality that you need





Android NDK









Lafisk a écrit :



nativeUI, cela veut dire, je pense (car je suis pas expert dans cette techno) que cela utilise des éléments graphique de langage natifs justement, de la même façon qu’en java tu as JNI et JNA, qui permettent d’utiliser du code natif (C/C++), elles ont bien le mot native dans leur nom mais ce n’est pas du langage natif pour autant.





C’est pas con et je pense même que c’est ça : natif au sens de interfaces natives aux système.



Il n’empêche que ces interfaces se codent en java et une partie du code appplicatif de firefox sous android est en java http://hg.mozilla.org/mozilla-central/file/6e78c3efd115/mobile/android/base) et il en sera de même de facebook parce que google recommande de coder ses applications en java.



Bref, quand quelqu’un parle de natif ne pas lire direct C/C+









satandierbis a écrit :



Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.



Native ça prends le sens qu’on veut mon petit <img data-src=" />





Natif ça a une définition claire, c’est pas “ce que l’on veut”. Java n’est pas un langage natif

Que certains fassent l’erreur veut pas dire que c’est vrai pour autant. (et d’ailleurs, nativeUI n’est pas en java)



Natif a plusieurs sens, mais là, on parle de code natif, pas d’application native, c’est pourtant simple de ne pas se tromper <img data-src=" />








Tolor a écrit :



Natif ça a une définition claire, c’est pas “ce que l’on veut”. Java n’est pas un langage natif

Que certains fassent l’erreur veut pas dire que c’est vrai pour autant. (et d’ailleurs, nativeUI n’est pas en java)





La seule définition claire de natif c’est x86, ppc, arm… tout le reste c’est déjà du flou artistique.



T’as le droit d’être obtus et de n’accepter que ta définition, mais quand mozilla (et probablement facebook) parlent de natif, comprends que C’EST PAS DU C++









Tolor a écrit :



Natif ça a une définition claire, c’est pas “ce que l’on veut”. Java n’est pas un langage natif

Que certains fassent l’erreur veut pas dire que c’est vrai pour autant. (et d’ailleurs, nativeUI n’est pas en java)





Natif veut dire “qui vient de la plateforme” en Français, non ? Avec ce sens le C++ est plus natif que le Java qui est plus natif que le HTML5 sur Android.



Maintenant si ça vous amuse de pinailler sur un mot que tous les développeurs avaient déjà compris dès le départ…



Quand à Android ce n’est pas simplement que Google recommande le java, c’est que le java est OBLIGATOIRE, ne serait-ce que pour servir de wrapper avec le C++.



Quand à facebook ils ne font pas beaucoup d’opérations de calcul lourd qui nécessiterait d’utiliser le C++ (qui n’apporterait donc aucune performance en plus par rapport au Java).

Au pire ils utiliseront le C++ pour une routine de compression des images ou plus tard pour faire de la reco faciale. Même là ce n’est pas sûr, ils peuvent se permettre de perdre 1s à chaque compression le faire en Java plutôt que de s’emmerder avec du code natif.









raoudoudou a écrit :



Natif a plusieurs sens, mais là, on parle de code natif, pas d’application native, c’est pourtant simple de ne pas se tromper <img data-src=" />







<img data-src=" />



Le début de l’article de techcrunch (la source de cet article):



Today, Mark Zuckerberg revealed that Facebook’s mobile strategy relied too much on HTML5, rather than native applications.









satandierbis a écrit :



La seule définition claire de natif c’est x86, ppc, arm… tout le reste c’est déjà du flou artistique.



T’as le droit d’être obtus et de n’accepter que ta définition, mais quand mozilla (et probablement facebook) parlent de natif, comprends que C’EST PAS DU C++





ben en même temps aujourd’hui tu n’en as pas des dizaines d’autres … surtout dans le contexte des smartphone, je doute qu’on code en pascal, basic, cobol ou fortran sur smartphone, donc dans ce domaine quand on parle de natif c’est du C/C++, car le seul cas ou java est un langage natif c’est quand le device est équipé d’une puce spéciale et qu’il ne s’exécute pas sur un VM, chose assez rare, et qui a ma connaissance ne se voit pas sur les smartphones.



d’ailleurs vu la popularité décroissante de la plupart des langages compilés, aujourd’hui assimilé langage natif à C/C++ n’est pas une énorme erreur non plus.



Donc tu as raisons en disant que langage natif != de C/C++, mais tu as tords dans notre cas, qui ce concentre sur le domaine des smartphones, où le C/C++ sont, à ma connaissance, les seuls langages natifs à pouvoir s’exécuter.












satandierbis a écrit :



Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.





Que les gens du marketing de Mozilla racontent n’importe quoi, c’est pas mon problème.







satandierbis a écrit :



Native ça prends le sens qu’on veut mon petit <img data-src=" />







  1. Je suis pas ton petit.

  2. Non. Ca a un sens très précis, et notamment implique l’absence de machine virtuelle.



    Donc non, le Java, c’est pas natif.









FrenchPig a écrit :



Quel est donc l’intérêt du HTML5 pour les applis du coup ?





Plus simple :)







Gontran a écrit :



Je pense qu’il peut y avoir une erreur d’interprétation autour du terme “native” utilisé par Zuckerberg. Beaucoup de gens entendent par “native” le fait d’utiliser le SDK de la plateforme auquel cas ça serait du Java. Certes le NDK permet de coder en C/C++ sur Android mais Zuckerberg n’en fait pas mention. Le “native” est à opposer au HTML5 qui lui est multiplateforme.





Evidemment. Notamment qu’il veut dire NDK+SDK. Il n’a jamais parlé de language, mais d’application.



Le souci, c’était la remarque fausse quotée, qui parle de language.









ErGo_404 a écrit :



Quand à Android ce n’est pas simplement que Google recommande le java, c’est que le java est OBLIGATOIRE, ne serait-ce que pour servir de wrapper avec le C++.





Plus maintenant :)









jb a écrit :



Que les gens du marketing de Mozilla racontent n’importe quoi, c’est pas mon problème.







  1. Je suis pas ton petit.

  2. Non. Ca a un sens très précis, et notamment implique l’absence de machine virtuelle.



    Donc non, le Java, c’est pas natif.





    Bon écoute, il y a une erreur dans la précédente news au sujet de firefox qu’il fallait résumer par “mozilla abandonne XUL pour son interface, maintenant elles seront codée en c++ java avec le sdk d’android”.



    Et là la même erreur est probablement reproduite.



    Après t’en a rien à faire, tu préfère chipoter, jouer l’obtus et prendre les gens de haut (même mozilla) allez… au revoir <img data-src=" />









satandierbis a écrit :



Bon écoute, il y a une erreur dans la précédente news au sujet de firefox qu’il fallait résumer par “mozilla abandonne XUL pour son interface, maintenant elles seront codée en c++ java avec le sdk d’android”.





Probablement.







satandierbis a écrit :



Après t’en a rien à faire, tu préfère chipoter, jouer l’obtus et prendre les gens de haut (même mozilla) allez… au revoir <img data-src=" />





Je ne joue pas l’obtus ni ne prends les gens de haut, c’est toi qui:





  • reproche à l’auteur de la news de ne pas être précis (commentaire 8) (chipote)

  • joue l’obtus vis à vis de la news (c’est eux qui se sont trompés) pour faire valoir ton point.(commentaire 39) (joue l’obtus)

  • appelle les gens: “mon petit” (commentaire 23) (prendre les gens de haut)







    Alors quand tu te trompes, la prochaine fois, dis mea culpa, et arrête d’attaquer les gens en leur reprochant exactement tes défauts.



    Enfin pour le code de Firefox, Gecko est en pure C/C++ et l’application native sous Android est un mixte Java/code-natif.



outre le débat sur le fait que java soit natif ou pas natif (par définition il ne l’est pas), ça me surprendrait qu’ils codent facebook en NDK, vu les emmerdes que c’est…



Les perfs sous java sont suffisantes pour ne pas avoir a faire des allez retour dans du JNI, pour le plaisir de dire “ on a codé en natif” ..



je ne parle bien sur pas des applications CPU intensives comme les lecteurs videos, ou les jeux, qui ont besoin du NDK, mais facebook, faut pas charier…








satandierbis a écrit :



Explique moi pourquoi les gens de mozilla parlent de NativeUI pour des interfaces (et pas que) codées en java.



Native ça prends le sens qu’on veut mon petit <img data-src=" />







Natif c’est natif, cela ne prend pas le sens que l’on veut lorsque l’on fait de la technique. Java n’est pas natif.









Nithril a écrit :



Natif c’est natif, cela ne prend pas le sens que l’on veut lorsque l’on fait de la technique. Java n’est pas natif.









c’est pas pour rien que quand tu veux coder sous android en natif, il faut iliser le NDK : native developpement kit.

Natif ne veux pas dire “langage recommandé “





Attention toutefois à ne pas généraliser : les critiques de Zuckerberg concernent uniquement les applications. Les versions web du site, en particulier mobiles, continueront à utiliser le HTML5 qui garde toute la confiance de l’entreprise.





Un truc que je comprend pas trop, Facebook a une version web (en HTML5) et une “application” (en HTML5 ?!), les deux accessibles sur mobile ? C’est pas un peu redondant ? (et je comprend pas trop la notion d’application en HTML5 non plus).








Pochi a écrit :



(et je comprend pas trop la notion d’application en HTML5 non plus).





si j’en crois les commentaires plus haut, cela concerne surtout l’apparence (l’interface).









Teovald a écrit :



Le nombre de questions sur stackoverflow portant sur PhoneGap me fait peur.

Ok si tu veux faire une app la moins chère possible pour le plus de plateformes possibles & que la qualité n’est donc pas ton objectif (par exemple si elle va juste être utilisée en interne), Phonegap est adapté (même si je conseillerai de considérer carrément une vraie webapp tant qu’à faire…).

Pour une app sérieuse, le html5 c’est à jeter aux ordure, point.







tout a fait d’accord, j’avais vraiment l’impression de faire de cheap / low cost app’









Lafisk a écrit :



car java est aussi interprété, (…), tout comme le C#.





C’est pas tout à fait faux mais j’ai l’impression en te lisant que tu les mets exactement dans le même panier que des langages comme Javascript, ce qui n’est pas non plus tout à fait vrai. Indépendamment des optimisations comme la compilation JIT, aussi bien Java que .Net utilisent des langages intermédiaires qui sans être du code machine restent bien moins coûteux à évaluer que l’interprétation en live du code tel que tapé par le développeur.



Mais effectivement, contrairement à du code compilé en langage machine, on est obligé de disposer d’une couche logicielle chargée de traduire les instructions.







Tolor a écrit :



Natif ça a une définition claire, c’est pas “ce que l’on veut”. Java n’est pas un langage natif.





Personnellement, je pense que tout le monde ici se déchire sur deux définitions de “natif” qui à mes yeux sont tout à fait valides, mais concernent des cas pratiques effectivement différents. À ma droite, ceux pour qui natif signifie “conçu pour être directement donné à manger à du matériel (éventuellement après une opération de compilation)”. À ma gauche, ceux pour quoi cela signifie “utilisant uniquement les outils standards disponibles sur la plate-forme cible”.



D’ailleurs, j’aime penser au terme “natif” comme étant défini relativement à quelque chose, ce qui si on amalgame logiciel et matériel aboutit au final à une généralisation des deux définitions précédemment proposées. Ce qui a à mes yeux d’autant plus de sens que du code “natif” x86 va avoir du mal à tourner sur une plate-forme ARM, et que du code “natif” Java pourrait bien ne pas être apprécié par le CLR.



Et à ce moment-là, il suffit quand le risque de mal être compris est élevé de parler de code “natif matériel” (à défaut d’être spécifique), “natif Android”… et de se faire des bisous plutôt que de se taper dessus. <img data-src=" />









BreizFenrir a écrit :



C’est pas tout à fait faux mais j’ai l’impression en te lisant que tu les mets exactement dans le même panier que des langages comme Javascript, ce qui n’est pas non plus tout à fait vrai. Indépendamment des optimisations comme la compilation JIT, aussi bien Java que .Net utilisent des langages intermédiaires qui sans être du code machine restent bien moins coûteux à évaluer que l’interprétation en live du code tel que tapé par le développeur.



Mais effectivement, contrairement à du code compilé en langage machine, on est obligé de disposer d’une couche logicielle chargée de traduire les instructions.





Personnellement, je pense que tout le monde ici se déchire sur deux définitions de “natif” qui à mes yeux sont tout à fait valides, mais concernent des cas pratiques effectivement différents. À ma droite, ceux pour qui natif signifie “conçu pour être directement donné à manger à du matériel (éventuellement après une opération de compilation)”. À ma gauche, ceux pour quoi cela signifie “utilisant uniquement les outils standards disponibles sur la plate-forme cible”.



D’ailleurs, j’aime penser au terme “natif” comme étant défini relativement à quelque chose, ce qui si on amalgame logiciel et matériel aboutit au final à une généralisation des deux définitions précédemment proposées. Ce qui a à mes yeux d’autant plus de sens que du code “natif” x86 va avoir du mal à tourner sur une plate-forme ARM, et que du code “natif” Java pourrait bien ne pas être apprécié par le CLR.



Et à ce moment-là, il suffit quand le risque de mal être compris est élevé de parler de code “natif matériel” (à défaut d’être spécifique), “natif Android”… et de se faire des bisous plutôt que de se taper dessus. <img data-src=" />





<img data-src=" />









jb a écrit :





  1. Non. Ca a un sens très précis, et notamment implique l’absence de machine virtuelle.



    Donc non, le Java, c’est pas natif.





    Attention, je vais pinailler :

    GCJ ne permet-il pas de compiler du code java en code machine ?

    Est-ce du natif dans ce cas ?



    :-)









BreizFenrir a écrit :



C’est pas tout à fait faux mais j’ai l’impression en te lisant que tu les mets exactement dans le même panier que des langages comme Javascript, ce qui n’est pas non plus tout à fait vrai. Indépendamment des optimisations comme la compilation JIT, aussi bien Java que .Net utilisent des langages intermédiaires qui sans être du code machine restent bien moins coûteux à évaluer que l’interprétation en live du code tel que tapé par le développeur.



Mais effectivement, contrairement à du code compilé en langage machine, on est obligé de disposer d’une couche logicielle chargée de traduire les instructions.







je “vulgarise” sûrement trop mais non y’a clairement une grosse différence entre JS, java, etc… mais bon je vais pas taper 500 lignes histoire d’être ultra précis, en général, je tranche dans le vif, et ‘a ceux qui ont l’habitude voir qui font pareil et comprennent de suite et les autres qui demande des précisions <img data-src=" />









liukahr a écrit :



Attention, je vais pinailler :

GCJ ne permet-il pas de compiler du code java en code machine ?

Est-ce du natif dans ce cas ?



:-)





C’est la que ça commence la vraie branlette de programmeur.<img data-src=" />









liukahr a écrit :



Attention, je vais pinailler :

GCJ ne permet-il pas de compiler du code java en code machine ?

Est-ce du natif dans ce cas ?



:-)





en fait Java est un peu batard, il est l’un ou l’autre selon le cas, mais est la plupart du temps utilisé en tant que langage interprété.









liukahr a écrit :



Attention, je vais pinailler :

GCJ ne permet-il pas de compiler du code java en code machine ?

Est-ce du natif dans ce cas ?

:-)







Arf, exact :) <img data-src=" />









Lafisk a écrit :



en fait Java est un peu batard, il est l’un ou l’autre selon le cas, mais est la plupart du temps utilisé en tant que langage interprété.





Non Java a été conçu comme un langage interprété par une VM( le bytecode n’est pas du code natif ).



Ensuite comme pour tous les langages on peut( et on a ) créer un compilateur en natif…<img data-src=" />



Ils ont juste voulu aller trop vite. L’HTML5, c’est bien mais pas mature.

Comment comparer une technologie même pas standardisée avec des langages ultra éprouvés comme JAVA ou C ?

C’est tout faut encore attendre quelques années. On va voir déjà ce que fait Mozilla avec son Firefox OS.

Toujours est-il que l’HTML5 est suffisant pour de petites applis.








Alucard63 a écrit :



Non Java a été conçu comme un langage interprété par une VM( le bytecode n’est pas du code natif ).



Ensuite comme pour tous les langages on peut( et on a ) créer un compilateur en natif…<img data-src=" />





non, tu as des puces qui permettent de ce passer de VM et donc de bytecode, qui compile directement du picojava (instruction similaire à l’asm.



et GCJ, si tu prend 10secondes et lit la description“It can compile Java source code to Java bytecode (class files) or directly to native machine code” peut compiler vers du bytecode comme il peut compiler vers du code machine directement.



Java n’a pas été conçu que comme un langage interprété, mais Sun pensait à l’époque que tout le monde voudrait s’équiper de leurs puce maison, qui permettait de ce passer de VM, ce qui ne fût le cas, et la parti interprétée est plus restée au fil des évolutions, mais tu peux très bien compiler directement en code machine avec du Java, théoriquement, pourvu que tu es le bon matos.









Lafisk a écrit :



Java n’a pas été conçu que comme un langage interprété, mais Sun pensait à l’époque que tout le monde voudrait s’équiper de leurs puce maison, qui permettait de ce passer de VM, ce qui ne fût le cas, et la parti interprétée est plus restée au fil des évolutions, mais tu peux très bien compiler directement en code machine avec du Java, théoriquement, pourvu que tu es le bon matos.





Ils m’ont menti à la l’école, remboursé!<img data-src=" />



Oh! On me signale à l’oreillette que j’était boursier donc je n’aurai rien.<img data-src=" /><img data-src=" /><img data-src=" />



Le 12/09/2012 à 15h 07



Le HTML5 est un langage interprété (…) Dans le cas du natif, cette étape est supprimée : le code est directement exécuté et la différence de performances est visible.



Les problèmes de performances du HTML5 ne sont pas dus au fait que le langage soit interprété, il existe des tas de techniques pour exécuter du code dans une VM à un niveau de performance proche du natif. Il y a une vie en dehors du C/C++.








Alucard63 a écrit :



Ils m’ont menti à la l’école, remboursé!<img data-src=" />



Oh! On me signale à l’oreillette que j’était boursier donc je n’aurai rien.<img data-src=" /><img data-src=" /><img data-src=" />





pourtant c’est exactement ce que j’ai appris à l’université, vu qu’on nous faisait bouffer du picojava, alors que l’asm … une après midi <img data-src=" />









Lafisk a écrit :



pourtant c’est exactement ce que j’ai appris à l’université, vu qu’on nous faisait bouffer du picojava, alors que l’asm … une après midi <img data-src=" />





Je savais que ça venait de l’embarqué au début mais je crois que le prof avait surtout insisté sur le fait que ça avait été pensé comme interopérable dès le début grâce à la VM( c’est surtout ça que les élèves doivent mal comprendre je pense ).<img data-src=" />









johnlesnones a écrit :



Les problèmes de performances du HTML5 ne sont pas dus au fait que le langage soit interprété, il existe des tas de techniques pour exécuter du code dans une VM à un niveau de performance proche du natif. Il y a une vie en dehors du C/C++.







De mon point de vu il n’y a vraiment pas de problème de performance du HTML 5 dans les navigateurs modernes









Alucard63 a écrit :



Je savais que ça venait de l’embarqué au début mais je crois que le prof avait surtout insisté sur le fait que ça avait été pensé comme interopérable dès le début grâce à la VM( c’est surtout ça que les élèves doivent mal comprendre je pense ).<img data-src=" />





Oui en effet, les deux côtés étaient dans leurs pensés au début je pense, la réalité les a rattraper par la suite <img data-src=" />



Disons que le java a été conçu avec 2 objectifs distincts dès le début, l’embarqué et l’interopérabilité, l’un n’allant pas avec l’autre en général, sauf grosse erreur de ma part, l’embarqué en général c’est quand même des cibles bien précises et plus ou moins sur mesure donc l’interopérabilité … <img data-src=" />



mais bon java n’a jamais réellement percer dans l’embarqué, bien qu’il y ai eu quelques projets par-ci par-la. Après, android … j’aime pas trop donc je n’ai jamais regarder de très près, mais faut que j’avoue que je serais curieux de savoir ce qui s’exécute vraiment au final derrière, par exemple le java, il passe par une VM du coup, non ? au final, les micro-instructions c’est quoi sur android ?? de l’asm ?? mais bon la flemme de chercher, la plateforme m’intéresse tellement peu <img data-src=" />









jb a écrit :



Plus maintenant :)





Euh tu as un piti lien pour étayer ça ? Je suis intéressé :)



Le 12/09/2012 à 15h 57







Nithril a écrit :



De mon point de vu il n’y a vraiment pas de problème de performance du HTML 5 dans les navigateurs modernes





Exact, depuis que les navigateurs implémentent une VM javascript “state of the art”. Il faudrait le dire au rédacteur de cet article qui n’a pas l’air bien au courant <img data-src=" />.



Je suis curieux de savoir ce qui leur a posé le plus problème, ainsi que les obstacles qu’ils n’ont pas pu surmonter…


Le HTML5 n’est (pour moi) qu’un langage de balises, son traitement est rapide sur n’importe quel moteur de rendu récent sur n’importe quel support (desktop/mobile).

Là où ça pêche vraiment au niveau des performances, c’est sur les traitements du DOM JavaScript.

C’est bien beau d’avoir des raccourcis d’écriture avec de belles librairies comme jQuery et autres qui provoquent des traitements massifs sur le DOM, mais sur un appareil mobile c’est beaucoup moins fun en terme de réactivité (sans même parler du temps de téléchargement de la librairie sur un réseau mobile).

Le plus consternant est d’utiliser du Javascript pour faire des animations qui sont faisables à 100% en CSS, et qui passe beaucoup mieux sur du mobile.



Enfin bref, accuser HTML5 c’est se tromper de cible.








piwi82 a écrit :



Le HTML5 n’est (pour moi) qu’un langage de balises, son traitement est rapide sur n’importe quel moteur de rendu récent sur n’importe quel support (desktop/mobile).

Là où ça pêche vraiment au niveau des performances, c’est sur les traitements du DOM JavaScript.

C’est bien beau d’avoir des raccourcis d’écriture avec de belles librairies comme jQuery et autres qui provoquent des traitements massifs sur le DOM, mais sur un appareil mobile c’est beaucoup moins fun en terme de réactivité (sans même parler du temps de téléchargement de la librairie sur un réseau mobile).

Le plus consternant est d’utiliser du Javascript pour faire des animations qui sont faisables à 100% en CSS, et qui passe beaucoup mieux sur du mobile.



Enfin bref, accuser HTML5 c’est se tromper de cible.





Le problème de l’HTML, c’est qu’il ya 10000 fois trop de façon de faire une seule et même chose, et comme en général les dèvs font ce qu’ils connaissent, ben tu te retrouves plus souvent avec des truc merdiques que des bons truc bien foutus … voila pourquoi je trouve que le dev web c’est vraiment de la daube …









Lafisk a écrit :



Le problème de l’HTML, c’est qu’il ya 10000 fois trop de façon de faire une seule et même chose, et comme en général les dèvs font ce qu’ils connaissent, ben tu te retrouves plus souvent avec des truc merdiques que des bons truc bien foutus … voila pourquoi je trouve que le dev web c’est vraiment de la daube …







Pour se prétendre développeur web, il faut connaître la sémantique d’HTML. Sans ça, un développeur aura beau être une brute en PHP/JavaScript, s’il ne son balisage par la sémantique il pondra effectivement du code HTML merdique.



On ne peut pas dire que le dev web soit de la daube, ou alors ça s’applique aussi tous les autres types de développement. Dans tous langage il y a des règles à respecter. Malheureusement dans le dev web, même pas 1% de ceux qui se prétendent développeurs ne les respectent.









piwi82 a écrit :



Pour se prétendre développeur web, il faut connaître la sémantique d’HTML. Sans ça, un développeur aura beau être une brute en PHP/JavaScript, s’il ne son balisage par la sémantique il pondra effectivement du code HTML merdique.



On ne peut pas dire que le dev web soit de la daube, ou alors ça s’applique aussi tous les autres types de développement. Dans tous langage il y a des règles à respecter. Malheureusement dans le dev web, même pas 1% de ceux qui se prétendent développeurs ne les respectent.







c’est bien ce que je dis, le truc c’est qu’en dèv desktop tu as en général beaucoup moins de règle (je parle niveau interface), enfin disons moins de façon de faire différentes, tu n’en as pas qu’une seule mais le problème de l’html c’est qu’il y en a beaucoup trop et que certaines techniques s’utilise dans des contextes précis etc… ces contextes ne sont pas toujours respectés, tout simplement parce qu’ils sont méconnus des développeurs, moi même je suis dèvs et loin de connaitre à fond le dèvs web, je fais ça à contre coeur plus qu’autre chose en vrai, pour le moment.