Discussion :

[lunatix]

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

[entreprise38]

Salut,

tu confonds clients lourd et léger

l'évolution des navigateurs ne les fait pas évoluer vers des clients lourds : ils continuent à se résumer à de l'affichage, tout le gros des traitements (calculs, travail sur des fichiers, etc) restant sur le serveur.

Bref, on risque peut être de voir aparaître une sorte d'hybride genre : client léger + quelques fonctionnalités d'un client lourd, cad des capacités d'affichage plus poussées (3D, GUI plus riche, etc), mais c'est tout.
Un client lourd restera un client lourd, et les navigateurs ne sont pas prêts de prendre leur place.

Néanmoins, ce qu'on pourrait éventuellement voir, c'est :
- un client lourd installé sur le poste
- auquel on connecte (on l'AJOUTE à coté du client lourd) le navigateur en tant qu'interface graphique pour ledit client lourd.
Bref : client lourd + client léger pour l'affichage.
Mais j'y crois pas, car pour cela on préfère directement intégrer un moteur de rendu, comme c'est le cas depuis belle lurette pour MediaCoder, utilisant le moteur de Firefox (mais ce n'est QUE le moteur, et il est intégré).

[lunatix]

non, je ne confonds pas, je dis juste que les deux types d'applications vont devenir tres proches

[yoyo88]

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 )

[vintz72]

Moi je pense au contraire que les clients lourds n'ont plus beaucoup de beaux jours devant eux. Pour reprendre l'exemple du client mail, je préfère bien souvent désormais utiliser les web mails qu'un client pop3. Le projet sur lequel je travaille actuellement (en Swing) aurait bien pu être fait en client web, bien plus rapidement et avec des effets graphiques plus modernes (avec du JQuery par exemple)...
En outre, les nouveautés d'HTML5 comme le stockage local permet d'envisager le mode déconnecté (avec synchro quand on revient de balade). Donc clairement, dans 5-10 ans, les projets en clients lourds se compteront sur les doigts !

[nicorama]

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

[robert_trudel]

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...

[lunatix]

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

[UNi[FR]]

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.

[richie_himself]

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.

[alband85]

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.

[benwit]

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.

[blbird]

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.

[erca57]

J'ai essayé plusieurs fois d'utiliser le moteur d'un navigateur pour construire l'interface-utilisateurs d'une application. Chaque fois j'ai calé devant la complexité de la mise en oeuvre, et je me suis finalement rabattu sur mon EDI préféré.
Je misais beaucoup sur XUL ou XAML. Mais pour les raisons ci-dessus, et faute de documentation concise et précise, je n'ai jamais rien réalisé. Quelqu'un connaît-il un exemple de réalisation bien documenté avec XUL (ou, mieux, un tutoriel) ?

[yoyo88]

le truc c'est que, comme je les dit plus haut, beaucoup on tendance a croire qu'une appli web et la solution a tous les problèmes rencontrer par les client lourd. (installation, centralisation des données ext...)

comme benwit le souligne il existe la solution du client dit "riche" (bien que pour moi lourd et riche soit très proche)
perso je croit beaucoup a cette solution qui permet de faire des traitement en local et de déporté certaines fonctions (exemple import/export de données vers base de données global).

Les gros avantages de se type de logiciel est :
_qu'il est indépendant d'un connections réseau.
_qu'il tire partie de la puissance de calcul du post client.
_Application plus "réactive".
_qu'il ne surcharge pas le réseau.
_qu'il peut échanger des information avec un serveur et ainsi déporté certains traitement pour le post client.



En soit il n'y a pas de meilleurs solution... tous dépend du cas de figure. mais le seul type de logiciel capable d'avoir les avantages d'un client riche et du client léger c'est le client "riche". (bien que j'aime pas trop se terme)

lors d'un de mes devellopements, un intervenant externe a essayer de me prouver qu'un client léger était plus adapté à mes besoin alors que j'avais des utilisateurs nomades.

Je pense qu'il faut pas tomber dans l'effet de mode "tous internet". certes y'a des avantages mais il y a aussi des défaut qui sont souvent minimisé.
exemple :
l'unique serveur tombe en panne lors du pique d'utilisation?
Client léger : logiciel impossible a utiliser, course contre la montre pour la maintenance qui avais peut être d'autre problème a gérer...
Client riche : Indisponibilité d'un service, mais on peut toujours continuer à travailler dans de bonne condition.
Client lourd : pas de problème de serveur en panne mais problème d'échange d'information.

[nicorama]

javascript limité ? mal connu peut etre, manquant un peu d'outillage surement, mais limité je ne crois pas.

Pas d'api standard, pas de documentation, pas d'ide, pas typé, pas enseigné à la fac. On peut tout faire avec Javascript, mais ils ont choisit le moins pratique et le moins connu des "illimités".
Mais qu'est-ce qui est passé par la tête de Netscape ce jour-là ?????

[benwit]

En y réfléchissant un peu, il ressort :

1. Interface utilisateur dans l'OS VS Interface utilisateur dans le navigateur
2. Traitements & données locaux VS Traitements & données distants

Aujourd'hui, il existe des applications dans les 4 configurations possibles.

Le point 2 dépend des applications :

• Certaines ont besoin d'être connectés car le volume d'information est tel qu'il ne peut être sur le client : exemple d'un moteur de recherche.
• Certaines stockent les données en lignes pour des commodités d'accès mais peuvent les rapatrier sur le client : exemple des mails, des documents
• Certaines travaillent sur des données locales : exemple des logiciels de gravure.

Le point 1 dépend pour l'instant de la "richesse" graphique, de l'ergonomie de l'interaction.
Aujourd'hui, il est clair que les logiciels dont l'UI tourne nativement dans l'OS sont plus performants mais quand sera t'il demain lorsque le navigateur et l'OS auront tellement fusionné qu'on ne pourra plus les distingués ?

La question n'est pas de savoir où seront effectués les traitements et où stockées les données, il existera toujours les deux
mais de savoir qu'elle est la plateforme applicative de demain :

• L'OS comme aujourd'hui ?
• Le navigateur ? (initialement lecteur générique de documents)
• Des plateformes génériques comme éclipse ?

Les frontières deviennent de plus en plus floues surtout que la frontière entre documents (site web) et application (webapp) est également de plus en plus floue.
Jusqu'à présent, le navigateur semble le plus limité pour les applications (graphisme / disque dur) mais des avancées sont proposées dans les deux directions.

[arno31]

Super l'intitulé du sondage : "Votre avis"

[gronobo]

Je pense que le client léger est en phase de prendre de l'importance. On le voit d'ailleurs avec l'émergence du terme "Cloud Computing" même si 95% des utilisateur lambda ne savent pas ce que c'est. Bref pour moi le client léger n'est pas amené à terme à remplacer le client lourd, sauf dans les application "basiques". Sauf si il permet d'effectuer des traitement directement sur la machine à la manière de NaCl que développe Google (je ne sais plus ou ça en est depuis). Les Clients lourds auront toujours l'avantage de tirer partie de la puissance en local du poste Client. S'en suit une meilleur réactivité, des effets bien plus léché que ce que propose le CSS3 et le javascript pour l'instant. Il ne faut pas oublier également la différence structurelle entre ces 2 approche, l'une est entièrement dépendante du réseau, que l'autre non. Nous verrons bien si ce que je di est inexact avec le lancement de Chrome OS. Voici un article qui explique un peu plus en profondeur les différences entres les différents "Clients" : http://gronoblog.blogspot.com/2011/0...-riche-ou.html