Discussion :

[Michael Guilloux]

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.

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

[Invité]

La solution la plus raisonnable serait d'arrêter d'utiliser JavaScript pour tout et n'importe-quoi.

[defZero]

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.

[walfrat]

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

[vbarr]

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

[walfrat]

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.

[Lcf.vs]

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.

[defZero]

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.

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

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.