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

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Analyste
    Inscrit en
    juillet 2013
    Messages
    2 408
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Analyste
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 408
    Points : 76 626
    Points
    76 626
    Billets dans le blog
    2
    Par défaut Le projet GNU de Richard Stallman veut se débarrasser de JavaScript non libre envoyé aux navigateurs
    Le projet GNU de Richard Stallman ne veut plus de code JavaScript non libre envoyé aux navigateurs par les sites Web
    et invite des volontaires à créer des extensions libres pour les remplacer

    « De nombreux sites Web portent atteinte à la liberté des utilisateurs en envoyant des programmes JavaScript non libres au navigateur de l'utilisateur. Nous invitons les volontaires à développer des extensions de navigateur libres pour remplacer le JavaScript envoyé par des sites particuliers », peut-on lire sur le site du projet GNU de Richard Stallman.

    Pour Richard Matthew Stallman (RMS), la lutte contre les logiciels propriétaires, encore appelés logiciels privateurs, est l'essence même de sa vie. Depuis le milieu des années 1990, il consacre la majeure partie de son temps à la promotion des logiciels libres tout en dénonçant les privations de liberté qu'imposent, selon lui et son mouvement, les logiciels dits propriétaires.

    C'est dans cette logique que depuis plus d'une décennie, le président de la Free Software Foundation a décidé de s'attaquer au piège JavaScript. En parlant de piège JavaScript, il fait référence au fait que les utilisateurs pourraient exécuter à leur insu des programmes non libres dans leur navigateur. Ces programmes sont généralement écrits en JavaScript, d'où le nom « piège JavaScript ».

    C'est d'ailleurs l'une des raisons pour lesquels RMS recommande de ne pas utiliser Google. « En général, la plupart des services de Google nécessitent l'exécution de code JavaScript non libre. Si vous refusez de le faire, vous verrez que vous ne pourrez pas utiliser ces services », affirme Stallman. Ce serait par exemple le cas de Google Docs qui requiert l’exécution d’un code JavaScript non libre pour éditer un document, ou encore YouTube qui repose sur un logiciel (code JavaScript) non libre pour l’utilisation normale du site. « Ce n'est pas une bonne façon de distribuer la vidéo », estime Richard Stallman pour qui, un programme qui n’est pas libre soumet les utilisateurs à la merci du développeur du programme. « C'est une injustice pour l'utilisateur », dit-il dans un billet. Stallman s’insurge également contre le fait que « même créer un compte Google nécessite l'exécution de logiciels non libres (JavaScript envoyé par le site) ».

    La première réponse du projet GNU au problème du code JavaScript non libre a été de développer LibreJS, qui permet aux navigateurs basés sur Firefox de détecter et de bloquer ce code. LibreJS empêche d'exécuter les programmes JS non libres d'un site. Toutefois, cela peut faire que certains sites ne fonctionnent pas correctement, comme RMS l'expliquait pour le cas des services Google.

    Nom : gnulogo.png
Affichages : 58114
Taille : 9,5 Ko

    La nouvelle solution du projet GNU est de créer des extensions propres à des sites pour remplacer le code JavaScript non libre qu'ils envoient aux navigateurs des utilisateurs. « Nous pourrions également résoudre le problème en convainquant les webmasters de corriger leurs sites pour qu'ils fonctionnent sans le code JavaScript [non libre], mais les convaincre s'avère très difficile, car la plupart du temps, ils ne comprennent pas le problème, encore moins s'en soucient », a écrit le projet GNU. Ils estiment donc que recommander ces futures extensions libres serait la solution à ce problème.

    Le projet GNU invite donc les partisans de son mouvement à contribuer à cette cause. Il semble toutefois qu'il faut y aller site par site. Ainsi, une liste de sites parmi les plus populaires au monde a été proposée pour commencer. « Nous invitons les volontaires à choisir un site et à écrire une extension de navigateur pour faire fonctionner ce site, en supposant que LibreJS bloque le JavaScript non libre envoyé par le site », peut-on lire sur le site du projet GNU. L'objectif initial est d'écrire des extensions pour gérer l'accès anonyme à ces sites. Des instructions sont même données sur la manière dont tout doit se faire. Toutefois, cette initiative ne va-t-elle pas un peu trop loin ?

    Source : GNU

    Et vous ?

    Que pensez-vous de cette initiative ? Ne va-t-elle pas un peu trop loin ?
    Cela dit, le combat du mouvement libre en général peut-il aboutir un jour ? Si oui, à quelles conditions ?

    Voir aussi :

    Richard Stallman adopte une alternative aux codes de conduite pour le projet GNU : les GNU Kind Communications Guidelines
    Un logiciel libre doit-il être en mesure de restreindre les tâches que ses utilisateurs peuvent effectuer avec son aide ? Non, pour Richard Stallman
    Trolldi : une blague de Richard Stallman sur l'avortement crée la polémique, 26 ans après avoir été écrite dans la documentation du projet glibc
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre averti
    Homme Profil pro
    Ingénieur avant-vente
    Inscrit en
    septembre 2020
    Messages
    125
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur avant-vente

    Informations forums :
    Inscription : septembre 2020
    Messages : 125
    Points : 449
    Points
    449
    Par défaut
    La solution la plus raisonnable serait d'arrêter d'utiliser JavaScript pour tout et n'importe-quoi.

  3. #3
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 346
    Points : 1 264
    Points
    1 264
    Par défaut
    Que pensez-vous de cette initiative ? Ne va-t-elle pas un peu trop loin ?

    Je comprend l'idée, mais la mise en pratique est juste impossible.
    Quand vous allez sur un site, vous vous contentez de faire une demande de ressources à un serveur HTTP, comment voulez vous savoir ce que le serveur va vous renvoyer et si oui ou non ça correspond à votre idée du web ?
    Faire une extension par site, ça va vite devenir ingérable, sans évoqué que c'est irréalisable pour l’ensemble du web.

    Cela dit, le combat du mouvement libre en général peut-il aboutir un jour ? Si oui, à quelles conditions ?

    Les idées sont bonnes, la mise en pratique pas tellement.
    Pour que le mouvement libre puisse se développer et mettre ses idées en pratique, il faudrait un soutient politique de plusieurs "grosses" nation pour obliger les fabricants, éditeurs de logiciel et autres éléments de la filière à ce conformé à leurs idées.
    A l'heure actuel, on ce dirigeraient plutôt vers le privateur à outrance que vers les idées du libre.
    Après ça, les politique vienne quémander les miettes en voulant assurer la réparabilités (limiter à 10, pourquoi ?) et limiter les déchets, mais le libre permettrait cela dès maintenant si les fabricants, éditeurs et autres y étaient contraints.

  4. #4
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    372
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 372
    Points : 1 242
    Points
    1 242
    Par défaut
    « Nous pourrions également résoudre le problème en convainquant les webmasters de corriger leurs sites pour qu'ils fonctionnent sans le code JavaScript [non libre], mais les convaincre s'avère très difficile, car la plupart du temps, ils ne comprennent pas le problème, encore moins s'en soucient
    Si tu paye ça pourrait marcher sinon ... pas de bras, pas de chocolat.

    Pour être plus pertinant, tant que le monde de la concurrence existe tel qu'aujourd'hui, absolument impitoyable, je doute que le libre puisse marcher, il serait trop facile de voler les efforts des autres.

  5. #5
    Membre habitué
    Homme Profil pro
    Inscrit en
    juillet 2003
    Messages
    28
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2003
    Messages : 28
    Points : 127
    Points
    127
    Par défaut
    Javascript est surement une des pires choses qui soit arrivées à l'informatique ces 15 dernières années.
    C'est un terrible pas en arrière que TypeScript a mis des années a essayer de corriger.
    C'est aussi un language très peu écolo qui a nécessité beaucoup d'énergie à éxécuter, également à cause de toutes les jQuery etc. qui doivent être exécutés pour rendre cette technologie utilisable.
    Ca a fait croire aux décideurs que c'était possible de faire une appli web de la même manière qu'une appli client, alors que la complexité, les compétences, la maintenabilité et évidemment les coûts n'ont rien à voir. L'argent qui a été mis a essayer de faire marcher ces trucs (maintenant ça marche avec les grosses surcouches que sont Angular et TypeScript) a été une terrible perte de productivité.

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    372
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 372
    Points : 1 242
    Points
    1 242
    Par défaut
    Citation Envoyé par vbarr Voir le message
    Javascript est surement une des pires choses qui soit arrivées à l'informatique ces 15 dernières années.
    C'est un terrible pas en arrière que TypeScript a mis des années a essayer de corriger.
    C'est aussi un language très peu écolo qui a nécessité beaucoup d'énergie à éxécuter, également à cause de toutes les jQuery etc. qui doivent être exécutés pour rendre cette technologie utilisable.
    Ca a fait croire aux décideurs que c'était possible de faire une appli web de la même manière qu'une appli client, alors que la complexité, les compétences, la maintenabilité et évidemment les coûts n'ont rien à voir. L'argent qui a été mis a essayer de faire marcher ces trucs (maintenant ça marche avec les grosses surcouches que sont Angular et TypeScript) a été une terrible perte de productivité.
    Perso même avant Angular si on me demandait de faire un site avec login/password + formulaire de saisie BDD, je le ferais plus vite et avec un meilleur rendu (merci bootstrap) que sur un client lourd. Donc je ne suis pas entièrement d'accord.

    Je veux dire, si on prend du vanilla JS d'il y a 20 ans et la même pour un client lourd, tu auras les même problématiques : la validation des champs de formulaires, tout les effets de rendus pour les retours utilisateurs etc. Mais le fait est que HTML/CSS/Javascript ont beaucoup plus avancé. C'est être moi mais je dois faire du rendu un peu souple en terme de résolution avec de la validation de formulaire et tout, j'irais quand même plus vite quelque librairies de base web qu'en JavaFX + quelque librairie de base. Des applis de gestions de données a coup de formulaire, ça se fait vraiment bien en web.

    En revanche des systèmes plus poussés ont effectivement intérêt a y réfléchir à deux fois avant de préférer le web au client lourd.

  7. #7
    Membre éclairé

    Homme Profil pro
    Développeur Web
    Inscrit en
    octobre 2007
    Messages
    730
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : octobre 2007
    Messages : 730
    Points : 734
    Points
    734
    Par défaut
    Pour moi, bien que j'adore le JavaScript et le libre, je pense que cette initiative est infaisable, en tous cas, tant que l'on fait autant usage des bundlers.
    Afin d'obtenir plus facilement de l'aide, n'hésitez pas à poster votre code de carte bancaire

    Mon GitHub

    Une alternative à jQuery, Angular, Vue.js, React, ... ? Testez anticore, en quelques secondes à peine !
    (Contributions bienvenues)

  8. #8
    Membre extrêmement actif
    Homme Profil pro
    Technicien de maintenance / Developpeur PHP
    Inscrit en
    mai 2015
    Messages
    346
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Technicien de maintenance / Developpeur PHP
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2015
    Messages : 346
    Points : 1 264
    Points
    1 264
    Par défaut
    Perso même avant Angular si on me demandait de faire un site avec login/password + formulaire de saisie BDD, je le ferais plus vite et avec un meilleur rendu (merci bootstrap) que sur un client lourd.
    Donc je ne suis pas entièrement d'accord.
    ...
    @walfrat
    Oui, effectivement, moi aussi je ferais un "site" avec auth plus vite en web qu'en client lourd, tout simplement parce que ça n'as aucun sens de "faire du web avec du client lourd" (je plaisante, mais je croit avoir comprit l'idée).
    Et puis, ça doit aussi à voir avec ton expérience.
    Pense qu'un développeur qui fait du client lourd toute la journée fume n'importe quel dev web ("finger in the nose", moi comprit ) pour faire une UI métier (temps de compilation et interactivité de l'UI comprit).

    Le web pour faire des Applis métier, c'est juste à défaut d'avoir des technologies cross-plateform valable et "gratuite" pour les Entreprises (et accessoirement, de la main d’œuvre pas cher ).

    Je veux dire, si on prend du vanilla JS d'il y a 20 ans et la même pour un client lourd, tu auras les même problématiques : la validation des champs de formulaires, tout les effets de rendus pour les retours utilisateurs etc.
    Mais le fait est que HTML/CSS/Javascript ont beaucoup plus avancé.
    ...
    @walfrat
    Les techno ont évolués certes, mais certains essai de tout faire en web, alors que ce n'est juste pas comparable / pas les mêmes usages.

    Euh, ... La validation des data, ok, mais ça c'est un fait que tout ce qui rentre dans ton appli doit être validé, client lourd ou léger, d'avant ou d'aujourd'hui, c'est pareille.
    Même une entrée système/utilisateur local doit être parsé et validé avant traitement (j’espère que tout le monde fait ça ).

    Par contre, en ce qui concerne le rendus utilisateur (et je l'est déjà écrit ici sur un fils de discussion concernant l'UI), les frameworks d'UI pour client lourd, font tout le job et sont largement moins galère que le web (qui n'est juste pas fait pour ça à la base).
    D’ailleurs ce n'est pas un hasard si les framework d'UI Web tendent à mimer des idées/comportements de framework d'UI pour client lourd (composants web, rendu dans canvas, ...etc).

    Et puis, dire que HTML, CSS et JS sont plus "avancé" aujourd'hui, ce n'est pas vraiment le cas (pas taper , j'explique).

    • HTML à supprimer certaine balises et en a ajouter d'autre pour ajouter de la sémantique (du sens), alors évidemment c'est une bonne chose, mais fondamentalement, rien n'as changé.
      HTML est un langage de balisage pour organisé un document texte, et pas une technologie d'UI révolutionnaire.
      Ce n'est pas le bon outil pour le job.
    • CSS lui c'est vraiment transformé, mais dans le fond, il ne sert qu'à la mise en page du document HTML qui vient derrière.
      De plus il est loin d'être "bien plus simple" qu'un framework d'UI pour client lourd.
      P.S. : Alors pourquoi de plus en plus de framework gui l'utilise me direz-vous ? Et bien peut être pour mettre à la portés des très nombreux dev web leur outils.
      Au contraire, il tend à ce complexifier avec l'age, ce qui est une preuve en soit d'un manque quelque part, non ?.

      Combien de personnes sont capable de l'utiliser à sont plein potentiel ?
      Et je parle pas de 4 @keyframes qui ce touches pour faire de l'animation .
      Honnêtement, pas moi, même si je peut faire de jolies animations et de belles mises en page, ça demande quand même pas mal d'effort, quand un client lourd en QML ou VCL aura déjà probablement ce que je veut dans une lib ou autre sans devoir modifier mon code par ailleurs pour coller à ma présentation (Merci qui ? Merci DOM/VDOM/ShadowDOM).
      Qui n'as jamais du toucher sont HTML pour "permettre" de faire ce que le client voulait en CSS ?
      C'est comme devoir recoder une partie de son appli parce que l'on veut mettre un spinner au chargement, c'est limite non ?
    • JS lui aussi c'est transformer, malheureusement il est resté rétrocompatible avec lui même et ça sa le plombe directement.
      Quand on fait du client lourd, on est relativement confient quant aux comportements de notre appli, alors qu'avec un client léger, vous êtes complétement dépendant du client utilisé par vos utilisateurs.
      Ok, Chrome à un quasi monopole, mais ayant connu l'aire IE6 et le faite de se reposer sur un client tiers totalement indépendant de vous ou de vos usager, d'expérience, c'est jouer la confiance .


    C'est être moi mais je dois faire du rendu un peu souple en terme de résolution avec de la validation de formulaire et tout, j'irais quand même plus vite quelque librairies de base web qu'en JavaFX + quelque librairie de base.
    Des applis de gestions de données a coup de formulaire, ça se fait vraiment bien en web.
    ...
    @walfrat
    Disons que pour ton appli de gestion de données, il faudra que tu fasse en "client léger", du HTML, CSS, JS + du backend (donc serveur / proxy HTTP, ...etc + ton coeur de métier avec le langage X), ça n'as de léger que le nom à mon avis.
    Alors qu'avec (je reprend ton exemple en JFX) ton "client lourd", tu fait une UI en JavaFX/TornadoFX/...etc (AWT ? ) et tu code ton app en Java/Kotlin/...etc (et en prime, ton "client lourd" sera plus léger que ton "client léger").

    Sachant qu'avec ton appli lourd, tu contrôlera tout de A à Z et le comportement est relativement uniforme et stable (ça fait un moment que les différentes résolutions peuvent être prisent en charge par les framework ui "lourd").

    D'accord la plateforme web est flexible, mais comme écrit précédemment c'est à défaut de mieux qu'elle c'est imposé face au client lourd, pas par ces méritent intrinsec.
    La plateforme web est faites pour la manipulation de documents texte et l'a toujours était.
    L'avantage qu'elle a acquit, c'est de disposer de clients/browser sur toutes les plateformes existantes, mais un client lourd ciblant une plateforme donné, donnera toujours de meilleurs résultats que l'utilisation du web hors de sont domaine de prédilection (site web et présentation de documents).

    En revanche des systèmes plus poussés ont effectivement intérêt a y réfléchir à deux fois avant de préférer le web au client lourd.
    @walfrat
    On est d'accord.

  9. #9
    Membre éprouvé
    Profil pro
    Inscrit en
    juin 2009
    Messages
    372
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2009
    Messages : 372
    Points : 1 242
    Points
    1 242
    Par défaut
    Citation Envoyé par defZero Voir le message
    Oui, effectivement, moi aussi je ferais un "site" avec auth plus vite en web qu'en client lourd, tout simplement parce que ça n'as aucun sens de "faire du web avec du client lourd" (je plaisante, mais je croit avoir comprit l'idée).
    Et puis, ça doit aussi à voir avec ton expérience.
    Evidemment, j'ai fais plus de web que de client lourd, mais j'ai tout même fait du Swing et aussi du JavaFX, et il y a des points qui prennent plus de temps, exemple bête : aligner des libelles/champs de formulaire et aussi éventuellement s'adapter à la résolution de l'écran. Personnellement après m'être arraché les cheveux pendant quelque jours, j'ai lâché l'affaire et considéré une résolution fixe (c'était de la R&D, donc ça passe).

    Pense qu'un développeur qui fait du client lourd toute la journée fume n'importe quel dev web ("finger in the nose", moi comprit ) pour faire une UI métier (temps de compilation et interactivité de l'UI comprit).
    J'ai pas croisé le premier cas, mais je ne vais pas spécialement commenter


    Le web pour faire des Applis métier, c'est juste à défaut d'avoir des technologies cross-plateform valable et "gratuite" pour les Entreprises (et accessoirement, de la main d’œuvre pas cher ).
    N'oublie pas la facilité de déploiement, c'est le principal atout pour faire du web en entreprise, plutôt que le cross plateforme (ils sont tous sur Windows de toute façon).

    Les techno ont évolués certes, mais certains essai de tout faire en web, alors que ce n'est juste pas comparable / pas les mêmes usages.
    On est d'accord.

    Euh, ... La validation des data, ok, mais ça c'est un fait que tout ce qui rentre dans ton appli doit être validé, client lourd ou léger, d'avant ou d'aujourd'hui, c'est pareille.
    Même une entrée système/utilisateur local doit être parsé et validé avant traitement (j’espère que tout le monde fait ça ).
    Mon point c'était que faire tout les petits retour utilisateurs qui gère sont largement mieux gérer de base en Web que en client lourd, de ma propre expérience évidemment (angularJS/Angular vs Swing / JavaFX). Évidemment c'est parce que le Web considère la gestion de formulaire comme "native" alors que Swing et JavaFX, n'ont pas spécialement des éléments très poussés pour la gestion de formulaire de base.

    Et il faut pas oublier de revalider les entrée utilisateurs côté serveurs, évidemment .

    Par contre, en ce qui concerne le rendus utilisateur (et je l'est déjà écrit ici sur un fils de discussion concernant l'UI), les frameworks d'UI pour client lourd, font tout le job et sont largement moins galère que le web (qui n'est juste pas fait pour ça à la base).
    D’ailleurs ce n'est pas un hasard si les framework d'UI Web tendent à mimer des idées/comportements de framework d'UI pour client lourd (composants web, rendu dans canvas, ...etc).

    Et puis, dire que HTML, CSS et JS sont plus "avancé" aujourd'hui, ce n'est pas vraiment le cas (pas taper , j'explique).

    • HTML à supprimer certaine balises et en a ajouter d'autre pour ajouter de la sémantique (du sens), alors évidemment c'est une bonne chose, mais fondamentalement, rien n'as changé.
      HTML est un langage de balisage pour organisé un document texte, et pas une technologie d'UI révolutionnaire.
      Ce n'est pas le bon outil pour le job.
    • CSS lui c'est vraiment transformé, mais dans le fond, il ne sert qu'à la mise en page du document HTML qui vient derrière.
      De plus il est loin d'être "bien plus simple" qu'un framework d'UI pour client lourd.
      P.S. : Alors pourquoi de plus en plus de framework gui l'utilise me direz-vous ? Et bien peut être pour mettre à la portés des très nombreux dev web leur outils.
      Au contraire, il tend à ce complexifier avec l'age, ce qui est une preuve en soit d'un manque quelque part, non ?.

      Combien de personnes sont capable de l'utiliser à sont plein potentiel ?
      Et je parle pas de 4 @keyframes qui ce touches pour faire de l'animation .
      Honnêtement, pas moi, même si je peut faire de jolies animations et de belles mises en page, ça demande quand même pas mal d'effort, quand un client lourd en QML ou VCL aura déjà probablement ce que je veut dans une lib ou autre sans devoir modifier mon code par ailleurs pour coller à ma présentation (Merci qui ? Merci DOM/VDOM/ShadowDOM).
      Qui n'as jamais du toucher sont HTML pour "permettre" de faire ce que le client voulait en CSS ?
      C'est comme devoir recoder une partie de son appli parce que l'on veut mettre un spinner au chargement, c'est limite non ?
    • JS lui aussi c'est transformer, malheureusement il est resté rétrocompatible avec lui même et ça sa le plombe directement.
      Quand on fait du client lourd, on est relativement confient quant aux comportements de notre appli, alors qu'avec un client léger, vous êtes complétement dépendant du client utilisé par vos utilisateurs.
      Ok, Chrome à un quasi monopole, mais ayant connu l'aire IE6 et le faite de se reposer sur un client tiers totalement indépendant de vous ou de vos usager, d'expérience, c'est jouer la confiance .

    J'ai effectivement pas très bien dit ce que je voulais dire, je pensais simplement plus à l'évolution des technos et le langage, que le langage lui-même.

    Et quand je vois le templating Angular (même angularJS) et le templating JavaFX, y'a aucun doute que c'est le templating Angular qui gagne.

    Disons que pour ton appli de gestion de données, il faudra que tu fasse en "client léger", du HTML, CSS, JS + du backend (donc serveur / proxy HTTP, ...etc + ton coeur de métier avec le langage X), ça n'as de léger que le nom à mon avis.
    Alors qu'avec (je reprend ton exemple en JFX) ton "client lourd", tu fait une UI en JavaFX/TornadoFX/...etc (AWT ? ) et tu code ton app en Java/Kotlin/...etc (et en prime, ton "client lourd" sera plus léger que ton "client léger").

    Sachant qu'avec ton appli lourd, tu contrôlera tout de A à Z et le comportement est relativement uniforme et stable (ça fait un moment que les différentes résolutions peuvent être prisent en charge par les framework ui "lourd").
    Quand je parle de client léger, je parle de la définition formelle à savoir pas de déploiement de ton appli sur les client, puisque les navigateurs sont là. Aussi quand je parle de la progression sur 20ans, e pense aussi au fait que l'ère IE6/7/8
    est terminée, heureusement pour nous, même si ce n'est pas encore parfait.

    D'accord la plateforme web est flexible, mais comme écrit précédemment c'est à défaut de mieux qu'elle c'est imposé face au client lourd, pas par ces méritent intrinsec.
    La plateforme web est faites pour la manipulation de documents texte et l'a toujours était.
    L'avantage qu'elle a acquit, c'est de disposer de clients/browser sur toutes les plateformes existantes, mais un client lourd ciblant une plateforme donné, donnera toujours de meilleurs résultats que l'utilisation du web hors de sont domaine de prédilection (site web et présentation de documents).
    Il faut définir "meilleur résultat". Le web est pratique pour faire des pages relativement "simple" qui n'ont pas des dizaines de milliers de noeuds HTML (la magie du CSS fait qu'on n'est plus limité que sur un client lourd, sauf si on prend des Canvas et qu'on fait tous à la main).

    Personnellement les deux points qui m'ont fâche quand je suis passé sur client lourd c'est :

    Les formulaires (validation, rendu utilisateur, alignement des champs, résolution, bref formulaire aux petit oignons)
    La navigation

    Pourquoi ? Parce que ces mécaniques sont largement plus intégrées nativement dans le web que dans Swing/JavaFX où il faut gérer cela soi même (toujours de mon expérience). Et il s'avère que quand on fait des applis qui font une grosse partie de la gestion de données, ce qu'on fait principalement ce sont :

    Des tableaux
    Des formulaires
    De la navigation
    Des requêtes vers le serveur.

    Bon y'a la sérialisation native dans JS en JSON mais c'est pas assez significatif pour que je le mette en bon point par rapport au client lourd (sérialisation java, oui bien sur, embarquée dans du SOAP ).

    Pour moi le "meilleur résultat" c'est de pouvoir répondre aux specs dans les coûts et avoir un truc maintenable. Et autant dire qu'une fois qu'on est rôdé à Angular, je trouve largement plus maintenable des templates ou je peux exprimer un maximum de choses et de conditions dans celui-ci et gérer le framework, que de gérer plus de choses à la main. Et oui, je sais que Angular c'est pas gratuit en perf, c'est pour a que j'utilisais Ag-grid, grille native avec intégration Angular, et pas grille Angular.

    Ma propre expérience est basée sur ce que j'ai appris par moi-même a travers différents tuto pour te mettre le pieds à l'étrier, que ce soit en Web et JavaFX (j'ai fait info en école d'ingé mais on apprend pas spécialement à faire du Web ou du Swing).
    Je ne prétend pas pouvoir déterminer ce qu'un maître du client lourd vs un maître du client léger peut faire. Déjà je crois pas tant que ça de personnes qui sont juste capable d'être à l'aise dans une techno et comprendre comment elle fonctionne, alors trouver des experts... (les vrais, pas ceux qui sont juste le seul a connaître la techno dans la boîte ). Si on me demande, je suis un dev intémédiaire, mais on préfère me dire que je suis à un plus haut niveau.

Discussions similaires

  1. Réponses: 311
    Dernier message: 19/04/2021, 11h47
  2. Réponses: 7
    Dernier message: 27/08/2020, 11h27
  3. Réponses: 3
    Dernier message: 28/11/2018, 10h30
  4. Réponses: 8
    Dernier message: 28/10/2018, 15h57
  5. Richard Stallman, l'initiateur du mouvement du logiciel libre, recommande d'éradiquer Facebook
    Par Stéphane le calme dans le forum Logiciels Libres & Open Source
    Réponses: 42
    Dernier message: 02/04/2016, 11h59

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