everwind a écrit :
Alors je vais t'expliquer:
- authentification : en Suède, tout site officiel nécessite une authentification double facteur via une application, dont la version Windows Phone ne marche plus depuis 2 mois et ne marchera plus jamais. Résultat : impossible de me connecter à un site officiel ou à mes banques.
- services ayant juste des applis : j'ai besoin d'une appli pour un service de taxi collectif pour aller à l'aeroport, dispo uniquement android / iOS. Donc je ne peux pas utiliser le service. La seule alternative c'est d'utiliser les taxis normaux qui sont 60% plus cher, et 120% plus chers la nuit. Beaucoup de gens ont aussi besoin d'applis pour le boulot ou des services qu'ils utilisent et aucun service web n'est disponible.
|
Si les éditeurs en question avaient prévu des applications web (ce qui n'empêche pas de proposer des applications natives pour autant), on serait typiquement dans le cas où elles auraient pu du coup être utilisées indépendamment de l'OS... te permettant de ne pas te retrouver bloqué. Tes exemples illustrent donc justement mon propos principal (=> quel est l'intérêt de se limiter à développer des app natives dépendantes d'une plateforme donnée lorsqu'il est aussi possible de développer une version multiplateforme).
Il est cependant possible que certaines contraintes empêchant le recours à une app web ne me sautent pas aux yeux dans ces exemples :
- peut-être que le générateur de code pour l'authentification à double facteur s'appuie sur des calculs faisant appel à des fonctions de hachage ou d'autres technos non disponibles en langage web ; l'OS en soit pourrait mettre à dispo des API répondant à de tels besoins si leurs éditeurs faisaient le choix de supporter vraiment les outils web.
- l'appli de taxi collectif, je n'imagine par contre pas là de suite de contrainte qui nécessite absolument de ne pouvoir proposer qu'une application native.
Dans tes exemples, si je mets à ta place, je me pose donc une question : est-ce que j'aurais préféré avoir une alternative web, quand bien même serait-elle plus lente, quand bien même consommerait-elle plus de batterie, plutôt que de ne pas avoir d'appli du tout (taxi collectif) ou une appli qui ne fonctionne et ne fonctionnera plus (authentification double facteur) ?
everwind a écrit :
(...) sous Windows Phone j'ai JAMAIS vu ca (...) Les onglets se ferment et prennent un temps fou à se restaurer
|
Bref, tout ce qui fait référence en fait spécifiquement à Windows Phone/Mobile et à Edge.
Ce n'était sans doute pas clair dans mon message, mais je ne ciblais pas uniquement la plateforme Windows Mobile (et ses divers renommages) concernant le débat web / natif ; je parlais des OS smartphones en général (d'où le fait que j'ai par exemple plusieurs fois cité l'iphone), puisque l'intérêt majeur de l'utilisation des technologies web (soit sites, soit app) serait justement la prise en charge multi-plateformes.
Donc, je mets déjà totalement de côté tout ce qui est évoqué concernant les onglets et leur rechargement intempestif : c'est un problème lié à Edge pour Windows Mobile, pas aux technologies web (et bien heureusement).
Ensuite, je ne limite donc pas l'expérience des applications web à Windows Mobile, où apparemment une application web s'ouvre obligatoirement dans un nouvel onglet d'Edge.
Prends iOS, le fait d'épingler un site web permet d'obtenir le "comportement" d'une app native si le développeur du site web l'a spécifié : fenêtre dédiée, pas de barre d'adresse, multitâche avec les scripts de l'application web qui continuent à tourner quand elle est en arrière plan ; cela n'ouvre pas Safari en soit (même si le moteur est évidemment utilisé), on a la même sensation que celle d'une app "native", cela tourne sur un processus distinct. C'est ce modèle que j'ai en tête quand je parle d'applications web, pas celui d'un nouvel onglet.
Donc si on se limite à Windows Phone, je peux comprendre certaines réticences fonctionnelles en l'état (je n'aimerais pas avoir à jongler entre 30 onglets non plus sur mobile).
everwind a écrit :
Et pour ta liste :
- Notifs : quels sites le gèrent aujourd'hui ? le fait que ce soit techniquement possible (et encore, sous Windows Phone j'ai JAMAIS vu ca) ne veut pas dire que c'est implémenté. PLein de standards du web ne sont jamais utilisés ni implémentés.
- Widgets : comment on peut avoir une tuile dynamique (j'imagine que c'était ce que tu voulais dire) avec un site web ? jamais vu.
- Accéléromètre, gyroscope : donne un exemple de site web qui permettrait de faire l'équivalent d'une appli de suivi de balades / footing.
- Caméra (photo / vidéo) et microphone / chat / visio : essaye d'utiliser une appli de VOIP via le web sur un windows phone et reviens nous dire que c'est pareil qu'une appli. Ca n'a juste rien à voir.
- Bases de données locales : Si tu fais référence à localStorage, c'est une technologie horrible à utiliser et ne remplace pas DU TOUT une base de données.
- Lecture / écriture fichiers locaux : quel site web a accès à tes fichiers ou peut écrire sur le disque, en dehors de localStorage / sessionsStorage ?
- Accès au GPS, géolocalisation : les sites ont accès sans soucis, mais une appli utilisera BEAUOUCP moins de batterie et pas de problème pour y revenir. Bonne chance pour essayer de suivre un guidage GPS via le web ...
- Appels : cf mon point sur la visio, l'experience n'a rien à voir avec une vraie appli
- Bluetooth : jamais vu de site utilisant le bluetooth
De manière générale, le fait qu'une solution soit en théorie techniquement possible ne veut pas dire qu'elle est pratique ni utilisée. Tu listes plein de trucs, mais en vrai s'il n'y aucun bon service les utilisant ça ne sert à rien.
|
Pour répondre déjà de manière globale : mon propos n'était pas d'avancer que toute cette liste était effectivement utilisée, d'autant plus que j'ai bien précisé que certaines fonctionnalités étaient encore en développement (ex. NFC) ou n'étaient pas supportées par tous les navigateurs (ex. Bluetooth : Chrome (Opéra ?) uniquement).
Il s'agissait de répondre aux affirmations précédentes quant au fait que de telles fonctionnalités ne sont pas gérables par un navigateur : c'est faux, la majorité le sont déjà de façon effective.
Oui, elles ne sont quasi pas utilisées par les développeurs des sites, je suis tout à fait d'accord avec ce point ; c'est justement ce que je déplore => on ne se pose pas la question, on développe directement une application native, alors qu'on pourrait aussi penser à une version web qui fonctionnerait partout. Donc je ne vais évidemment pas donner des exemples d'utilisation qui n'existent souvent pas ou trop peu.
Ensuite, dire que la technologie web correspondante existe ne veut pas dire que je pense systématiquement qu'il faille absolument l'utiliser à la place d'une native, il s'agissait juste de corriger une affirmation inexacte. La visio existe en techno web, je pense pourtant personnellement qu'une app Skype native reste cependant préférable (mais n'empêche pas pour autant l'existence d'une version web donc... qui peut être utilisée sur un autre système pour laquelle il n'y a pas d'application native Skype).
Pour te répondre plus précisément à présent sur les différents points :
- Notifs / tuiles dynamiques : pour Windows Phone, il s'agit de l'extension de ce qui avait été mis en place pour les "sites épinglés" Windows 7, donc en gros les balises ms-application et directives dérivées. Les tuiles dynamiques se configurent de la même façon. Encore une fois, les outils existent, mais je regrette justement qu'ils ne soient pas utilisés (ne serait ce que pour la simple création d'icônes à la "apple-touch-icon" même si là l'adoption a été plus forte que pour les balises tuiles dynamiques / notifs).
- Widgets : je parlais bien de widgets, car encore une fois je n'avais pas spécialement Windows Phone en tête (puisque les widgets n'existent pas sous Windows Phone de toute façon). Les widgets ne sont évidemment pas nés avec les smartphones : ceux apparus avec je crois Windows Vista, les widgets Yahoo, Applicast, les widgets pour les téléphones i-mode (même si ça n'a pas dû faire le chemin jusqu'en France)... Ces exemples reposaient sur des couples html/javascript, et couvraient déjà le fonctionnement standard d'un widget actuel (requêtes locales ou distantes => affichage sous une forme donnée à l'utilisateur et interactions associées). Simple question de choix, supporter directement les widgets de ce type (puisque cela existait déjà) aurait pu unifier les développements : développement d'un widget standard, installation possible sur tous les smartphones. On a privilégié le natif, ce n'est pas pour autant que ce n'est pas possible techniquement.
- Accéléromètre, gyroscope : encore une fois, mets de côté le problème de rechargement / onglet spécifique à Edge : rien n'empêche le suivi de balades / footing (même si peut-être donc bémol sur l'autonomie).
- Visio : J'ai testé la fonctionnalité WebRTC sur un tel Archos Androïd bas de gamme au niveau caractéristiques techniques avec Chome mobile pour une conversation entre 3 personnes, pour le coup ça ne rame pas, contrairement aux applis de visio qui y sont installées. Je ne peux pas tester sur Windows Phone, mon téléphone n'étant pas en Insider et la prise en charge du WebRTC n'étant prévue que pour la Creator Update. Mais si ça rame spécifiquement sur Windows Phone, ce n'est donc pas la technologie WebRTC qui en cause mais la plateforme, puisque ça fonctionne nickel sur un Androïd bas de gamme.
- Bases de données locales : j'avais plutôt en tête des API telles que Indexed Database ou Web SQL Database qui sont quand même plus adaptées à cet usage.
- Lecture / écriture fichiers locaux : localStorage / sessionsStorage accessibles à tous en l'état oui, mais des API javascript existent telles que tout le namespace Windows.Storage pour Windows Phone par exemple qui permet d’accéder à tous les répertoires consultables par l'utilisateur et à la carte SD ; l'accès est cependant artificiellement restreint à l'intégration au sein d'une app native, c'est ce que je trouve regrettable (c'est quand même plus pratique que du localStorage). Je ne sais pas ce qu'il en est côté Apple et Google donc je ne vais pas me prononcer pour ces plateformes. Mais ce n'est donc pas une limite technique de facto.
- GPS : l'utilisation du GPS est énergivore de façon générale, même les GPS "autonomes" y sont confrontés (mieux vaut avoir un allume-cigare) ; si tu avances que l'appel à l'API web correspondante consomme plus qu'un appel à l'API système, je suis cependant disposé à te croire. Mais si c'est à cause de l'histoire de rechargement des onglets ou de la non disponibilité éventuelle quand en arrière-plan, ce n'est encore une fois pas l'API web qui est en cause, mais Edge lui-même.
- Appels : j'ai distingué de la visio car je parlais juste de la fonctionnalité permettant de lancer un appel standard depuis du web, ce qui existe depuis (au moins) l'i-mode.
- Bluetooth : je contredisais juste les propos disant que ça ne pourrait pas être dispo sur navigateur ; j'ai bien précisé par contre qu'il n'y avait actuellement qu'un navigateur en gros qui prenait en charge la techno (il doit bien y avoir un site au fond du web qui en fait la démo, je ne vois pas l'intérêt de partir à sa recherche par contre).
everwind a écrit :
En plus ton commentaire sur le fait que les API sont différentes pour le web et les applis, c'est normal et ca ne changera pas. Un site web ne DOIT PAS avoir le même genre d'accès qu'une application, pour la simple raison que l'application a été vérifiée pour arriver sur le store et que tu as accepté ses conditions alors qu'un site tu débarques juste dessus et personne ne peut te garantir que ce n'est pas un gros malware venant te piquer tes données.
|
Je parlais pour le coup spécifiquement de l'UWP, et disais exactement le contraire : les API sont identiques. Il s'agit d'un blocage arbitraire dans leur appel, Microsoft en autorise l'appel en javascript depuis une app native, mais pas en dehors.
J'ai cité les contacts, les sms, le calendrier, le listing des appels.
Je ne vois pas tellement de différences personnellement entre autoriser l'accès pour une app de lampe de poche à mes contacts (ou sms, etc.) et autoriser l'accès à ces mêmes contacts / sms par une application web ; dans les deux cas, le but peut être de me piquer mes données : c'est à l'utilisateur de faire preuve de jugeote pour l'une comme l'autre des utilisations, car aucun des stores ne contraint actuellement une application native à se limiter aux demandes réellement utiles pour son bon fonctionnement (c'est même un festival de demandes hors-propos pour beaucoup d'applis gratuites chez Android).
Le développeur coche les cases pour les demandes qu'il souhaite effectuer auprès de l'utilisateur, même si ça n'a pas spécialement de rapport avec le but annoncé de l'app, l'application demande ensuite l’autorisation à l'utilisateur qui garde officiellement le dernier mot. C'est le même principe en web : géolocalisation, accès caméra, notifs... demandent actuellement l'autorisation à l'utilisateur avant que l'accès soit effectif. Si les API contacts, sms, étaient utilisables, on imagine le même genre d'autorisations que celles actuellement en place pour la géolocalisation ou la webcam, il n'est pas plus question de faire de l'open bar ; l'utilisateur est autant averti que pour une app native.
Au niveau sécurité, les cloisonnements sont ensuite les mêmes tant que l'appareil n'est pas rooté : le navigateur ou une web app n'aura pas plus accès aux fichiers systèmes qu'une appli du store.
Bien sûr, les stores actuels proposent par contre l'avantage de centraliser la disponibilité : rien n'empêche d'y inclure des apps web (qui pourraient pour le coup passer le scan sommaire de sécurité des validations store).
everwind a écrit :
Les web app c'est bien joli mais on ne peut PAS faire quelque chose d'aussi performant et stable qu'une application. Les onglets se ferment et prennent un temps fou à se restaurer, les API sont chaotiques et pas toujours supportées, la batterie est beaucoup plus sollicitée qu'une app bien codée etc.
|
Stabilité : heureusement qu'il est tout de même possible de développer des web app stables, cf. celles disponibles sur les chromebooks.
Onglets qui se ferment etc. : c'est à nouveau une vision biaisée par le comportement d'Edge Mobile. Pour rappel : pas d'onglet dans une vraie prise en charge d'une web app, on est sur un processus distinct. Ça plante ? La fenêtre se ferme. Comme pour une appli native qui plante donc (ce qui arrive de temps à autres, sur Windows, sur iOS, sur Android...).
API chaotiques : pas vraiment plus que celles du code "natif", c'est plutôt le manque ponctuel de constance des éditeurs qui est à mettre en cause, avec des fonctions dépréciées, retours modifiés, etc. On retrouve cela dans énormément de technos d'une version à l'autre... notamment chez les 3 systèmes précités. Ce n'est en rien spécifiques aux technos web.
Supportées : Question encore de choix des éditeurs d'OS, qui privilégient le natif. Il ne tient qu'à eux de supporter ce qui est à disposition. Et une fois que c'est supporté, il appartient aux éditeurs d'apps de les utiliser. Comme les deux parties semblent plus ou moins indifférentes, ce n'est pas supporté bien vite évidemment, voire abandonné.
Performance / batterie beaucoup plus sollicitée qu'une app bien codée : ça tombe effectivement sous le sens qu'une appli "bien codée" consommera moins / sera plus performante qu'une appli "mal codée" Mais j'imagine que j'extrapole ton propos, et que tu voulais plutôt dire qu'une app web bien codée consommera plus et restera moins performante qu'une appli native bien codée. Je te l'accorde dans l'absolu, mais c'est sûr que si on ne cherche de toute façon pas à optimiser la chose côté OS, ça ne risque pas de s'améliorer. Et c'est aussi faire l'impasse sur le fait que dans le cas d'Android, ce que j'appelle "application native" peut aussi faire finalement référence à des applications basées sur Java (donc on n'est pas sur les performances / consommations du natif non plus). Google a certes bien amélioré la chose depuis plusieurs années, mais une optimisation similaire aurait pu être faite côté prise en charge des applications web ; c'est une nouvelle fois une question de choix directionnels.
everwind a écrit :
Ce n'est pas de la fainéantise ou une volonté de surfacturer. Beaucoup de sites laissent tomber leurs apps récemment mais pour autant l'experience mobile reste très en dessous d'une vraie app, sauf à avoir un portable de compétition. Je code des applications web et c'est toujours fou de voir à quel point un téléphone standard est lent par rapport à ce qu'on peut penser. Un site mobile en Ember/Angular/React/VueJS même bien optimisé peut ramer sur un mobile milieu de gamme en ce moment quand on commence à avoir pas mal de fonctionnalités. ´Je peste toujours avec mon téléphone sur les temps de chargement et les sauts dans la page lors du chargement parce que juste parser JS prends parfois plus de 200ms !
|
Je te rejoins sur la faiblesse actuelle sur les temps de chargement, etc. Mais déjà, tu ne pourras pas nier qu'un des plus gros problèmes du web actuel question performances, ce sont les dizaines et dizaines de scripts de suivis publicitaires ou assimilés qui pourrissent les chargements de pages. C'est problématique sur mobile, c'est aussi visible sur un ordinateur de bureau peu performant. Donc oui, en l'état, cela pourrait être aussi un sacré frein. Mais si on part véritablement sur des web app, il faut évidemment faire le choix de se débarrasser autant que possible de ces éléments parasites pour gagner en performance, c'est évident. Ajoute le même nombre de conneries à une app native, tu perdras aussi pas mal en performance... J'utilise deux / trois applis sur iPhone qui sont de bons exemples de cette perte de performance.
Ensuite, dans le cadre d'un développement web app, il y a quand même bon nombre d'applications de bases qui n'auraient aucun intérêt profond à s'imposer l'utilisation des frameworks que tu listes. Ce serait un peu comme tous ces développeurs qui utilisent WordPress pour au final produire un site de 5 pages, pour caricaturer. Si tu prends le problème de la disponibilité des applications sur Windows Phone, en dehors des jeux et de quelques grands noms manquants (Google, Snapchat...), la pénurie est surtout visible côté app basiques pour les évènementiels, musées, institutions, communication avec des objets, etc. où le Windows Store est quasi toujours délaissé. Ce genre d'apps n'aurait pas spécialement besoin de sortir la grosse artillerie des frameworks pour produire une app web fonctionnelle.
Et je ciblais justement ce type d'applications quand je disais "je ne comprends pas non plus l'intérêt de la majorité des app à l'heure actuelle".
Restent par contre des cas où donc oui, la lourdeur de ces frameworks demeure indispensable. Même réponse, aux éditeurs d'OS d'améliorer les perfs déjà, ce n'est pas comme si le web lui-même était d'une utilisation toute marginale, tout le monde aurait à y gagner, puisque la navigation web en général sur mobile sur des sites tout à fait classiques gagnerait aussi en réactivité par ricochet. Mais regretter l'indifférence quant à une bonne prise en charge d'applications web qui remplaceraient avantageusement beaucoup d'applications natives actuelles ne revient pas à souhaiter la mort de toutes les applications natives pour autant. D'autant plus quand les performances sont cruciales (et je re-cite l'exemple le plus parlant, les jeux).
Concernant la sur-facturation, c'était évidemment une pique périphérique, mais faisant un petit tour d'agence de dev en agence de dev dans le cadre professionnel, je confirme tout de même que ça réjouit bon nombre de commerciaux qui y travaillent ces développements / mises à jours pour des plateformes distinctes. Comme à la belle époque pour eux de la forte distinction site desktop / site mobile qui permettait de facturer deux projets distincts, alors que dans les faits, le développement de la version mobile n'était qu'une extension du développement principal, qui ne représentait absolument pas le même volume de travail, puisque toutes les les bases avaient déjà été posées par le développement bureau.
Message édité par loicbg le 19-03-2017 à 16:02:11