IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Votre avis

Votants
97. Vous ne pouvez pas participer à ce sondage.
  • Oui

    54 55,67%
  • Non

    33 34,02%
  • Autre avis (précisez)

    3 3,09%
  • Sans opinion

    7 7,22%
Actualités Discussion :

le navigateur web : le futur du client lourd ?

  1. #1
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    Novembre 2002
    Messages
    1 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : Novembre 2002
    Messages : 1 960
    Points : 3 736
    Points
    3 736
    Par défaut le navigateur web : le futur du client lourd ?
    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

  2. #2
    Inactif  
    Profil pro
    Inscrit en
    Avril 2008
    Messages
    885
    Détails du profil
    Informations personnelles :
    Âge : 40
    Localisation : France

    Informations forums :
    Inscription : Avril 2008
    Messages : 885
    Points : 1 320
    Points
    1 320
    Par défaut
    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é).

  3. #3
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    Novembre 2002
    Messages
    1 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : Novembre 2002
    Messages : 1 960
    Points : 3 736
    Points
    3 736
    Par défaut
    non, je ne confonds pas, je dis juste que les deux types d'applications vont devenir tres proches

  4. #4
    Membre chevronné

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2009
    Messages
    966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Juillet 2009
    Messages : 966
    Points : 2 078
    Points
    2 078
    Par défaut
    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 )

  5. #5
    Membre averti Avatar de vintz72
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    154
    Détails du profil
    Informations personnelles :
    Âge : 52
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Octobre 2005
    Messages : 154
    Points : 316
    Points
    316
    Par défaut
    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 !

  6. #6
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    Juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Points : 1 267
    Points
    1 267
    Par défaut
    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

  7. #7
    Membre éprouvé
    Inscrit en
    Avril 2006
    Messages
    853
    Détails du profil
    Informations forums :
    Inscription : Avril 2006
    Messages : 853
    Points : 929
    Points
    929
    Par défaut
    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...

  8. #8
    Rédacteur
    Avatar de lunatix
    Homme Profil pro
    Architecte technique
    Inscrit en
    Novembre 2002
    Messages
    1 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : Novembre 2002
    Messages : 1 960
    Points : 3 736
    Points
    3 736
    Par défaut
    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

  9. #9
    Membre averti
    Avatar de UNi[FR]
    Homme Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Juin 2002
    Messages
    340
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Juin 2002
    Messages : 340
    Points : 448
    Points
    448
    Par défaut
    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.

  10. #10
    Membre à l'essai
    Profil pro
    Inscrit en
    Juillet 2009
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2009
    Messages : 12
    Points : 12
    Points
    12
    Par défaut Lourd ou léger ?
    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.

  11. #11
    Membre éclairé
    Homme Profil pro
    Développeur
    Inscrit en
    Juin 2006
    Messages
    645
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Juin 2006
    Messages : 645
    Points : 709
    Points
    709
    Par défaut
    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.

  12. #12
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    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.

  13. #13
    Membre chevronné

    Profil pro
    Conseil - Consultant en systèmes d'information
    Inscrit en
    Février 2004
    Messages
    760
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Conseil - Consultant en systèmes d'information

    Informations forums :
    Inscription : Février 2004
    Messages : 760
    Points : 2 095
    Points
    2 095
    Par défaut
    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.

  14. #14
    Membre actif

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Avril 2007
    Messages
    47
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Avril 2007
    Messages : 47
    Points : 297
    Points
    297
    Par défaut
    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) ?

  15. #15
    Membre chevronné

    Homme Profil pro
    Développeur .NET
    Inscrit en
    Juillet 2009
    Messages
    966
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Juillet 2009
    Messages : 966
    Points : 2 078
    Points
    2 078
    Par défaut
    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.

  16. #16
    En attente de confirmation mail

    Homme Profil pro
    Inscrit en
    Juillet 2006
    Messages
    766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 766
    Points : 1 267
    Points
    1 267
    Par défaut
    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à ?????

  17. #17
    Rédacteur
    Avatar de benwit
    Profil pro
    dev
    Inscrit en
    Septembre 2004
    Messages
    1 676
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : dev

    Informations forums :
    Inscription : Septembre 2004
    Messages : 1 676
    Points : 4 265
    Points
    4 265
    Par défaut
    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.

  18. #18
    Membre habitué
    Profil pro
    Inscrit en
    Octobre 2007
    Messages
    87
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2007
    Messages : 87
    Points : 170
    Points
    170
    Par défaut
    Super l'intitulé du sondage : "Votre avis"

  19. #19
    Membre à l'essai
    Profil pro
    Inscrit en
    Septembre 2010
    Messages
    10
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2010
    Messages : 10
    Points : 22
    Points
    22
    Par défaut
    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

Discussions similaires

  1. Consommation d'un web service par un client lourd
    Par Pico51 dans le forum Services Web
    Réponses: 0
    Dernier message: 11/04/2014, 17h03
  2. Choix d'architecture : client lourd vers appli web
    Par nonoRedDevils dans le forum Frameworks Web
    Réponses: 8
    Dernier message: 21/04/2010, 10h14
  3. Application Client lourd et web
    Par MottetCCSF dans le forum Général Dotnet
    Réponses: 2
    Dernier message: 18/02/2009, 21h35
  4. client lourd en web service
    Par amelA dans le forum Services Web
    Réponses: 4
    Dernier message: 04/04/2007, 21h57
  5. Client lourd java et web service
    Par gs@ab dans le forum Services Web
    Réponses: 6
    Dernier message: 22/11/2006, 18h15

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo