Vous êtes plutôt application web, hybride ou lourde (native)

Je lance cette discussion dans l'espoir de sonder la tendance des éditeurs, concepteurs de produits logiciels de nos jours.

Je suis partisan "application web", c'est pour cela aussi.

Êtes-vous d'accord avec moi que le web reste incontournable voire la technologie "leader" chez les éditeurs de Silicon Valley?

Il y a une version web à toutes les applications initialement desktop. Il y a une version web à toutes les applications initialement mobiles.
De plus, les navigateurs web (leurs moteurs) sont de plus en plus sophistiqués aujourd'hui.

Skype, Slack, Whatsapp ... tous ceux que j'utilise ont une version web et je préfère leurs versions web

Qu'en pensez-vous?

Bonjour,

Ça dépend.

Pour faire une interface utilisateur, oui, c'est globalement mieux d'avoir un front-end de type web : c'est plus léger, et plus facile à maintenir qu'une version lourde. Par contre, pour ce qui est back-end, je ne vois pas l'intérêt.

Je vous recommande chaudement de visionner cette vidéo pour avoir un aperçu de ce que pourrait être le web dans quelques années avec les progressives webapps.

https://www.youtube.com/watch?v=dSKp-76Ur6E

Merci pour cette vidéo

Citation:

---

Par contre, pour ce qui est back-end, je ne vois pas l'intérêt.

---

Beaucoup sont encore réticents à Javascript pour coder le métier d'une application, d'ailleurs même moi. Mais il est question ici de choix sur la forme de vente/publication d'une application: application mobile ou application installée sur Windows ou application web (en ligne) ...

Tant qu'une application n'a pas besoin de beaucoup de resources (icones, scripts, sons, ...) alors je préfère la version web plus légère et toujours à jour.
Sinon quitte à devoir télécharger beaucoup de données, je préfère les avoir sur mon disque dur dans un dossier d'installation que dans les tréfonds du cache du navigateur.
Si l'application fait du calcul un peu lourd, je préfère l'avoir dans un processus à part qu'en tant que nième onglet de mon navigateur au risque de faire planter le tout.

Citation:

---

Envoyé par randriano

Beaucoup sont encore réticents à Javascript pour coder le métier d'une application, d'ailleurs même moi. Mais il est question ici de choix sur la forme de vente/publication d'une application: application mobile ou application installée sur Windows ou application web (en ligne) ...

---

Le métier est toujours codé côté backend, c'est juste l'UI qui est en js. Evidemment pour ceux qui font le backend en nodejs, ils mettent du js partout, mais ça reste 2 couches distinctes, même si c'est le même langage. ;)

Citation:

---

Envoyé par ovh

Le métier est toujours codé côté backend, c'est juste l'UI qui est en js.

---

Une SPA sans du métier dedans ça s'appelle un fichier html. Et encore ...

Citation:

---

Envoyé par Marco46

Une SPA sans du métier dedans ça s'appelle un fichier html. Et encore ...

---

Comprends pas... Ce qui s'affiche dans le navigateur, c'est bien un page html, non ?
Et dans le cadre d'une SPA, si toute l'UI est chargée d'un coup, quel rapport avec le code métier ? La navigation entre les pages, c'est du code métier ??

Citation:

---

Envoyé par nnovic

Comprends pas... Ce qui s'affiche dans le navigateur, c'est bien un page html, non ?
Et dans le cadre d'une SPA, si toute l'UI est chargée d'un coup, quel rapport avec le code métier ? La navigation entre les pages, c'est du code métier ??

---

OK, je me réponds à moi-même. Je viens de lire qu'une SPA a aussi comme particularité de pouvoir s'exécuter en "offline". J'avais manqué ce point.
Du coup, effectivement, ça oblige à mettre tout le code dedans.
Reste que, à mon avis, ce n'est pas envisageable si des données/algos confidentiels sont en jeu. Or, pour moi, le code métier c'est justement ça...

Citation:

---

Envoyé par nnovic

Reste que, à mon avis, ce n'est pas envisageable si des données/algos confidentiels sont en jeu. Or, pour moi, le code métier c'est justement ça...

---

Code métier ne signifie pas obligatoirement confidentialité.

Je vais prendre un exemple classique, la facturation.

Pour des raisons techniques (numérotation des factures), il est absolument impossible d'avoir la logique de facturation implémentée dans la SPA, pourtant l'algo de conversion d'une commande en facture n'a absolument rien de confidentiel. C'est parfaitement trivial. En revanche une facture proformat (qui n'a pas de n° de facture) elle peut parfaitement avoir sa logique implémentée dans la SPA. Cela soulagera d'autant les serveurs et l'utilisateur aura une bien meilleure UX.

Il y a des tonnes de cas où la logique métier n'a pas besoin de d'être confidentielle.

Citation:

---

Envoyé par nnovic

Et dans le cadre d'une SPA, si toute l'UI est chargée d'un coup, quel rapport avec le code métier ? La navigation entre les pages, c'est du code métier ??

---

Ça peut en contenir oui. Avoir le droit d'aller dans telle ou telle vue (et pas page on est dans une SPA il n'y a qu'une seule page) selon tel ou tel critère métier. Ce n'est qu'un exemple, tu appliques la même logique sur des blocs à l'intérieur des vues, sur des champs à l'intérieur des blocs, etc ... Et tu te rends compte que ta SPA elle est absolument blindée de partout de logique métier de partout.

Citation:

---

Envoyé par Marco46

Il y a des tonnes de cas où la logique métier n'a pas besoin de d'être confidentielle.

---

Ok, je comprends ton point de vue. J'ai toujours travaillé dans l'industrie, et là en général on aime bien garder nos petits secrets (ou aussi, on aime bien faire croire qu'on en a!)

Citation:

---

Envoyé par Marco46

Ça peut en contenir oui. Avoir le droit d'aller dans telle ou telle vue (et pas page on est dans une SPA il n'y a qu'une seule page) selon tel ou tel critère métier. Ce n'est qu'un exemple, tu appliques la même logique sur des blocs à l'intérieur des vues, sur des champs à l'intérieur des blocs, etc ... Et tu te rends compte que ta SPA elle est absolument blindée de partout de logique métier de partout.

---

Là par contre je ne suis pas d'accord. Ce dont tu parles, c'est simplement de l'UX.

Citation:

---

Envoyé par randriano

Je suis partisan "application web", c'est pour cela aussi.

Êtes-vous d'accord avec moi que le web reste incontournable voire la technologie "leader" chez les éditeurs de Silicon Valley?

Il y a une version web à toutes les applications initialement desktop. Il y a une version web à toutes les applications initialement mobiles.

---

la question peut-être légitimement posée mais c'est comme le débat mobile vs PC je me vois mal faire tourner un simulator de vol comme FSX ou des logiciels comme 3ds Max dans un navigateur Web :roll:

Citation:

---

Envoyé par nnovic

Là par contre je ne suis pas d'accord. Ce dont tu parles, c'est simplement de l'UX.

---

Afficher le bloc bidule parce que le user a tel rôle et que la valeur de tel champ est supérieure à telle valeur c'est du métier, pas de l'UX.

Si tu préfères c'est pas l'ergo qui va décider des critères d'affichage des blocs, des champs, quand tel ou tel bouton est disabled, c'est le métier qui décide de tout ça. L'ergo lui va faire des propositions de positionnement des éléments dans l'ihm, de savoir si tel bouton il vaut mieux le masquer ou l'afficher disabled, il va proposer d'utiliser tel wording plutôt qu'un autre pour telle ou telle action métier etc ...

Le sujet a quelques temps mais bon, pour revenir à la question :

Citation:

---

Envoyé par randriano

Êtes-vous d'accord avec moi que le web reste incontournable voire la technologie "leader" chez les éditeurs de Silicon Valley?

---

problème : incontournable, oui. Leader…*Non. La remarque

Citation:

---

Il y a une version web à toutes les applications initialement desktop. Il y a une version web à toutes les applications initialement mobiles.

---

manque juste de considérer les différences entre les versions "web" et "mobiles"/"Desktop". Pour la plupart de ces apps 'initialement mobiles', la version web permet d'avoir de la présence, d'être accessible même en dehors du contexte "idéal" de l'app. Et une version web, ça permet d'avoir le service disponible même pour ceux qui n'ont pas l'app. Mais attention, le business n'est pas sur cette version…

Ensuite, il faut rappeler que les préférences personnelles ne font pas les préférences des utilisateurs. Et en fait, la simple question "préférez vous le natif ou le web" passe à coté de la question fondamentale : le service…

Je te prends une anecdote : Voyages-SNCF, lorsqu'ils ont lancé leur première version de l'app mobile en, je crois, 2010, en 3 mois sans pub, elle a cartonnée. Elle a même complètement bouffé la version web pour une simple raison : elle était pensée pour être utilisée sur mobile. Le gars qui l'a eu en charge m'a résumé son ambition (c'est un usex) : commander son billet en 3 taps utilisable au pouce. En d'autres termes, elle était pensée non pas uniquement pour être utilisée sur un mobile mais par des personnes qui manipulent un mobile dans les conditions d'usage du mobile. En théorie cette considération fait que le web peut être considéré comme la techno universelle, mais dans la pratique, pour espérer y prétendre, un développement devrait considérer l'affichage non pas uniquement sous forme de contraintes techniques mais aussi d'usage. C'est le même problème qu'a eu Microsoft en vendant ses "Universal Apps" supposées nécessiter un dev minimum : à dev minimum, interfaces inadaptées…

Reste ensuite toute la question d'intégration à la plate-forme. Que ce soit sur desktop ou mobile, une application native accède à toutes les ressources proposées, et je ne parle pas uniquement des notifications ou la géolocalisation.

Au final, sur desktop, ça peut se discuter, mais sur mobile, je ne connais aucune service dont la version web soit plus pratique que la version app.

Mais au (vrai) final, le juge, c'est l'utilisateur…*Et là j'ai eu une app qui a bouffé des parts sur un concurrent qui ne s'était pas adapté…

Le fait est qu'aujourd'hui, les SDKs des apps mobiles natives sont

Citation:

---

Envoyé par martopioche

Au final, sur desktop, ça peut se discuter, mais sur mobile, je ne connais aucune service dont la version web soit plus pratique que la version app.

---

Justement tu te goures :aie: :aie:

Le problème du desktop, c'est l'installation, la recherche dans un magasin (dont l'importance des notes/ réputation et des mises à jour fréquentes), le partage de son application (qui n'est pas un partage d'URL) et les mises à jour qui sont tributaires de l'installateur

Citation:

---

Envoyé par martopioche

C'est le même problème qu'a eu Microsoft en vendant ses "Universal Apps" supposées nécessiter un dev minimum : à dev minimum, interfaces inadaptées…

---

Ce serait pas plutôt la faute aux développeurs desdites apps, plutôt qu'à Microsoft qui n'a fait que fournir la technologie ? C'est comme affirmer qu'une app Androïd est mauvaise à cause de Google...

L'objectif des Universal Apps c'est justement, dans la même application, de réaliser des interfaces complètement différentes en fonctions des écrans sur lesquels elles s'exécutent.

Débat qui durera un bon moment. Mais à terme, la friction de l'installation de l'app devrait s'effacer. Il ne serait pas étonnant qu'on aie un pré-load des applications automatique permettant d'utiliser les fonctions de base (non natif ?) pendant que le reste de l'appli s'installe. En soit le natif est une pure contrainte pour l'utilisateur, la frontière à vocation à disparaitre.

Je ne découvre l'universal windows apps qu'en lisant ce fil. L'UWP est-il sur la voie de la disparition depuis l'abandon de Windows Phone?

En tout cas, ce fil a été bien répondu par vous tous. Merci

Non, UWP est cross-platform entre Win10 et Xbox également (Xbox play anywhere).