Publicité
+ Répondre à la discussion
Page 1 sur 5 12345 DernièreDernière
Affichage des résultats 1 à 20 sur 82
  1. #1
    Membre actif
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 193
    Points
    193

    Par défaut Le client riche : Quelles technologies ont un avenir ?

    Bonjour à tous,

    J'aimerais amorcer un échange autour d'un sujet à la mode et dans le fond très intéressant: le client riche.

    Le "client riche" se définit le mieux à travers l'objectif qu'il vise: offrir à une application l'ergonomie du "client lourd" tout en conservant la facilité de déploiement/maintenance du "client léger".

    Des langages comme le PHP, l'ASP et le JSP permettent de générer des pages HTML et ainsi de construire des "applications web" exploitable côté client à travers un interpréteur HTML, autrement dit un navigateur basique. Ceci constitue pour moi le modèle "client léger". Le HTML est le seul language compris côté client.

    Le langage Javascript vient alors s'intégrer au navigateur (le client léger devient donc légèrement plus riche), lui permettant de faire autre chose que de restituer le code HTML envoyé par le serveur. Sa combinaison avec le formalisme XML aboutit à l'AJAX qui a permis de voir naître des applications web légèrement plus ergonomiques avec du drag&drop par exemple comme nouvelle fonctionnalité. Là encore, le navigateur est suffisant. Mais il s'agit d'un navigateur enrichi. On peut encore y ajouter le Flash Player ou la Java Virtual Machine et on obtient un client pas si léger que ça.

    Pour aller plus loin, il faut avoir un langage de script plus riche que le Javascript couplé avec un langage de description d'interface graphique plus complet que le HTML voir extensible. Adobe par exemple propose Flex qui couple ActionScript et MXML. Microsoft propose Silverlight qui interprète du XAML mais le language de script reste le Javascript. Mozilla intègre lui XUL directement dans le navigateur Firefox et la suite applicative SeaMonkey, mais là encore le langage de script reste Javascript.

    Toutes ces nouvelles solutions restent à l'intérieur du navigateur mais tend à s'en désolidariser. Adobe Integrated Runtime (AIR) est une machine virtuelle permettant de faire fonctionner des clients riches en dehors du navigateur, mais tout en utilisant ActionScript et MXML. Mozilla proposera bientôt XULRunner, machine virtuelle permettant d'interpréter XUL en dehors de Firefox ou SeaMonkey qui à termes devrait elles mêmes être des applications tournant sur XULRunner.

    Il s'agit là de modèles de développements d'applications web riche, c'est-à-dire ne pouvant plus s'exécuter sur un navigateur basique. La discussion que j'essaye d'amorcer tenterait de déterminer objectivement quel est le modèle le plus complet.

    Au fil de mes lectures, il m'apparait que le modèle proposé par Sun et résumé sous le nom JavaFX est le plus prometteur. Avec J2EE, la technologie Java est bien éprouvée en termes de "client léger". Avec JavaFX, Sun vise à compléter sa Java Virtual Machine pour enrichir le client.

    En ce qui concerne le développement, le code du langage JavaFX script est limpide et est appuyé par la Javadoc. Des plug-ins sont proposés pour les IDE Netbeans et Eclipse, et Sun offrira bientôt un outil non encore nommé destiné aux designers d'interfaces graphiques.

    Le couple J2EE/JavaFX me semble répondre de façon complète à l'objectif du client riche (cf. plus haut).

    Qu'en pensez-vous?

  2. #2
    Expert Confirmé Sénior Avatar de Médinoc
    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2005
    Messages
    23 817
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : septembre 2005
    Messages : 23 817
    Points : 31 660
    Points
    31 660

    Par défaut

    Pour moi, dès que ça dépasse le niveau "Javascript" (exemple: du Flash ou une applet Java), c'est déjà un client lourd.
    SVP, pas de questions techniques par MP. Surtout si je ne vous ai jamais parlé avant.

    "Aw, come on, who would be so stupid as to insert a cast to make an error go away without actually fixing the error?"
    Apparently everyone.
    -- Raymond Chen.
    Traduction obligatoire: "Oh, voyons, qui serait assez stupide pour mettre un cast pour faire disparaitre un message d'erreur sans vraiment corriger l'erreur?" - Apparemment, tout le monde. -- Raymond Chen.

  3. #3
    Membre actif
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 193
    Points
    193

    Par défaut

    Je serais tenté d'être encore plus extrême en affirmant que dès que Javascript est utilisé, ce n'est plus du client léger. Par exemple, GMail propose une version "basic HTML" afin de fonctionner sur le plus basique des navigateurs. Je suis donc tout à fait d'accord avec toi sur ce point.

    Pour qu'il y ait enrichissement du "client léger", il faut qu'il y ait des moteurs supplémentaires installés côté client, par exemple Silverlight de Microsoft qui est un plug-in à installer sur le navigateur ou XulRunner qui est une machine virtuelle à installer sur l'O.S. Les futurs versions du navigateur Firefox seront construites sur XULRunner, donc j'imagine que l'intégration de cette machine dans ce navigateur sera implicite (pas de plug-in à installer).

    Pensez-vous qu'il soit nécessaire qu'un navigateur intègre de base l'ensemble des différents moteurs existants à ce jour, sans qu'il y ait d'installation de plug-in à effectuer? Cela impliquerait la présence de tous les moteurs sur le client, ce qui me semble assez lourd (c'est le mot...).

    Je crois qu'une entreprise, avant de développer son application web riche, sera contraint de choisir un des moteurs côté client et son pendant côté serveur, et c'est bien pour cela que je me demande quelle est la technologie qui vous semble la plus complète dans le domaine bourgeonnant des application web riches.

    Avez-vous déjà développé une application web riche reposant sur Abode AIR par exemple?

  4. #4
    Rédacteur/Modérateur
    Avatar de _Mac_
    Inscrit en
    août 2005
    Messages
    9 407
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 9 407
    Points : 10 952
    Points
    10 952

    Par défaut

    Pour ce qui est du client web qui intègre tous les moteurs, ça n'a aucun : comment tu fais pour intégrer un nouveau moteur ou une nouvelle version de moteur ? Sans parler du fait que les éditeurs vont refuser d'intégrer les moteurs des concurrents (tu devines à qui je fais allusion).

    Pour info, Eclipse propose une version "moteur seul" de l'IDE qui permet justement de développer ses propres applications, par exemple des applications utilisant massivement les Web services, ce qui fait de lui aussi un candidat au client riche, quelque part.

    Par goût, j'aurais une tendance pour JavaFX, mais l'inconvénient majeur de la solution reste le déploiement sur le poste client : il faut quand même installer un programme pour que ça fonctionne, donc c'est pas top de ce côté-là. Et a mon sens, c'est bien tout le problème.

    En ce qui concerne les fonctionnalités, je pense que tout le monde est conscient des limitations du modèle actuel HTML + JavaScript (+ Ajax, pour faire tendance). Tous les nouveaux frameworks de client riche qui apparaissent intègrent des fonctionnalités avancées, qu'on peut pratiquement retrouver d'un moteur à l'autre, qu'on ne peut pas retrouver avec un navigateur standard.

    Je résumerais donc la problématique par rapport à cette question : quel est le modèle de déploiement des clients riches ? 2 solutions s'offrent à nous :
    - Si une entreprise ne veut rien installer sur les postes client, on est obligé de passer par un client léger (navigateur Web standardisé dans l'entreprise) qui fera de l'Ajax, dans les limites de ce dernier, ou qui installera éventuellement des plug-ins genre ActiveX, mais qui utilisera du coup certainement des technologies propriétaires.
    - Si une entreprise accepte d'installer un programme sur le poste client, là tu as effectivement le choix entre les différents éditeurs. Pourvu 2 choses : que la solution de l'éditeur propose un déploiement "centralisé" de l'application (i.e. l'application ne réside pas directement sur le poste client, seulement le moteur), et que la mise à jour du moteur installé sur le PC soit possible et de manière la plus automatisée et transparente possible.

    Mais sinon, j'aime bien Java, j'en fait depuis des années. Les applets, c'est plutôt pas mal, même si c'est assez boudé, et Java Web Start, c'est excellent aussi, mais ça prend pas. Pour moi, c'est le modèle de déploiement le plus intéressant (et qui à son époque, avait bien de l'avance sur ses concurrents). Je pense que Sun veut donner un coup de boost à cette solution avec JavaFX.

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  5. #5
    Membre actif
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 193
    Points
    193

    Par défaut

    Exactement. L'entreprise a bien le choix entre 2 stratégies:

    1 - Aucune installation côté client (en dehors du navigateur qui est fourni le plus souvent avec l'O.S.): stratégie client léger.

    2 - Installation côté client: stratégie client riche.

    J'ai évoqué un navigateur qui serait capable de faire fonctionner tous les moteurs en pensant qu'une entreprise pourrait le choisir comme navigateur standard qu'il incluerait dans le package d'installation de tous ses postes clients. Mais cette idée est assez farfelue, se situe un peu au milieu des 2 stratégies, et un tel navigateur serait finalement une sorte d'IDE (sans les possibilités de programmation) comme Eclipse effectivement.

    Mettons de côté cette idée pour nous concentrer sur la stratégie n°2: déployer et faire évoluer un client riche sur tous les postes de travail.

    Je trouve ton idée de "déploiment centralisé" (uniquement le moteur installé sur le poste client, pas l'application) très intéressante parce qu'elle permet de réaliser la mise à jour de l'application uniquement sur le serveur (gain de temps, gain d'argent). Mais techniquement, je ne suis pas sûr de savoir comment cela fonctionne. Imaginons que le poste client dispose simplement d'un lanceur pour démarrer l'application. Ce lanceur se charge d'établir la connexion avec le serveur pour amener l'application du serveur vers le client. A sa fermeture, l'application se décharge du poste client. Est-ce bien cela que "Java Web Start" et Applets permettent de faire depuis des lustres?!

    Voilà pourquoi je suis plus attiré par JavaFX que par les autres solutions de client riche. J'ai l'impression que tout est déjà là: un moteur qui se met à jour automatiquement (la Java Virtual Machine) et le lanceur (Java Web Start). Tu as raison, en termes de déploiement et mise à jour d'une application, c'est particulièrement élégant et adhère parfaitement à la philosophie des applications web! Donc JavaFX viendrait enrichir le moteur de nouvelles fonctionnalités "orientées client riche" afin que le développeur (ou même le designer) puisse créer plus rapidement une application web riche.

    Mais pourquoi JavaFX n'arrivera qu'au second trimestre 2008? Rajouter des fonctionnalités "orientées client riche" à un moteur déjà existant ne m'apparait pas comme une tâche particulièrement difficile pour des informaticiens aussi talentueux. Je pense (ou plutôt j'espère) que Sun profite de l'occasion pour améliorer son moteur sur d'autres aspects pour donner un vrai coup de boost comme tu dis à la solution Java côté client.

    _Mac_, toi qui travailles avec Java côté client depuis des années, quels sont selon toi les défauts qui l'handicapent aujourd'hui et comment JavaFX (je parle de cette sorte d'upgrade dont va profiter la JVM, pas simplement du langage JavaFX script) pourrait rectifier le tir?

  6. #6
    Rédacteur/Modérateur
    Avatar de _Mac_
    Inscrit en
    août 2005
    Messages
    9 407
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 9 407
    Points : 10 952
    Points
    10 952

    Par défaut

    Oui, Java Web Start est une sorte de lanceur d'application distantes : il télécharge l'application au besoin.

    Pour JavaFX, je ne sais plus trop pourquoi Sun met du temps à le sortir. J'ai lu un papier sur lemondeinformatique.fr je crois, du gourou Java chez Sun et qui expliquait les enjeux de JavaFX. Malheureusement, je ne saurais trop t'expliquer les tenants et les aboutissants. Sinon, on a dû mal se comprendre : je travaille surtout côté serveur

    Pour ce qui est de la stratégie n°1, je ne l'excluerais pas totalement pour 3 raisons :
    - Les évolutions des techno Web. Certes, c'est (très) lent à se mettre en place mais le W3C travaille sur des versions plus évoluées de HTML. On peut s'attendre à des enrichissements conséquents sur les prochaines versions avec, pourquoi pas, des fonctionnalités avancées permettant le développement d'IHM évoluées faciles à mettre en oeuvre et sans la lourdeur d'Ajax.
    - Les fonctionnalités propriétaires : de ce que j'ai compris, Microsoft surtout, un peu moins Mozilla, travaillent justement sur des versions "maison" de langages de type XML pour le développement d'applications riches fonctionnant dans le navigateur. C'est un peu batard, on ne sait pas trop dire si c'est de la stratégie 1 ou 2, mais ça a l'avantage de ne nécessité qu'un navigateur. L'idée, je pense, c'est qu'à un moment donné, le W3C intègre ce genre de technologies pour normaliser un langage standard de développement d'applications riches.
    - EDIT : j'ai oublié la 3ème raison

    EDIT : c'est pas lemondeinformatique.fr, mais 01net : http://www.01net.com/editorial/36321...-aujourd-hui-/

    Du détail, du détail, du détail !!!
    Revenons à la source : lisons la documentation et les fichiers de trace, la réponse à notre problème s'y trouve sans doute

  7. #7
    Membre actif
    Inscrit en
    janvier 2007
    Messages
    205
    Détails du profil
    Informations forums :
    Inscription : janvier 2007
    Messages : 205
    Points : 193
    Points
    193

    Par défaut

    Pas de méprise, j'ai bien compris que tu travaillais côté serveur .

    J'avais également lu l'interview de James Gosling sur 01net (il y avait effectivement eu un podcast d'une interview précédente sur lemondeinformatique.com à l'occasion du Sun Tech Days en mars) et c'est elle qui a réellement éveillée mon intérêt pour JavaFX. En mars, je ne voyais ça que comme un langage de script supplémentaire, mais il s'agit en fait d'un upgrade significatif de la JVM.

    Je n'exclus pas non plus la stratégie 1 et je pense aussi qu'un jour peut-être le W3C finalisera un nouveau langage qui simplefiera la syntaxe et offrira des nouvelles possibilités dans la description d'une interface graphique.

    Cela pour moi rejoint l'objectif des langages de description comme XUL de Mozilla, XAML de Microsoft ou encore MXML d'Adobe. Offrir un moyen de décrire de façon plus complète et plus souple une interface graphique (je pense notamment au XBL chez Mozilla qui permet de créer ses propres éléments d'interface pour étendre ce que propose XUL de base).

    Mais cela reste de la description, non? Cela ne permettra pas par exemple d'interagir avec l'environnement du poste client. Je m'amusais tout à l'heure à charger quelques photos sur Facebook en utilisant Firefox. Pour uploader des photos, l'application web intégrée dans Facebook doit avoir accès à l'arborescence des fichiers de mon poste de travail, et là, c'est la JVM qui se met en route...

    Comment un langage de description, aussi riche et souple soit-il pourra permettre à un navigateur d'interagir avec l'environnement client? A moins qu'en plus de ce langage, le W3C définisse un moteur standard à intégrer dans le navigateur.

    Franchement, quelles différences y a-t-il entre:
    - upgrader le navigateur de tous les postes clients pour passer au super navigateur homologué W3C,
    - installer sur tous les postes clients le moteur et lanceur nécessaires pour faire fonctionner une application web riche?

    Pour moi, les deux solutions se rejoignent. L'amélioration du navigateur nous fait déjà quitter la stratégie 1 pour la stratégie 2. Sur ce sujet, je me suis déjà fait mon avis: dans le cadre d'une entreprise, le navigateur doit rester basique et ne doit pas permettre d'interagir avec l'environnement client, ne serait-ce que pour des raisons de sécurité.

    A côté de cela, le couple moteur/lanceur pour accueillir les applications web riches de l'entreprise. C'est tellement plus propre ainsi!



    Maintenant, je me pose la question suivante. On parle de plus en plus de travail en mode déconnecté, permettant à l'utilisateur de manipuler l'application web riche lorsqu'il n'a pas accès au réseau de l'entreprise. Prenons l'exemple d'une application comme Google Docs et supposons que l'utilisateur veuille travailler son spreadsheet Google sans être connecté à Internet. Pour moi, il n'y a pas d'autre choix que de faire une copie du fichier sur le poste client qu'il faudra ensuite synchroniser avec le fichier du même nom sur le serveur. Des logiciels de messagerie comme Lotus Notes mettent en oeuvre des mécanismes de synchronisation des mails. J'ai aussi eu l'occasion de travailler avec l'application Siebel CRM gérant des portefeuilles clientèle. Cette application propose un mode "offline" avec mécanisme de synchronisation de son portefeuille clientèle.

    Ca ne me semble pas être un truc très simple à implémenter. Est-ce que quelqu'un l'a déjà expérimenté avec Adobe AIR ou Java?

  8. #8
    Membre du Club Avatar de eracius
    Inscrit en
    décembre 2004
    Messages
    132
    Détails du profil
    Informations personnelles :
    Âge : 31

    Informations forums :
    Inscription : décembre 2004
    Messages : 132
    Points : 44
    Points
    44

    Par défaut

    Citation Envoyé par yphilogene Voir le message
    On parle de plus en plus de travail en mode déconnecté
    C'est marrant j'avais personnellement l'impression que l'idée d'un logiciel fonctionnant en offline était complètement HasBeen ...
    Sous l'impulsion de google qui justement nous propose un environnement en ligne toujours plus riche, êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?

  9. #9
    Membre confirmé
    Inscrit en
    février 2006
    Messages
    235
    Détails du profil
    Informations forums :
    Inscription : février 2006
    Messages : 235
    Points : 239
    Points
    239

    Par défaut CAML

    Sinon y a les 'XBAP' du coté de microsoft qui permet de faire tourner une applic en tant que .exe ou bien la lancé via un navigateur (IE ou bien Firefox et quelques consort).

  10. #10
    Membre actif

    Homme Profil pro Roland Krebs
    Développeur informatique
    Inscrit en
    avril 2007
    Messages
    36
    Détails du profil
    Informations personnelles :
    Nom : Homme Roland Krebs
    Localisation : France, Moselle (Lorraine)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Associations - ONG

    Informations forums :
    Inscription : avril 2007
    Messages : 36
    Points : 163
    Points
    163

    Par défaut

    Citation Envoyé par eracius Voir le message
    offline [...] complètement HasBeen ...
    êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?
    Les logiciels fonctionnant en mode déconnecté restent indispensables pour les pc nomades par exemple, dont le nombre ne cesse de croître.

  11. #11
    Membre du Club
    Inscrit en
    mars 2005
    Messages
    54
    Détails du profil
    Informations forums :
    Inscription : mars 2005
    Messages : 54
    Points : 53
    Points
    53

    Par défaut

    Citation Envoyé par erca57 Voir le message
    Les logiciels fonctionnant en mode déconnecté restent indispensables pour les pc nomades par exemple, dont le nombre ne cesse de croître.
    Les points Wifi aussi

  12. #12
    Modérateur

    Inscrit en
    août 2006
    Messages
    3 075
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 3 075
    Points : 3 353
    Points
    3 353

    Par défaut

    La théorie du client léger qui ne nécessite aucune installation ne m'a jamais convaincu. En effet, deux navigateurs différents (IE, Firefox) ne réagissent pas toujours de la manière face au même code, mais c'est le cas aussi pour deux navigateurs identiques dans des version différentes (IE 6, IE5.5), donc au final on est très loin du code html soit disant interprétable par n'importe quel navigateur.
    Si à cela, on rajoute javascript, le problème s'accentue encore.

    Du coup, je trouve que des solutions comme Java WebStart, même si elles ne sont pas parfaites, sont trop souvent négligées. La mise à jour de l'application se fait automatiquement par téléchargement sur le serveur.
    Ok, on peut être amené à mettre à jour la JVM sur le poste client si l'application doit utiliser de nouvelle fonctionnalités propres à une JVM plus récente.

    Au final, je dirais que selon les besoins, on peut choisir l'un ou l'autre et qu'il n'y pas de solution meilleure que l'autre.

  13. #13
    Membre éclairé
    Inscrit en
    août 2006
    Messages
    404
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 404
    Points : 353
    Points
    353

    Par défaut

    Citation Envoyé par yphilogene Voir le message
    Microsoft propose Silverlight qui interprète du XAML mais le language de script reste le Javascript.
    pour la version 1.0 d'accord, mais pour la v 1.1 Silverlight couple XAML et C# avec un framework allégé.

    Mosco

  14. #14
    Membre du Club
    Inscrit en
    août 2004
    Messages
    61
    Détails du profil
    Informations forums :
    Inscription : août 2004
    Messages : 61
    Points : 42
    Points
    42

    Par défaut

    coucou à tous,

    Moi perso j'utilise PHP et javascript, pour l'interface riche, la bibliotheque YUI (Yahoo User Interface) qui a encore quelques bugs mais qui dans l'ensemble est très correcte. Donc cette solution evite de devoir mettre en place une startegie de mise à jour des moteurs xyz coté client.

    Pour les solutions adobe, microsoft et autre, je pense que le match sera remporté par celui qui sera le plus innovant et qui appliquera la meilleur strategie marketing.

  15. #15
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 703
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 703
    Points : 5 639
    Points
    5 639

    Par défaut

    Citation Envoyé par eracius Voir le message
    C'est marrant j'avais personnellement l'impression que l'idée d'un logiciel fonctionnant en offline était complètement HasBeen ...
    Sous l'impulsion de google qui justement nous propose un environnement en ligne toujours plus riche, êtes vous vraiment sûr que le mode déconnecté représente vraiment encore un quelconque intérêt ?
    L'enjeu, c'est de faire des applications qui vont pouvoir fonctionner en ligne ET hors ligne. Un exemple : On pourrait facilement imaginer un traitement de texte qui fonctionnerait en ligne, comme Google Documents, mais qu'on pourrait aussi utiliser hors ligne. L'application sauvegarderait alors le travail en local et se synchroniserait toute seule avec le serveur dès que le réseau serait à nouveau disponible.

    En dehors de ça, c'est sûr, JavaFX, et plus généralement les nouvelles évolutions de Java 7, c'est prometteur. Mais ce qui est annoncé pour l'instant est trop incomplet : JavaFX Script permettra la réalisation d'interface graphique et Java 7 intégrera le système de librairies modulaires permettant de démarrer une application et en particulier une applet beaucoup plus vite. Mais il manque encore plein de fonctionnalités pour rivaliser efficacement avec Flash : gestion du multimedia, et notamment du streaming, video et audio (Cortado, c'est trop limité), affichage vectoriel (même s'il semblerait que des choses soient prévues dans ce domaine avec JavaFX. Il y a deja un convertisseur SVG-JavaFX qui existe, je crois), moteur de rendu HTML (il y a un projet appellé Flying Saucer sur java.net, mais je ne sais pas s'il est prévu de l'intégrer à JavaFX)
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

  16. #16
    Expert Confirmé
    Homme Profil pro Geek forever
    Chef de projet NTIC
    Inscrit en
    septembre 2006
    Messages
    2 897
    Détails du profil
    Informations personnelles :
    Nom : Homme Geek forever
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : septembre 2006
    Messages : 2 897
    Points : 3 552
    Points
    3 552

    Par défaut

    Bonjour

    A titre professionnel, je développe depuis presque 10 ans que des applications
    "déconnecté"...

    Et pour la question n'est pas de savoir, client Leger / client lourd mais plutot de savoir si on developpe des applications qui s'execute sur une machine avec eventuellement connection (si dispo) sur le net, ou si on developpe des applications hébergés dans un browser et qui donc sont "pour l'instant" assez lié au fait que la connection internet, intranet, etc.. (bref du reseau) est disponible...

    Au vue des dev que l'on fait dans ma société (Cap gemini Sud ouest), j'aurais
    tendance à dire que la tendance, justement, est au "massivement" web

    Et j'aime autant vous dire que je suis très triste de cela ...

    Personnellement, je trouve qu'il est bcp plus facile d'avoir une application
    stand-alone performante, chatoyante, rapide avec les fonctionnalités qu'on aime (undo /redo, copy paste, drag & drop (depuis OU on veut) que lorsque j'ai pu approcher des dev en asp.Net

    Apres, souvent, on me sort comme argument : LE DEPLOIEMENT

    JE suis d'accord que deployer une application (.Net pour mon cas en étant expert) est , pour une grande partie de nos clients (grands comptes) une
    problématique forte.. En effet, ces clients sont "fatigués" d'avoir à installer
    sur 10000 Postes des mises à jour word, etc... (bon, maintenant, ce se fait automatiquement quand la machine se connecte et non plus le serveur qui cherche les machines pour les mettre à jour)...

    Avec le web, on simplifie grandement ces aspects

    Cela dit, avec le deploiement Click Once (un exemple sympa étant Paint.Net), on peut tout à fait se retrouver dans des modes d'utilisation assez proche
    de ceux du web... avec l'avantage de pouvoir exploiter son logiciel meme si on est completement Hors Reseau

    Parce que pour moi, d'un point de vue stratégie et sécurité, plus il y a de reseau, et plus il y a de risque de blocage...

    Le jour ou tout le reseau est par terre, si on a un Word via Web => nické
    Et identique pour le reste

    Et de plus, plein d'application n'ont pas besoin d'etre "distribué" et par ailleurs requiert des performances de traitement que l'on n'a pas encore atteint coté web (quelque soit le client)

    En clair, je comprends l'attrait du web , mais pour moi, si le developpement d'application "stand alone" ou pouvant etre deconnecté se marginalise, je pense qu'on aura fait une grosse regression dans le monde de l'informatique

    The Monz, Toulouse

  17. #17
    En attente de confirmation mail

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

    Informations forums :
    Inscription : juillet 2006
    Messages : 766
    Points : 984
    Points
    984

    Par défaut

    Citation Envoyé par Médinoc Voir le message
    Pour moi, dès que ça dépasse le niveau "Javascript" (exemple: du Flash ou une applet Java), c'est déjà un client lourd.
    Pour moi le principal soucis dans l'"expérience utilisateur" , c'est le temps de latence quand il fait appel à un client riche en flash ou plus encore pour une applet Java.
    Faut dire que le lancement de la machine virtuel, et les bugs qu'il occasionne sur Firefox quand l'applet est mal détruite sont assez casse-pied.

    Comme souvent, Sun est à deux doigts de la solution -améliorer le lancement après avoir considérablement améliorer les performances - et va se perdre dans une sémantique marketing incompréhensible, avec sans doute d'excellentes solutions techniques.

  18. #18
    Rédacteur
    Avatar de lunatix
    Homme Profil pro julien
    Architecte technique
    Inscrit en
    novembre 2002
    Messages
    1 946
    Détails du profil
    Informations personnelles :
    Nom : Homme julien
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte technique

    Informations forums :
    Inscription : novembre 2002
    Messages : 1 946
    Points : 3 072
    Points
    3 072

    Par défaut

    essaye la JRE qui arrive (update 6) voir le blog de la section java pour le lien. démarrage instantané de la jvm

  19. #19
    Membre Expert
    Inscrit en
    août 2005
    Messages
    1 109
    Détails du profil
    Informations forums :
    Inscription : août 2005
    Messages : 1 109
    Points : 1 147
    Points
    1 147

    Par défaut

    Bonjour theMonz31
    tu pourrais dire en quoi ce serait une régression si on abandonnait les logiciels en stand ou déconnectés?

  20. #20
    Expert Confirmé Sénior

    Inscrit en
    décembre 2003
    Messages
    2 703
    Détails du profil
    Informations forums :
    Inscription : décembre 2003
    Messages : 2 703
    Points : 5 639
    Points
    5 639

    Par défaut

    Sinon, dans le projet sur lequel je travaille (en ligne sur kizoa.fr), on utilise Flex et bientôt Air. Bon, je m'occupe de la partie serveur, en Java, donc mon expérience de Flex est limitée.
    Ca a le mérite d'être mûr, contrairement à Silverlight ou JavaFX, mais je trouve ça peu performant (et c'est un euphémisme) et franchement gourmand, tant en mémoire qu'en CPU. Quand on a testé la première fois l'application sur MacOS X/Safari, ça faisait peur tellement c'était lent...
    Sans parler des problèmes de compatibilité entre les versions de Flash : le plug-in Linux pour Flash 9 marche vraiment très mal (impossible de faire tourner notre appli Flex dessus, par exemple) et Flash 9 embarque 2 runtimes d'execution Actionscript distincts, pour AS2 et AS3. C'est un peu bancal, comme manière de fonctionner, je trouve. J'ai peur qu'Adobe ne prenne plein les dents quand Microsoft et Sun débarqueront vraiment sur le marché...
    Les brevets ? Le type qui a inventé l'eau chaude doit être grave blindé de thunes !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •