Les applications natives seront-elles remplacées par les applications HTML 5 ?

Les applications natives seront-elles remplacées par les applications HTML 5 ?
La fin du règne des applications natives annoncée pour l’an prochain


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

On pourra peut-être observer un déclin de l'applicatif, mais je doute que tout se fera en une année.

Il ne faut pas non plus oublier que les appli web ont un défaut sur la communication client/serveur, le client doit sans cesse questionner le serveur au lieu d'attendre un signal.

La réponse est non , HTML5 sera un standard pouvant être utiliser pour développer l'interface d'applications native comme dans metro c'est certain. Mais une application Metro ne risque pas de tourner ailleurs que dans métro. ce sont donc des applications natives, comme un plugin Chrome ne tourne pas ailleurs que dans Chrome.
Pour ce qui est du cloud, il faut être connecté pour y accéder , donc la réponse à la question est non.
L'avenir est plutôt au solutions de "cross" compilation. On développe dans un langage et on déploie sur différentes plateformes, web ou natif , comme particle SDK , qui permet de développer en as3 ou en Java et déployer dans flash, java , win32 , XNA , html5 , ios , et android.

De toute manière tant que subsisteront des navigateurs non compatibles ou des navigateurs compatibles mais avec leur propre api, les applications native auront de beaux jours devant elle.

Et puis entre nous à développer des appli basées sur un standard non terminé , y'en a qui vont avoir des suprises ...

Il y a un terme qui me gêne dans la news.
"solutions natives" en parlant de Silverlight et Flash ? Ce n'est pour moi pas le moins du monde natif vu que tout navigateur ne le gère pas de base (nécessité d'un plugin).

Citation:

---

Envoyé par Grimly

Il ne faut pas non plus oublier que les appli web ont un défaut sur la communication client/serveur, le client doit sans cesse questionner le serveur au lieu d'attendre un signal.

---

Ce n'est justement plus le cas en HTML5 grâce aux WebSockets :)

Vu le nombre existant d'applications natives, je doute que le domination du HTML5 se fasse dès l'année prochaine, par contre c'est clairement la tendance actuelle, et outre le choix de Microsoft pour Metro avec Windows 8 et Boot2Gecko de Mozilla, j'ajouterais le récent rachat de PhoneGap par Adobe comme marque de la montée en intérêt du HTML5.

Cet article me fait penser aux deux [autocensuré] qui avaient reçu le prix nobel d'économie en 2000 (juste avant la "dotcom bubble") et qui avaient écrit un livre intitulé "Etes vous prêts pour 20 ans de croissance continue ?".

Pour ma part je m'en retourne coder mes applications natives, je n'ai que jusqu'à la fin de l'année pour les finir vu que l'année prochaine il n'y aura plus que du HTML5 :)

PS le HTML5 commence à avoir le même goût que le cloud ... avec des vrais morceaux de marketing vaseux dedans.

De toute façon, il n'existe pas d'applications non-native indépendante.

Quand on écrit un code Java, on le compile pour qu'il tourne sur une JVM dont l'implémentation est, par essence, native.

Quand on écrit un code Web, on le fait tourner dans un navigateur qui est lui-aussi natif.

On ne fait que déplacer la gestion du natif vers un socle.

Le problème est donc "Aura t'on un socle applicatif dont toutes les implémentations respecteront de façon stricte et identique la norme HTML5 ?"
Ce socle applicatif permettra t'il d'égaler le fonctionnement et la fiabilité d'un progiciel Client/Serveur ou Monoposte ?

Je n'y crois personnellement pas.
Il suffit de voir la variété d'implémentation de la norme ECMA/Javascript.
De plus le web pose des problèmes de performances car là aussi on remplace une logique (traitement lourd local, faible communication) par une autre (traitement local faible, haute communication) et cela ne fait que déplacer les problématiques.

Pour moi, les deux vont coexister encore longtemps.
Quant à la "deadline" d'1 an, c'est juste une élucubration.
Dans le milieu pro on en est encore à migrer des applications en Cobol ou Fortran ...

Citation:

---

Envoyé par transgohan

Il y a un terme qui me gêne dans la news.
"solutions natives" en parlant de Silverlight et Flash ? Ce n'est pour moi pas le moins du monde natif vu que tout navigateur ne le gère pas de base (nécessité d'un plugin).

---

Il n'est pas fait référence à Silverlight ou Flash lors de l'utilisation de ce terme mais bien à des applications natives. C'est la pertinence des plateformes Silverlight et Flash qui est remise en cause face à l'avancée de HTML5.

Pour ce qui est du remplacement du natif l'année prochaine ... ça relève presque du troll si c'est pris au sens littéral, en revanche pris dans le sens ou cela marquera le début de la fin, pourquoi pas, mais certainement pas de façon généralisée.

Il me semble évident que bon nombre de petites applications aujourd'hui écrites avec des SDK natifs vont pouvoir être remplacées par des application web HTML5.

Les clients pour des réseaux sociaux (Twitter, Facebook, LinkedIn) n'ont pas vraiment besoin de socle natif, sauf pour:

- accéder aux notification: pousser du contenu du web vers le terminal n'est (encore?) dans le périmètre d'HTML5.

- l'accès aux ressources physiques du terminal reste un handicap (capture photo, audio, video, accélérometre, gyroscope, NFC...)

- l'intégration à l'environnement natif (agenda, contacts) reste encore à définir.

Par exemple, je défie quiconque de réécrire une application comme GarageBand (iPhone ou iPad) en HTML5.

Même si ce n'est pas très tendance de le dire, je pense que les applications natives ont encore de beaux jours devant elles.

Et aussi un point qui me semble important :

Est-ce que tout le monde pense que javascript est idéal pour les grosses applications? Pour ma part tout ce qui est d'importance non négligeable codé en javascript me donne une impression de fragilité et de maintenabilité hasardeuse.
Je ne me verrais pas personnellement coder des éléments métier sensibles en javascript.

Citation:

---

Envoyé par _skip

Et aussi un point qui me semble important :

Est-ce que tout le monde pense que javascript est idéal pour les grosses applications? Pour ma part tout ce qui est d'importance non négligeable codé en javascript me donne une impression de fragilité et de maintenabilité hasardeuse.
Je ne me verrais pas personnellement coder des éléments métier sensibles en javascript.

---

Sans compté qu'a fonctionnalité égale les app HTML5 demande beaucoup plus de ressource que un client lourd. Sans doute la faute au moteur JS pas encore des plus optimisé , mais quand même.

il est toujours agréable de faire une application standard et ouverte pouvant se déploiyer sous n'importe quel plate forme sans autre forme de procès. c'est en cella que le HTML5 est une véritable avancée et c'est également pour cella qu'il tend à devenir la norme . Mais la question est : est ce qu'on peut faire en HTML5 tout ce qui est fait ou peut être fait avec une application native ? Si oui alors je suis pour qu'on passe au Full HTML5 tout de suite; si par contre c'est pas encore le cas, les deux domaines vont devoir cohabiter un bon moment encore.
;)

Je penses que nous devrions arreter de developper des applications et attendre cette magnifique revolution qu'est HTML5.

C'est vrai, avec toute les nouveautes annonces, les choses incroyable que nous pourrons faire comme par exemple les balises video ou menu, c'est une vrai revolution qui est en marche, rendez-vous compte des menus et des videos accessible a tous, c'est Internet 2.0 qui arrives !

Plus serieusement je suis plus que septique quand je lis ce genre d'article.
Oui c'est bien de creer un standard universel, mais ca s'arrete la.
La preuve etant, pour tester la vrai valeur de HTML5, desactiver javascript, et la on pourra voir ce qu'est vraiment HTML5 (rien du tout donc).

HTML restera un support, sur lequel viendra se greffer d'autres technologies de plus haut niveau, qui pourrons donner acces a de la POO.

La mort des applications en 1 an ? Fort heureusement personne n'est paye pour raconter des choses pareils... Attendons la "sortie officiel" pour voir les revolutions annonces...

Citation:

---

Envoyé par kdmbella

il est toujours agréable de faire une application standard et ouverte pouvant se déploiyer sous n'importe quel plate forme sans autre forme de procès.
;)

---

Pour ce genre d'appli, une plateforme equinox (Eclipse RCP) est tout à fait indiqué.
Au niveau déploiement c'est monstreux : Tu télécharges un zip, tu dézippe c'est prêt !!:mrgreen:

Sinon le RIA Web (JSF, GWT, ...) pour une appli de gestion n'est pas à mon avis un bon choix et mon expérience professionnelle me donne raison pour le moment.

Citation:

---

Envoyé par _skip

Javascript me donne une impression de fragilité et de maintenabilité hasardeuse.
Je ne me verrais pas personnellement coder des éléments métier sensibles en javascript.

---

C'est pas le langage qui fait la qualité du Développement. Il suffit de mettre Java sur un serveur Websphere pour le comprendre :)

Citation:

---

Envoyé par _skip

Est-ce que tout le monde pense que javascript est idéal pour les grosses applications? Pour ma part tout ce qui est d'importance non négligeable codé en javascript me donne une impression de fragilité et de maintenabilité hasardeuse.
Je ne me verrais pas personnellement coder des éléments métier sensibles en javascript.

---

En effet javascript n'est un langage fait à la base pour des grosse application.
Heureusement il existe maintenant des outils comme Coffescript, GWT, Dart, ... qui permettent de ne pas programmer directement en Javascript mais dans des langages plus propres et/ou stricts.
Javascript est en train de devenir une sorte de bytecode pour appli web.

Citation:

---

Envoyé par sgamel

- accéder aux notification: pousser du contenu du web vers le terminal n'est (encore?) dans le périmètre d'HTML5.

- l'accès aux ressources physiques du terminal reste un handicap (capture photo, audio, video, accélérometre, gyroscope, NFC...)

- l'intégration à l'environnement natif (agenda, contacts) reste encore à définir.

---

Ce n'est pas encore au point mais ca viendra très vite, il y a des API qui sont en cours de développement pour presque tout ce moment : son, joystick, caméra, tactile, ...

Citation:

---

Envoyé par nicorama

C'est pas le langage qui fait la qualité du Développement. Il suffit de mettre Java sur un serveur Websphere pour le comprendre :)

---

:ccool: +1
Il faut reconnaître que le Java/Web n'est pas fait pour les applis de production lourdes.
Notamment à cause des communications Ajax incessantes avec le serveur.

En somme, les solutions natives vont disparaître au profit de solutions ayant une productivité plus faible, un tooling inférieur, nécessitant l'ajout de pelletées d'outils et produisant un résultat moindre pour l'utilisateur (performances, langages souples davantage prompts aux bugs) ?
Si mes concurrents pouvaient gober ça... :lol:

Ca se tient toutefois dans le cas d'outils disponibles sur plusieurs plateformes. Ou pour une partie de leur développement.

Citation:

---

Envoyé par nicorama

C'est pas le langage qui fait la qualité du Développement. Il suffit de mettre Java sur un serveur Websphere pour le comprendre :)

---

Oui et non...
On peut dire ce que l'on veut mais pour moi, un langage fortement typé, permettant la détection de toutes les erreurs de syntaxes à la compilation, dont le comportement au runtime est extrêmement homogène et de surcroît accompagné d'une toolchain puissante, ça contribue aussi à la qualité.

En revanche, un code javascript devant être testé exhaustivement sur plein de navigateurs différents (sans compter les versions) et qu'un simple retour à la ligne mal placé peut foutre silencieusement en l'air, ça me pose personnellement plus de problèmes.

J'oblige personne à être d'accord avec ce point de vue mais l'existence de frameworks qui génèrent du (voire se "compilent" en) javascript tels que cités par Uther me fait penser que je ne suis pas le seul à avoir cette petite réticence envers JS.