GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

Les applications natives seront-elles remplacées par celles en HTML5 ?
La fin du règne du natif annoncée pour l'an prochain

Le , par Hinault Romaric, Responsable .NET
Le HTML5, la prochaine révision majeure du HTML dont les travaux de spécification sont encore en cours, fait couler beaucoup d’encre.

Le soutien et l’adoption du futur standard du Web par les géants comme Microsoft, Google ou encore Mozilla ont donné naissance à d’innombrables débats sur la pertinence des plateformes existantes comme Flash et Silverlight.

Certains estiment même que le HTML5 pourrait apporter une véritable mutation dans le monde des applications, avec une orientation des entreprises et développeurs vers les solutions HTML 5 au détriment des solutions natives.

C’est en tout cas le point de vue de Jon Lech Johansen, développeur Novergien, reconnu pour ses travaux de rétro-ingénierie sur la gestion des droits numériques, qui estime dans un tweet que « les applications natives seront remplacées par les applications HTML5 l’an prochain ».

La position actuelle des éditeurs donne du crédit à cette affirmation.

Microsoft a mis en avant dans son futur OS Windows 8, qui sera disponible l'année prochaine, la possibilité offerte aux développeurs de créer des applications Metro en utilisant uniquement le couple HTML5 + JavaScript.

Mozilla, de son côté, espère également publier avant la fin de 2012, son nouvel OS mobile « Boot to Gecko », qui permettra de créer des applications HTML 5 pouvant supplanter des solutions natives.

À ces exemples, viennent s’ajouter les avis des éditeurs des magazines numériques. Rob Grimshaw, directeur général de la division numérique du Financial Times, lors du sommet Open Mobile a déclaré : « Nous avons utilisé HTML5 pour sortir de iTunes et entrer à nouveau dans l’environnement du navigateur ».

L’année prochaine pourrait être l’année du HTML 5 au détriment des applications natives ? Ou celles-ci ont encore des beaux jours devant elles ?

Source : Twitter Jon Lech Johansen


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de zeyr2mejetrem zeyr2mejetrem - Membre chevronné https://www.developpez.com
le 07/11/2011 à 21:52
Citation Envoyé par Paul TOTH  Voir le message
non, HTML est utilisé comme XML dans d'autres langage, pour le design de l'appli et les binds avec des composants systèmes. Ensuite JS fait le reste.

Et JS, pour fonctionner, nécessite bien un moteur Javascript (Webkit, Gecko ou Trident...), non ?

Mais on le faisait déjà il y a 20 ans avec Visual Basic, qu'est ce qui empêcherais Javascript d'utiliser les connexion BDD de Microsoft ou d'écrire une couche métier ? JS est tout de même un peu plus évolué que VB (j'ai lâché le produit à la version 3 ceci dit) !

Js n'est pas plus évolué que VB (du moins les versions actuelles).
De plus, si Javascript utilise des couches natives (OLE, ODBC...) il perd son intérêt en tant qu'alternative au natif ...

En tant que développeur Delphi, je ne suis pas pour l'harmonisation des langages et du "tous sous JS", mais ça reste pourtant techniquement tout à fait réalisable.

Quant à moi je suis contre l'optique du langage unique.
Et ce n'est pas parce qu'une chose est réalisable qu'elle est souhaitable
Avatar de Paul TOTH Paul TOTH - Expert éminent sénior https://www.developpez.com
le 08/11/2011 à 5:50
Citation Envoyé par zeyr2mejetrem  Voir le message
Et JS, pour fonctionner, nécessite bien un moteur Javascript (Webkit, Gecko ou Trident...), non ?

et VB un Runtime, Java une JVM... et .Net un CLI, on s'éloigne du natif même avec les outils modernes...après dans quelle mesure il est possible de compiler du Javascript en natif...c'est ce que fait le JIT de toute façon.

Citation Envoyé par zeyr2mejetrem  Voir le message
Js n'est pas plus évolué que VB (du moins les versions actuelles).
De plus, si Javascript utilise des couches natives (OLE, ODBC...) il perd son intérêt en tant qu'alternative au natif ...

en fait je pense que l'idée c'est dans l'autre sens, permettre de développer "nativement" avec les outils du Web...probablement aussi pour dénaturer le Web et en faire du Metro, donc du Windows, donc du Microsoft Comme IE6 qui a la peau dure.

Citation Envoyé par zeyr2mejetrem  Voir le message
Quant à moi je suis contre l'optique du langage unique.
Et ce n'est pas parce qu'une chose est réalisable qu'elle est souhaitable

Je préfère JS à VB...mais ma préférence va toujours au Pascal...partant de là mes souhaits et la réalité ne sont pas toujours d'accord
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 08/11/2011 à 8:36
Citation Envoyé par Paul TOTH  Voir le message
et VB un Runtime, Java une JVM... et .Net un CLI, on s'éloigne du natif même avec les outils modernes...après dans quelle mesure il est possible de compiler du Javascript en natif...c'est ce que fait le JIT de toute façon.

Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Citation Envoyé par DonQuiche  Voir le message
Par rapport au C++, oui, dotnet nous a fait gagner en productivité et permet d'écrire un code plus clair et plus maintenable selon moi, et plus stable. Y a t-il un coût en performances ? Bien sûr de l'ordre de 30%, ce qui est acceptable pour la plupart des applications.

La situation est-elle alors comparable avec js+html ? Non :
* Le coût en performances n'est pas de 30% avec js+html, il est beaucoup plus élevé, sans doute 500% à 1000%. Le moindre accès à une variable impose de consulter un dictionnaire.
* Cette perte de performances se faisait dans le cadre de machines dont la puissance doublait tous les 18 mois. Ici la puissance vient d'être divisée par 20.
* Dotnet permettait d'accroître la productivité. Js+html la diminue.

Enfin, le sens de l'histoire jusqu'à présent, c'était d'accroître la productivité au détriment des performances. Rien de tel avec js+html. Le seul intérêt de js+html c'est de prétendre à être un esperanto, ce qui est relativement faux (support restreint de html5 sur les postes windows existants et sans doute anciens iphones) et à relativiser par l'existence d'alternatives viables

Merci beaucoup DonQuiche, quand je lis ça j'ai moins l'impression d'avoir loupé le virage du RIA en pur html/javascript. Je trouve même que ce que fait html5 (au sens large), certaines technos font la même chose depuis des années avec des outils puissants (Silverlight et flash entre autre pour ne pas le nommer) et là soudain, un comité, après moult houleuses délibérations (qui prennent des années) nous pond un "standard" et hop tout le monde s'accorde à dire que c'est le futur et que le reste n'a aucune raison d'être.
On a pourtant au coeur de tout ça javascript, un langage conçu à la base pour servir à faire des petits bricolages plus qu'autre chose, un truc dont presque tout le monde s'accord à dire qu'il n'est pleinement satisfaisant ni sur la performance, ni sur la portabilité, ni sur le reste (typage, organisation, scope, sécurité, etc...).

Est-ce que je dénigre? En fait je constate que reprendre du code javascript est souvent une tâche horrible, et que ça a beau être standard, il y a toujours des différences subtiles entre les navigateurs qui demandent beaucoup de test sur différentes configs, et rarement du test facilement automatisable.

Lorsque je code en java, .net, c++, ou même python (lui aussi interprété). Malgré leurs défauts je sais que tout fonctionne "comme codé" en exécution sauf si l'utilisateur me fait une grosse variante (runtime exotique).

Donc avec ce que je vois de JS aujourd'hui je suis très sceptique avec le côté "coder une fois, faire tourner sur iPhone, Android, Desktop" etc... Je sais beaucoup ne cessent de dire que la situation actuelle c'est la faute à IE, peut être mais franchement ce n'est pas une excuse que je peux facilement sortir de mon chapeau devant un client.

Alors je suis plein de doutes quand j'entends dire que le html/js dans le navigateur c'est le futur de mon métier car avec ce que je vois de ces technos web aujourd'hui, il reste beaucoup de chemin à faire...
C'est peut être le futur de youtube, de gmail, de messenger, de l'application iPhone X qui fait prout mais j'ai encore du mal à imaginer une simple caisse enregistreuse codée là dessus. Ne serait-ce que pour l'accès aux périphériques...

Accessoirement, et c'est surtout là la raison de cet engouement, il offre d'autres débouchés à une pléthore d'équipes web js+html moins coûteuses.

Peut être mais les tests, ça coûte plutôt cher aussi. A moins que des supers outils se développent ou que des garanties sérieuses de respect inconditionnel d'une spécification super stricte et sans ambiguïté soient fournis au développeur.

Ce n'est pas impossible en soi. Mais j'attend de voir, rester avec mes technos et ma mentalité dépassés encore un moment.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 08/11/2011 à 9:31
Citation Envoyé par zeyr2mejetrem  Voir le message
Je résume mon propos pour éviter toute confusion:

  • Dire que dans un an tous les développements natifs seront remplacés par du développement Web est idiot dans la mesure où le navigateur, on le code en quoi ??? En techno native, non ?
  • S'extasier devant le HTML5 est un peu bizarre dans la mesure où HTML5 est une norme encore instable qui arrive après la guerre. Le besoin a été comblé par plusieurs technos maintenant très répandues.
  • De toute façon même une fois la norme stabilisée, les implémentations seront très probablement dépendantes du navigateur comme avec le JS actuellement.
  • Il est tout à fait possible de faire de très jolis applis web avec les technos existantes (HTML5 ne présente donc pas vraiment d'intérêt)
  • La grosse problématique du web est de pouvoir accéder aux ressources matérielles du client (surtout en mobile) mais la solution viendra des APIs du navigateurs qui seront de toute façon accessibles avec les technos existantes.
  • Pour les grosses applis industrielles, l’exécution côté client est soit trop gourmande en ressources soit trop risquée pour utiliser du web, HTML5 compris, et donc les développements natifs (au sens dépendant de l'OS) "lourds" C++, Java ont encore de beaux jours devant eux
    .
  • De toute façon avec l'inertie des gros systèmes on est pas près de passer à un HTML5 qui n'a pas encore fait ses preuves

De toute facon le constat de départ est foireux, l'interprétation du tweet par le newsers particulièrement.
Il est plus qu'évident que HTML5, CSS3, WebGL, Javascript, ... ne pourront pas remplacer toutes les applications natives et surtout pas dès l'année prochaine.
Par contre dans pas mal de cas, c'est déjà possible. Et vu l'évolution assez rapide du web ces derniers temps, je pense qu'en effet le HTML 5 à tout ce qu'il faut pour remplacer les applications lourde dans de nombreux cas ou ce n'était même pas imaginable avant.

Citation Envoyé par xelab  Voir le message
C'est vrai... et en même temps personne n'a dit ça au final, si on lit bien le tweet original... C'est assez aberrant que la news n'ait pas été corrigée et qu'un débat soit parti sur une interprétation complètement contraire au sens initial du tweet.

Ça fait un moment que les news de developper.com ressemblent de plus en plus a des invitations au troll. Les modérateurs doivent s’ennuyer sur les sujets trop techniques.

Citation Envoyé par Paul TOTH  Voir le message
Mais on le faisait déjà il y a 20 ans avec Visual Basic, qu'est ce qui empêcherais Javascript d'utiliser les connexion BDD de Microsoft ou d'écrire une couche métier ? JS est tout de même un peu plus évolué que VB (j'ai lâché le produit à la version 3 ceci dit) !

Difficile de dire que le JS ou le VB sont plus évolués l'un que l'autre. C'est deux langages différents qui ont en commun de ne pas avoir été crée pour ce a quoi il servent aujourd'hui.
Le premier a une orientation objet par prototype, ce qui le rend aux yeux de ces adeptes vraiment "puissant", pour moi c'est surtout tellement souple que ça deviens très vite le bordel. Même si en général ça marche, on écrit souvent des choses sans être très sur de ce que l'on fait. Enfin c'est complètement inadapté à la plupart des outils d'aide au programmeur (complétion, refactoring,...).
Visual Basic était a la base une langage pour débutant qui a été modifié et a gagné un modèle objet certes plus strict que le modèle par prototype, mais qui me déroute vraiment.
Citation Envoyé par _skip  Voir le message
Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Ca doit bien faire 2 ans que tous les navigateurs font du JIT, certains mieux que d'autre. Il faut dire que le Javascript n'est pas le langage le plus adapté pour ça.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 08/11/2011 à 9:36
Citation Envoyé par _skip  Voir le message
Javascript est jitté actuellement avec certains navigateurs?
Je sais que c'est en préparation depuis longtemps mais aucune idée d'où ça en est.

Il l'est avec Firefox et Chrome, oui, depuis un moment maintenant.

Malheureusement, cela reste lent : la VM doit toujours aller consulter un dico pour accéder à la moindre variable et fonction, les vérifications de types doivent toujours être réalisées à l'évaluation (pour une addition par exemple, le membre gauche doit toujours tester le type du membre droit et traiter chacun des cas), toutes les opérations légères demeurent lourdes (les opérateurs addition, référencement, égalité, etc sont toujours des appels de fonction avec appel au dico), le moindre entier demeure en réalité un objet lourd (type, dictionnaire des membres, etc).

Bref, toutes ces choses qui, avec un typage statique et fort sont résolues à la compilation demeurent ici presque toujours résolues à l'évaluation. En théorie, il serait possible d'aller plus loin en exploitant le fait que l'essentiel du code dynamique peut être retraduit en langage statique : d'abord on reconstruit une hiérarchie de types (amalgamer les objets ayant les mêmes membres), ce que les navigateurs font déjà, puis on procède à une analyse statique approfondie afin de prédire le pseudo-type de nombreuses variables et on utilise ensuite cette information pour résoudre le plus de choses possibles à la compilation.

Hélas, l'analyse statique est coûteuse et même avec des algorithmes simples pour ce problème particulier (O(n^3) / O(n^4)), quelques dizaines de ko de code à traiter (disons 500 à 2000 lignes) suffisent typiquement à dépasser les dix secondes, puis la minute quand celui-ci double, puis une heure en multipliant encore par cinq, etc... Accessoirement, si le problème est très intéressant, je pense que tous ceux qui s'y sont frotté seront d'accord avec moi pour dire que c'est une horreur à écrire : on se retrouve typiquement à générer plusieurs représentations du code sous diverses formes - graphes de dominance, arbres, piles, etc - qu'il faut ensuite modifier et resynchroniser les unes à partir des autres tout en optimisant sévèrement les performances, faire passer le tout dans des machines de turing, ...
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 08/11/2011 à 9:39
Citation Envoyé par zeyr2mejetrem
Pour faire de la vue, OK, c'est bien HTML/Js.
Pour faire du métier ou du traitement un peu lourd c'est pas fait pour ...
Maintenant, j'ai peut être tord mais j'aimerai voir un exemple qui me contredise (avec du vrai traitement et de la base de donnée, pas un éditeur de texte ...)

Par exemple ça : http://mbebenita.github.com/Broadway/broadway.html
D'après l'auteur c'est 4 fois plus lent que l'équivalent C, mais ca reste quand même une bonne performance.

Pour la base de donnée, de toute façon, ça n'a que très rarement intérêt coté client.

Citation Envoyé par DonQuiche
Bref, toutes ces choses qui, avec un typage statique et fort sont résolues à la compilation demeurent ici presque toujours résolues à l'évaluation. En théorie, il serait possible d'aller plus loin en exploitant le fait que l'essentiel du code dynamique peut être retraduit en langage statique : d'abord on reconstruit une hiérarchie de types (amalgamer les objets ayant les mêmes membres), ce que les navigateurs font déjà, puis on procède à une analyse statique approfondie afin de prédire le pseudo-type de nombreuses variables et on utilise ensuite cette information pour résoudre le plus de choses possibles à la compilation.

La dernière version (ou la béta en cours, je suis plus sur) de Firefox fait de l'inférence de type, le gain est sensible mais c'est encore loin d'être parfait.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 08/11/2011 à 9:54
Citation Envoyé par Uther  Voir le message
La dernière version (ou la béta en cours, je suis plus sur) de Firefox fait de l'inférence de type, le gain est sensible mais c'est encore loin d'être parfait.

Oui et je ne pense pas que ça le sera, les gains issus de ces stratégies vont être de plus en plus faibles. A mon avis les espoirs d'optimisation reposent plutôt sur l'intégration de nouvelles API au sein des navigateurs, comme le projet de Firefox de fournir des appels JQuery natifs (les appels JQuery JS seraient remplacés à la volée par les appels au code natif). Malheureusement la limite de cette stratégie et des autres, c'est que les dévs doivent pondre un code pour le plus petit dénominateur commun, le plus lent des navigateurs parmi leurs clients : aujourd'hui, IE6.
Avatar de regisportalez regisportalez - Futur Membre du Club https://www.developpez.com
le 09/11/2011 à 13:46
Citation Envoyé par camus3  Voir le message
Et tes navigateurs , ils tournent sous quoi ? un os javascript ? et tes navigateurs ils sont codés en quoi ? javascript ?et le dom ? et les moteurs javascript , ils sont codés en quoi ? javascript ? pour que des personnes comme toi puissent se la jouer HTML5 , d'autres se sont cassé le cul à développer des moteurs qui tournent relativement vite dans des technos que tu dénigres. On appelle cela être ignorant.

A la base je suis développeur C/Cuda donc je n'ai vraiment rien contre les autres langages.
Non je ne dénigre rien, ce n'est pas mon genre.
Mais si on critique les technos en disant qu'elles se basent sur d'autres trucs, on ira pas bien loin...
Avatar de Chuck_Norris Chuck_Norris - Rédactrice/Modératrice https://www.developpez.com
le 09/11/2011 à 15:39
Citation Envoyé par DonQuiche  Voir le message
Tu dis ça parce tu es dév php/js et jaloux des rémunérations des dévs Java/C#/C++ ?

Donc en gros tu me prends pour une personne sans principe qui ne pense qu'à l'argent ?

Désolé. Je préfère faire ce en quoi je crois, ce en quoi je pense qu'il y a de l'avenir, ce qui me plaît, même si je dois pour ça vivre avec mon compte à découvert, plutôt que d'être riche, mais faire quelque chose qui ne me plaît pas et pour lequel je pense qu'il n'y a plus d'avenir ?

Citation Envoyé par _skip  Voir le message
J'en suis pas sûr. Vu le temps qu'il a fallu pour nous concocter un html5, les technos propriétaires peuvent facilement devancer ce premier en fonctionnalité en offrant des cycles de release plus rapides. Je ne les enterrerai pas trop vite...

Regarde la nouvelle récente : Flash Player est abandonné pour mobiles. C'est bête hein, mais cela montre qu'au contraire le Html 5 est l'une des solutions permettant d'avoir la compatibilité dans le futur avec toutes les plate-formes, sans dépendre du bon vouloir d'un éditeur qui décide d'arrêter le produit du jour au lendemain, ou qui décide ou pas de supporter une plate-forme (ou de mal la supporter). D'où l'intérêt d'un standard qui ne dépend pas de logiciels propriétaires pour concevoir ou exécuter la chose afin d'avoir la pérennité du développement.

Citation Envoyé par zeyr2mejetrem  Voir le message
D'habitude je porte le plus grand crédit à ton opinion mais là, laisse moi te dire que tu m'as bien fait marrer
"la puissance du langage Javascript"

Citation Envoyé par Robin56  Voir le message
Moi je dirais que ça sent un peu le second degré, non ?

Certes mon message était un peu provocateur. On voit aussi que j'ai touché un point sensible des développeurs applicatifs vu l'avalanche de [-] que j'ai eu dans mon message. Ne dit-on pas, y'a que la vérité qui blesse ?

En ce qui concerne la puissance du langage Javascript, je vais te dire ce que j'en pense.

On est parti d'un langage peu performant, mal conçu dès le départ et à la compatibilité douteuse. Depuis, le langage a été (un peu) enrichi à la base. Mais surtout, le langage a été enrichi considérablement avec l'avènement des bibliothèques Javascript comme jQuery, ExtJS, et d'autres.

Alors certes les bases sont pas solides, mais elles sont là, et on fait avec. Avec le travail qui a été fait au niveau des navigateurs pour optimiser le Javascript, on peut maintenant faire beaucoup de choses qu'auparavant on aurait jamais imaginées.

On pourrait certes faire un langage bien mieux adapté aux besoins. Le problème est qu'il y a tout le poids de l'existant. Quand on sait qu'IE 6 règne toujours en maître et surtout dans les entreprises, je pense qu'il faut pas trop compter sur une alternative à Javascript avant des années.

Citation Envoyé par timiteh  Voir le message
Sérieusement, il y a bien une raison pour laquelle Google a developpé Dart.
Si Google qui est le champion du tout web, a jugé utile de proposer un langage alternatif à Javascript, cela veut bien dire qu'il estime que Javascript est trop limité pour le developpement d'applications puissantes.

Javascript n'a pas été conçu pour ça, mais on pousse ses limites chaque jour. Si Internet Explorer n'existait pas, je suis sûr qu'on pourrait avancer bien plus vite pour justement améliorer significativement JS ou un autre langage pour avoir bien plus de puissance à notre disposition.

Enfin, un dernier mot.

Je pense que le Développement Web dans le but de remplacer certaines applications métiers à de l'avenir.

Avantages :
- Multiplateforme d'origine, que la machine soit sous Windows (toute version), Linux, Mac, Solaris, ou je ne sais quoi encore
- Aucun travail de déploiement à faire (aussi bien initial que de mise à jour), il suffit d'un accès à l'intranet

Inconvénients :
- Internet Explorer est le boulet du Développement Web. Si la dernière version se rapproche un peu de ce qui se fait chez les concurrents, les autres versions hantent les développeurs Web.
- Performances très inférieures
- Certaines limitations qui peuvent être gênant suivant les applications (notamment pas d'accès au système de fichier)

Pour les applis métiers qui étaient légères, cela me semble parfait.

Evidemment pour des applications plus lourdes, qui ont besoin de puissance, etc, le développement applicatif restera irremplaçable, surtout pour le code natif.

C'est donc amené à se développer, c'est évident. A faire disparaître le développement applicatif, certes non. On a des processeurs très puissants, et on trouvera toujours de quoi se servir de cette puissance sans forcément la gaspiller par du pseudo-code comme Javascript, ou même Java et .NET.
Avatar de gilwath gilwath - Membre confirmé https://www.developpez.com
le 09/11/2011 à 22:46
Une belle news à troll. Je pense qu'il faut retenir de la news, c'est l'arrivé du combo javascript/html5 dans nos applications hors "web browser", et en générale une multiplication des usages du javascript ( dans son mode "natif" ou avec des syntaxe de type coffee & dart ) que ce soit du coté client ou du coté serveur.
Avatar de DonQuiche DonQuiche - Expert confirmé https://www.developpez.com
le 09/11/2011 à 23:03
Citation Envoyé par Chuck_Norris  Voir le message
Donc en gros tu me prends pour une personne sans principe qui ne pense qu'à l'argent ?

Non, cela se voulait simplement un trait d'humour.
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Architecte électronique de puissance expérimenté H/F
Safran - Ile de France - Villaroche - Réau
Chef projet big data - pse flotte H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil