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 |
