Discussion :

[mnaulet]

Bonjour,
Je pose une question très générale,
Quels sont selon vous, les différents avantages ou inconvénients à faire une application web ou une application native.
Aujourd'hui avec le html5 ou des frameworks tels que sencha, on peut faire des application très dynamiques se rapprochant des application natives (Qt, WPF).
Quelles pourraient être les limites d'une application utilisant les technologies web ?
Quelles pourraient être les avantages à développer une application native (sous windows 8 par exemple ?

[gangsoleil]

Bonjour,

Je n'ai aucune confiance dans les technologies web en matiere d'acces a mes donnees. En ce sens, pour tout ce qui est acces aux fichiers, je prefere de tres tres loin une application native.

Apres, tu parles de limites, et je ne pense pas qu'il subsiste des limites a ce que peuvent faire les applications natives ou web aujourd'hui.

[rmaker]

Bonjour,
Je pose une question très générale,
Quels sont selon vous, les différents avantages ou inconvénients à faire une application web ou une application native.
Aujourd'hui avec le html5 ou des frameworks tels que sencha, on peut faire des application très dynamiques se rapprochant des application natives (Qt, WPF).
Quelles pourraient être les limites d'une application utilisant les technologies web ?
Quelles pourraient être les avantages à développer une application native (sous windows 8 par exemple ?

Pour ta question, ça dépend du nombre d'utilisateurs et de là où est située la base de données. Si tu fais une appli pour toi, ou juste des potes, pas de souci, prend du client lourd. Ta question est beaucoup plus subtile quand tu as plein d'utilisateurs qui tapent la même base, ou la même source de données.

Et dans ce cas, le problème du client lourd, c'est de gérer des tas d'aspects que tu n'as pas à gérer en faisant du web. Je pense à la concurrence, au multithreading, à tenir la charge pour ton client lourd. Tout cela est bien géré par un serveur d'application. Au final, pour moi, la différence ce n'est pas le rendu. Cà, effectivement, avec les frameworks que tu mentionnes, le résultat doit être super. Le problème, c'est de faire une application robuste, qui gère bien tout ce que te cache un serveur d'application tel que JBoss ou Weblogic (pour les javaistes)

[nnovic]

Je ne suis pas partisan des applications sur le web. Les désavantages que je vois:

1/ Comment fais tu en HTML5 pour piloter le driver d'un périphérique (usb, par exemple) ?

2/ Si l'application web est hébergée chez l'éditeur, tu ne peux pas t'opposer aux évolutions de l'application web. Ca peut poser de gros problèmes aux entreprises qui, une fois qu'une version précise de l'application est approuvée, veulent pouvoir maîtriser le déploiement des évolutions de cette application.

3/ Est-ce qu'une application web est réellement efficace pour traiter des gros calculs et/ou des gros fichiers ? Convertir un fichier .wav en mp3 ? Convertir un .avi en .mp4 ? J'ai des doutes...

[rmaker]

Je ne suis pas d'accord avec toi. Ou plus exactement, les arguments que tu apportes ne me semblent pas valides.

1/ Comment fais tu en HTML5 pour piloter le driver d'un périphérique (usb, par exemple) ?

C'est impossible, mais ce n'est pas le but d'une appli web. De même, coder un facebook en C et en natif serait complètement aberrant. Ce n'est pas la même finalité.

3/ Est-ce qu'une application web est réellement efficace pour traiter des gros calculs et/ou des gros fichiers ? Convertir un fichier .wav en mp3 ? Convertir un .avi en .mp4 ? J'ai des doutes...

En fait, on peut répondre oui. Via le client web, tu soumets juste l'ordre de conversion ou de gros calculs. Si derrière, le serveur est hyper puissant, cela peut aller très vite, et tu peux avoir la réponse (presque) immédiatement.

2/ Si l'application web est hébergée chez l'éditeur, tu ne peux pas t'opposer aux évolutions de l'application web. Ca peut poser de gros problèmes aux entreprises qui, une fois qu'une version précise de l'application est approuvée, veulent pouvoir maîtriser le déploiement des évolutions de cette application.

Si le client natif est développé chez l'éditeur, tu ne peux pas non plus trop lui dire que tu veux ça ou ça. Au pire, tu ne changes pas de version. Evidemment, avec un logiciel libre et natif, tu peux déja faire beaucoup plus de trucs. Mais c'est plus rare.

[nnovic]

C'est impossible, mais ce n'est pas le but d'une appli web. De même, coder un facebook en C et en natif serait complètement aberrant. Ce n'est pas la même finalité.

La question initiale ne précise pas la finalité de l'application, ce qui laisse penser qu'on pourrait tout faire avec l'un et l'autre. Or, je suis bien d'accord avec toi, ce n'est pas le cas. La comparaison n'a de sens que pour certaines applications, par exemple orientées bases de données.

En fait, on peut répondre oui. Via le client web, tu soumets juste l'ordre de conversion ou de gros calculs. Si derrière, le serveur est hyper puissant, cela peut aller très vite, et tu peux avoir la réponse (presque) immédiatement.

Je ne suis pas convaincu. Si on prend en considération le temps de transfert des données du client vers le serveur, et vice-versa, je pense que l'application web a un handicap.

[wiztricks]

Salut,
Côté richesse de l'interface graphique, il n'y a plus trop de différences.

• Client/Serveur = 2 Tiers = accès direct à la BDD par N clients.
• Serveur Web = 3 Tiers = Presentation sur le client, application dérrière le serveur HTTP qui accède à la BDD le moins souvent possible. En gros, le serveur construit dynamiquement (ou pas) des pages et les expédie au(x) client(s)

Application Web est une variante du modèle 3 tiers dans lequel le dialogue entre serveur applicatif et clients n'est plus "page" mais "requête dynamique" de mise à jour d'un champ de ce qui est affiché.

Poussons le modèle pour avoir le "métier" de l'application présentée sous forme de Web services REST (des services HTTP).

On peut alors faire une présentation HTML5/CSS/Javascript qui "attaque" les services métiers via http et une application GUI classique qui fasse la même chose. La différence entre les deux sera la mise à jour des clients: elle est quasi transparente avec HTML5/..., elle devra être organisée via un repository pour des applications "classique" - qui sont déployées pour les applications "mobiles" -.

Si nombre de client et interactivité de l'IHM ne sont plus des critères "structurants" pour faire un choix, il faut voir application par application sans se fermer une migration opportuniste de l'un à l'autre.
Il est généralement plus simple de faire un proto avec un GUI "classique" ne serait ce que parce que cela réduit le nombre de compétences à trouver.
Une fois qu'on sait ce qu'on veut on peut HTMLisée tout ou partie.

- W