GRATUIT

Vos offres d'emploi informatique

Développeurs, chefs de projets, ingénieurs, informaticiens
Postez gratuitement vos offres d'emploi ici visibles par 4 000 000 de visiteurs uniques par mois

emploi.developpez.com

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

Le , par lunatix, Rédacteur
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de UNi[FR] UNi[FR] - Membre confirmé http://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.
Avatar de richie_himself richie_himself - Membre à l'essai http://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.
Avatar de alband85 alband85 - Membre éclairé http://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.
Avatar de benwit benwit - Rédacteur http://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.
Avatar de blbird blbird - Membre éclairé http://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.
Avatar de erca57 erca57 - Membre habitué http://www.developpez.com
le 25/08/2009 à 9:02
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) ?
Avatar de yoyo88 yoyo88 - Membre expérimenté http://www.developpez.com
le 25/08/2009 à 9:06
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.
Avatar de nicorama nicorama - En attente de confirmation mail http://www.developpez.com
le 25/08/2009 à 9:19
Citation Envoyé par lunatix  Voir le message
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à ?????
Avatar de benwit benwit - Rédacteur http://www.developpez.com
le 25/08/2009 à 9:48
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.
Avatar de arno31 arno31 - Membre régulier http://www.developpez.com
le 25/08/2009 à 18:26
Super l'intitulé du sondage : "Votre avis"
Avatar de gronobo gronobo - Membre à l'essai http://www.developpez.com
le 07/01/2011 à 12:28
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
Offres d'emploi IT
Developpeur web LAMP (H/F)
Experts-recrutement - Provence Alpes Côte d'Azur - Sophia-Antipolis
Chef de projets web h/f
1000MERCIS - Ile de France - Paris (75000)
Ingénieur concepteur web (h/p)
Atos Technology Services - Ile de France - Bezons (95870)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique Développement Web : Xavier Lecomte -