Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le navigateur web est-il le futur du client lourd ?

Le , par lunatix

0PARTAGES

0  0 
Votre avis
Le navigateur comme on le connait aujourdh'ui va-t-il devenir le moteur de rendu universel des applications clients lourds ?

En effet : avec les inclusions de css3-3d-transforms et de CSS Animation dans les futurs navigateurs (cela permet l'animation et la 3D), certains se posent la question de l'utilisation d'un navigateur comme moteur de rendu de bureau.
On peut maintenant grace a ces extension a la norme Css faire a peut pret tout ce que fait un bureau moderne

Quelques démos qui montrent que l'on peut rendre tous les effets de bureaux modernes avec un navigateur sont visibles sur le blog de webkit
ou sur chrome Experiments
Une video qui montre des animation 3D dans safari (via un binding openGL)
snow-stack-is-here

ChromeOs, pour ce qu'on en connait devrait être sur ce modèle, la question se pose pour Gnome, KDE utilise déjà Webkit, Apple l'utilise pour Dashboard et vu le travail qu'ils mènent à marche forcée sur Webkit/Safari, on peut penser qu'ils ont une idée derrière la tête.

Et vous : pensez-vous que le futur de l'interface client lourd soit le client léger ?

Note : la plupart des démos ne fonctionnent qu'avec un navigateur à base de Webkit (safari, ou chrome) et surement bientôt avec Firefox

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de benwit
Rédacteur https://www.developpez.com
Le 24/08/2009 à 17:55
Resituons les mots dans leur contexte.

Historiquement,

Les premières machines étaient imposantes et les utilisateurs se connectaient donc à l'ordinateur central (chargés des traitements) via des terminaux (chargés uniquement de la partie interaction avec l'utilisateur UI).

Puis sont arrivés les PC ...
Dès lors, son rôle ne se limitait pas seulement à une UI mais pouvait faire également des traitements.
Cela a conduit à des applications autonomes (traitement & interface utilisateur sur la même machine) : Jeux, Traitement de texte, tableur, ...

... en réseau local ...
La deuxième étape à consister en une mise en réseau. On pouvait de nouveau s'en servir comme de simples terminaux. Cela a conduit à des applications en deux parties : une partie serveur et une partie cliente (surtout des applications d'entreprise).

... puis mondial (Internet)
Il y a alors une diversité des applications :
  • des programmes "serveur" (juste des traitements)
  • des applications autonomes (UI + traitements)
  • des applications non autonomes (UI + traitements + réseau) : ces hybrides que sont les clients web, mail, ftp,
  • des "clients lourds" (UI + traitements réseau)
  • des "clients terminaux" applicatifs (juste une UI + réseau)


Avec le développement d'internet, on assiste au retour du C/S et se développent des applications web composés de deux parties : la partie serveur qui traite les données et la partie cliente (envoyée au client dans son navigateur) qui permet l'interaction utilisateur.

On se rend alors vite compte que la partie traitement sur le serveur n'a pas beaucoup changée par rapport à l'origine mais que désormais, ces applicatifs serveurs peuvent être appelés de deux façons :
  • soit en passant par un navigateur, on parle alors de client léger
    J'y vois deux sens possibles :
    • les débits initiaux sont lents, il faut donc que le volume de données transférées soit léger.
    • pas d'installation de client applicatif spécifique puisque le navigateur servant de client générique, il faut juste que l'ordinateur dispose d'un navigateur (installation donc légère)

  • soit en passant par un client applicatif dédié.
    Certains le qualifie de client riche car à ce stade, les interfaces des applications tournant sur un OS offrent plus de possibilités que celles tournant sur un navigateur (servant initialement à affiché uniquement des documents/formulaires)
    Certains le qualifie de client lourd par opposition au client léger d'une part, et probablement par ressemblance graphique aux autres applicatifs du PC dont les "clients lourd" (Ce terme est sujet à caution car certains préfèrent réserver ce terme aux applications qui font également du traitement côté client)


Je tenais à clarifier la façon dont je comprend ces termes pour apporter mon point de vue

Si on entend "client lourd" comme "client riche", on tend à une convergence des interfaces puisque les utilisateurs veulent la même ergonomie.
L'utilisation d'un navigateur se rapprochant de plus en plus de celle d'un OS : d'un réceptacle applicatif.
Les nouvelles possibilités évoquées par lunatix tendent vers cela ...

Si on entend par "client lourd" des applications qui font des traitements, un navigateur est il un client lourd ?
Là, j'ai deux points de vues :
  • soit je considère le navigateur comme le socle de mes applications et je dit que c'est un client léger d'une application donnée, il ne sert que d'UI.
  • soit le considère le navigateur comme un applicatif dont le job est de se connecter à des serveurs sur internet et de ramener des documents, et je peux le qualifier de client lourds, au même titre que des clients lourds applicatifs (les deux utilisent le graphisme de l'OS, ont besoin d'être installé sur l'OS ...)

C'est parce que le navigateur est un META-client qu'il peut être qualifier de lourd ou léger selon le niveau où l'on se place.

Pour autant, les choses ne demeurent pas si simple

Pour éviter les ambiguïtés de langage "client lourds" relevées plus haut, je répondrai à la question : Penser vous que l'on vas utiliser de plus en plus des applications à travers son navigateur ?

On y va tout droit :
D'abord AJAX puis Les améliorations graphiques des CSS que tu évoques ... HTML 5
Et on tend également à permettre des traitements "applicatifs" côté client (GWT : traitements en Javascript), et à stocker des données en local (GEARS)
Comme quoi Google Chrome OS était prévu depuis longtemps dans la stratégie de Google.

Microsoft s'y met aussi avec la suite Office bientôt en ligne ...

Est-ce une bonne chose ?
J'ai vu il y a 8 ans des applications PC pilotant des automates d'usines être réécrite en application web , des applications web utilisant des menus accessible à travers une champ texte et des codes (111, 112, ...) parce que dans l'usine, ils n'avaient pas de souris !!!

Tu comprends yoyo88 qu'avec cet exemple extrême, je partage ton avis qu'on ne devrait pas en faire une solution à tout mais que du coup, une suite bureautique en ligne, c'est pas si mal que cela (surtout que dans le cas bureautique, c'est à mon avis plus adapté (travail collaboratif, accès de partout à ses documents, évolution des technos web depuis 9 ans))

Edit : J'ai voté "autre avis", car c'est pas tout blanc ou tout noir. C'est un futur mais pas le futur.
  • Pour la gestion, il faut y aller à fond (surtout si on a des capacités de stockage local, de travail déconnecté)
  • Pour les jeux, oui car c'est collaboratif par essence. Néanmoins, il faudra peut être des traitements locaux pour ne pas ressentir de ralentissements et que les jeux solos non connectés continuent d'exister.
  • Pour des applications plus spécifiques liés à du matériel (robot, automates, ...), je ne crois pas. Que l'automate synchronise des données avec des serveurs, oui mais pas un pilotage total par le web.
4  0 
Avatar de yoyo88
Membre chevronné https://www.developpez.com
Le 24/08/2009 à 16:15
Il ne faut pas oublier que internet n'es pas la solution a tous.
Aujourd'hui on utilise beaucoup internet, cependant certain utilisateurs en sont priver. (exemple : commerciaux) et bien qu'il y ai des possibilité de connections sans fil (wifi ou clef 3g) ses solution ne remplace clairement pas une traditionnel connections ethernet.
(en plus on ne sais même pas l'impacte sur la santé...)

bref t'en que des utilisateurs pourront être priver d'internet les solution de client léger seront discutable.

Je pense, de plus, qu'aujourd'hui vouloir faire tous avec des client léger c'est plus un gros effet de mode. par exemple, Outlook Web Access et un super client léger qui permet de lire ses mails lorsqu'on est pas au boulot. cependant au travail je préfère travailler avec Outlook.

Bref les applis lourdes ont encore de beau jour devant elles.

(je suis le seul a penser sa? ou alors je suis déjà a la ramase )
3  0 
Avatar de lunatix
Rédacteur https://www.developpez.com
Le 21/08/2009 à 14:08
non, je ne confonds pas, je dis juste que les deux types d'applications vont devenir tres proches
0  0 
Avatar de nicorama
En attente de confirmation mail https://www.developpez.com
Le 24/08/2009 à 16:40
Disons que le web permet de faire grâce aux CSS une interface simplement personnalisée, mais souffre toujours de ce langage disons limité qu'est le Javascript
0  0 
Avatar de robert_trudel
Membre éclairé https://www.developpez.com
Le 24/08/2009 à 17:06
avec kde il ya déjà possibilité d'utiliser javascript pour des widget... néanmoins, ça reste beaucoup moins rapide que le faire en C++

je crois pas vraiment que le client lourd disparaitra bientôt...

il y a beaucoup trop d'application qui serait trop pénaliser

jeux, logiciel de gravure, montage vidéo, dessin...

pour des applications de gestions, c'est pas si mal...

de plus il faut penser au fait que la connexion peut se couper et cie... google à gears...
0  0 
Avatar de lunatix
Rédacteur https://www.developpez.com
Le 24/08/2009 à 17:07
javascript limité ? mal connu peut etre, manquant un peu d'outillage surement, mais limité je ne crois pas.

sinon, je parle surtout de l'interface grapqhique : rien n'empeche d'imaginer que les applications locales du futur seront construites sur le modele des applications web actuelles, avec un serveur web/d'applications local et le navigateur en interface.

Opera avec unite semble deja penser a ce genre choses
0  0 
Avatar de UNi[FR]
Membre confirmé https://www.developpez.com
Le 24/08/2009 à 17:12
Je pense que nous tendons (si ce n'est pas déjà le cas) vers un modèle 3 tiers

La vue des applications se fera via un client léger, les process se feront via des applications lourdes et tout cela sera couplé à une base de données.
0  0 
Avatar de richie_himself
Membre à l'essai https://www.developpez.com
Le 24/08/2009 à 17:19
C'est marrant cette tendance à toujours vouloir tout opposer. Telle techno doit-elle nécessairement impliquer la mort de telle autre ?

Moi j'ai travaillé sur des projets où clairement le client léger était plus indiqué et d'autres où c'était le client lourd...

Par contre, ce qui se passe parfois (souvent ?) c'est que cette évidence est niée... et on se retrouve à faire du lourd là où le léger était bien plus adapté et inversement.

Ce sont pas les technos qui sont en cause mais les gens qui les préconisent.
0  0 
Avatar de alband85
Membre éclairé https://www.developpez.com
Le 24/08/2009 à 17:27
Qui dit client léger dit centralisation.

Ca a des avantages dans le sens où il n'y a pas d'intervention à faire sur le poste de l'utilisateur, que la maintenance est simplifiée, que l'appli est accessible depuis n'importe quel poste, etc.

Mais ça pose également de (gros ?) problèmes : le serveur est inaccessible, plus personne ne peux bosser. Tout passe par le réseau : ça a beau être chiffré, il y a toujours moyen de péter le truc, d'intercepter, de brouiller... bref, de nuire.
On peut également parler d'ergonomie, même si ça tend à s'arranger.

Pour moi, un client léger peut convenir à des applis simples, partagées... mais surtout non critiques.
Donc comme souvent dans ce genre de débat : client léger ou client lourd, ça dépend.
0  0 
Avatar de blbird
Membre expérimenté https://www.developpez.com
Le 24/08/2009 à 22:31
J'ai toujours pensé et je continue à penser que les 2 n'ont rien à voir. Par contre, je crois toujours que les clients lourds continueront à évoluer, et permettent bien souvent (surtout en intranet) d'aller beaucoup plus loin qu'un simple navigateur web (même avec ajax et/ou flash, cela importe peu).

En disant ca, je regarde les applications ultra-modulaires, évolutives, du type Eclipse (voir Talend basé sur Eclipse aussi par ex.), qui s'auto-patch, qui ne nécessitent pas d'installation, ni même forcément d'Internet pour fonctionner.

Ca, pour moi, c'est l'avenir des véritables applications, hors de ce fatras de technologies web qui complexifient tout par rapport à du client lourd, sauf la personnalisation de l'interface graphique, entre autres.

P.S. pour les fameux problèmes d'installation, il existe des exemples tellement simples de patch automatiques : Eclipse, tout les jeux MMORPGS, qui tournent la plupart sur différents OS et sur des millions de machines toutes différentes.
0  0