IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Intel mise sur le HTML5 pour le développement multiplateforme

Le , par Hinault Romaric

26PARTAGES

3  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de CapFlow
Membre actif https://www.developpez.com
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.
7  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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
6  1 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
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.
5  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 01/01/2013 à 13:23
Merci Sencha pour cette démonstration de la totale incohérence du discours de M.Zuckerberg. Il est ridicule de désigner le HTML5 comme responsable des lenteurs de l'application, alors que la plupart des utilisateurs sur Android se sont aperçus que passer par le site mobile (donc à plus forte raison du HTML) via le navigateur était bien plus rapide.

Le choix technologique du HTML5 ne justifie en rien des pages qui mettent presque une minute à se charger... Si les requêtes et le code sont correctement optimisés, la différence de performance devrait être minime voire insignifiante pour une application et un device de ce type.

La question du choix web ou natif doit se poser pour chaque projet selon les contraintes budgétaires / cible / pérennité / ressources / scope fonctionnel etc... J'irais même plus loin en disant que la question devrait se poser pour chaque composant de l'application. Car oui, beaucoup ne savent pas ou ont oublié qu'on peut très bien viser au milieu en concevant des applis hybrides : un peu de natif par ci, un peu de HTML par là, pour chercher le meilleur rapport productivité/qualité. Ne prêcher que par le natif ou par le web, ça n'a pas de sens ; toutes les applications ne rentrent pas dans le même moule.
5  0 
Avatar de
https://www.developpez.com
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
4  0 
Avatar de Freem
Membre émérite https://www.developpez.com
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.
4  0 
Avatar de stailer
Membre chevronné https://www.developpez.com
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...
3  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 04/01/2013 à 10:31
Pour ce qui est des smartphones je ne me prononcerais pas.

mais pour ce qui est des desktops
J’utilise Sencha depuis bien longtemps et je suis entièrement d’accord avec le discours de Sencha lorsqu’ils disent que le plus souvent c’est le mode de développement qui est en cause.

on pense trop souvent que le développent sur le navigateur passe par un développement de pages web avec des enrichissements en JavaScript et CSS.
or on peut très bien développer ses applis en adoptant les mêmes principes qu’avec le natif MVC KVC DAO etc.

Quant à la compatibilitité avec les navigateurs même anciens je n’ai pas de pb. il existe encore nombre de IE6 (une vraie plaie) dans mon entreprise et même ces versions-là sont supportées.

J’ai développé de grosses applications (plusieurs milliers de lignes de codes) dans des boîtes de 100*000 et 200*000 postes et les ralentissements sont toujours venus de la partie serveur.

Quant à développer sur le navigateur qui serait plus complexe qu’en natif. Je constate que les phantasmes on la vie dure.

A+JYT
3  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 04/01/2013 à 16:53
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
3  0 
Avatar de stailer
Membre chevronné https://www.developpez.com
Le 29/12/2012 à 1:05
il en faut 5 fois plus pour la maintenance en html 5 ! car le principal problème est justement la compatibilité avec les divers navigateurs et non pas le problème de perf comme le souligne facebook !! ( preuve en ai, sencha et sa démo ... )

je pense donc au final qu'il s'agit plus d'une question de coût que de perf ...
Je pense pas qu'il faille voir les choses de façon aussi tranchées.

Tout dépend de l'app que tu développes. Déjà selon les besoins, certaines choses ne sont pas possibles en HTML5 ou très difficilement comparées à une version native.

D'un autre côté, dans le cas d'une app avec des besoins réalisables à la fois en natif et en html5 je pense que le temps de dév est au pire le même avec l'avantage du cross plateform pour le html5.

La raison en est simple : une fois que tu as ton archi et que tu as vérifié que tes composants fonctionnent bien sur IOS / Android (car aujourd'hui tout le marché est là) il n'y a pas de raison de multiplier le temps dév.

Me concernant j'ai réalisé une démo il y a peu de temps sous Sencha Touch 2.0.3 : j'ai eu en effet des soucis sur la version Android, surtout de performances.
Une fois que les ai résolus, toute mon archi était prête à fonctionner pour X appli avec un déploiement sous IOS et Android... Certes il y a eu une perte de temps au départ mais tu ne réinventes pas non plus la roue à chaque projet.
2  0