Cette semaine, Benjamin De Cock écrivait sur son blog un article contre les applications web, en faveur des applications natives.
J’ai pris mon actuel écran d’accueil [sur mon iPhone] comme exemple. Combien d’apps serais-je capable de recréer aujourd’hui en ciblant uniquement la dernière version de Safari Mobile et sans sacrifier aucune fonctionnalité ? Indice : aucune.
- Alarme: Oubliez la fonctionnalité la plus utile : l’alarme.
- Calendrier: Les alertes d’événements ne peuvent pas être implémentées.
- Photos: Vous ne pouvez pas stocker 1000 photos et vidéos en cache.
- Appareil photo: Forcément, non.
- Réglages: Vous ne pouvez pas modifier les réglages, évidemment.
- Rappels: Vous ne pouvez pas créer de vrais rappels.
- Reeder: Vous ne pouvez pas partager un article par SMS.
Je ne savais même pas qu’on pouvait partager un article par SMS dans Reeder. Et je ne pense pas qu’utiliser Safari Mobile comme référence de fonctionnalités HTML5 soit très pertinent (au contraire). En théorie, il existe des API HTML5 (en cours d’écriture ou déjà implémentées) pour quasiment toutes les fonctionnalités décrites.
Mais il marque un point : les applications web, on n’y est pas encore tout à fait.
La semaine dernière, Facebook a annoncé la sortie prochaine d’une nouvelle version beaucoup plus rapide de son application iOS, abandonnant HTML5 au profit d’Objective-C.
Mais d’un autre côté, on voit naître actuellement une tripotée de systèmes d’exploitation poussant les applications web : Google et Chrome OS, Mozilla et Firefox OS, Microsoft et l’interface Metro de Windows 8. Alors est-ce cela signifie qu’on va avoir des OS au rabais avec des applications web amputées ? C’est très certainement le cas aujourd’hui (cf. les tests des derniers Chromebooks sur Chrome OS), mais je pense qu’il faut ajouter d’autres arguments dans la balance.
Pour moi, les applications web résolvent deux problèmes de longue date dans l’informatique :
- L’universalité d’une application : En codant en HTML5, en respectant les standards, vous êtes à peu près certains de pouvoir faire tourner votre application sur n’importe quel navigateur et plate-forme compatible. Bien sûr, il y aura toujours des cas particuliers à gérer. Mais comparez ça avec le casse-tête actuel du développement mobile (iOS, Android, Windows Mobile), et ce n’est pas dur de voir l’avantage du web en tant que plate-forme. L’adage de Java se prête plutôt bien (« Write once, run everywhere »), même si sa parodie aussi (« Write once, debug everywhere »).
- La pérennité d’une application : En codant en HTML5 aujourd’hui, il y a de grandes chances que votre application fonctionne encore dans 10 ans sur des appareils et des navigateurs totalement différents. A l’inverse, il y a de grandes chances qu’en choisissant une application native aujourd’hui, la plate-forme sur laquelle elle tourne soit totalement désuète d’ici 10 ans. J’expliquais déjà tout ça il y a quelques semaines en parlant de la rétro-compatibilité.
Alors forcément, en tant qu’intégrateur, mon point de vue est certainement un peu biaisé. Mais je pense que nous sommes dans une période un peu bancale. HTML5 n’est pas encore assez mûr pour permettre de réaliser n’importe quel type d’application de manière aussi performante qu’une application native. Mais développer aujourd’hui une multitude d’applications sur tout autant de plate-formes me semble un choix farfelu.
Bacteries, le
La démo faites du Firefox OS au Web2Day laisse penser qu’au final, une fois les API d’interrogation des fonctionnalités du système faites, il sera possible de faire une appli web & mobile qui a accès à tout (SMS, batterie, contact, caméra, fichiers, …). Le Firefox OS fonctionne déjà, et l’interface est faites en full HTML5.
Du coup l’universalité d’une appli pourrait être possible.
Nico, le
C’est débile comme raisonnement : c’est comme si je comparais une voiture diesel et essence, en disant, « la voiture essence ne tolère pas qu’on mette du diesel dedans ».
Il prend des exemples typiquement natifs (SMS, alerte natives au tél) et dit qu’on ne peut pas les faire en web ! Si Apple utilisait un hardware accessible depuis les web-apps, tout cela serait possible.
Et accessoirement, c’est ridicule sur certains points : une web app avec un serveur qui le permet peut envoyer des SMS par exemple.
Comme tu l’as dit, les web-apps ont un énorme avantage, l’universalité et la compatibilité : j’aimerais bien savoir si les intranets que j’ai codés il y a 7 ans (et qui tournent encore et tourneront encore dans des années) auraient la même durée de vie en apps natives en dépit des évolution des navigateurs.
Loïc, le
Effectivement, si l’on prend le HTML5 seul, comme ça avec des navigateurs pas toujours au top, on peut se dire que les applications natives ont encore de beaux jours devant elles.
Mais il y a maintenant phonegap (http://phonegap.com/), entre autres, qui fourni les api manquantes au HTML5 pour accéder à toutes les fonctionnalités du téléphone (oui, toutes, sans exception!!!). De plus, phonegap package la webapp dans une app native (l’avantage de la mettre sur le market et d’avoir une petite icone sur l’écran d’accueil).
Hormis encore quelques problèmes de performance, il n’y a pas vraiment de différences entre une application native et une web app…
Aucune raison donc de ne pas se mettre au web pour de bon !
Agence web MyWebShop, le
Je suis globalement d’accord avec l’article ainsi que les commentaires ci-dessus. Par contre un point a été négligé… celui du coût desdites technos ;-) Le choix et la différences peuvent aussi se porter sur ce point car n’oublions pas qu’il s’agit du nerf de la guerre :p
yop, le
Facebook et des centaines de milliers d’utilisateurs mettent en cause la rapidité de l’appli. C’est pourquoi ils vont abandonner le html5 pour faire du dev spécifique ios/Android.
C’est un coup dur pour la crédibilité de la techno, mais ça remet sur terre tous les extrémistes et autres trolls .
mich, le
J’apporte mon point de vue de concepteur d’appli professionnelles pour l’agriculture.
Nos applis mobiles sont désormais développées en html5, après avoir fait le constat que développer et sur iOS, et sur Android, et sur Win phone 7 allait nous coûter bien cher. Avant, c’était facile, tout était développé pour Win 6.5.
Nous sommes confrontés à des compatibilité de framework : sensa touch sur Win 7 ne fonctionne pas, tant pis. Le stockage en local pour les zones d’ombre sont très intéressantes pour nous pour saisir directement sur le tracteur
Nous avons fait un compromis entre le coût des développements et notre marché (bien moins grand que celui de facebook), et les fonctionnalités (rapidité entre autres). Et nous avons fait le pari que l’html5 ne pouvait que s’améliorer.