Je ne suis pas tout à fait sûr d’où vient ce chiffre de 1 %, mais avec 14 millions d’utilisateurs, cela représente toujours 14 000 utilisateurs qui seraient bannis de Discourse. Juste pour ajouter quelques ajustements CSS et de performance ?
Quant à la question « Quel nombre d’utilisateurs devrait pouvoir empêcher le pourcentage restant de profiter de leur logiciel à jour ? »… pourquoi ce nombre ne pourrait-il pas être bien, bien inférieur à 1 %, beaucoup plus proche de 0 % que de 1 % ? Je soutiendrais que Discourse devrait adopter l’approche inverse, et non apporter inutilement des changements non rétrocompatibles à moins qu’il n’y ait une correction critique primordiale ou une fonctionnalité majeure qui l’exige absolument, ET qu’il y ait une demande généralisée des utilisateurs pour cela.
L’inverse de cette question est « Combien d’utilisateurs sommes-nous prêts à exclure pour rechercher quelques commodités mineures avec un impact faible ou nul sur l’utilisateur ? » Une légère amélioration des performances qui sera à peine perceptible sur autre chose que des benchmarks minutieux vaut-elle la peine d’exclure 14 000 personnes de leurs communautés ?
Quel genre de « logiciel à jour » les utilisateurs de forums réclament-ils… ? C’est un forum. Les gens lisent du texte et répondent à des messages texte. Il est effrayant que les développeurs continuent de dire « nous devons continuer à avancer » alors que vos clients réels disent, attendez, pourquoi, aucune de ces fonctionnalités n’a de sens et vous excluez de vraies personnes.
J’ai l’impression que c’est exactement l’approche opposée que l’on attendrait d’un logiciel de forum stable et ancien comme Discourse. Si vous voulez expérimenter de nouvelles fonctionnalités, cela devrait se faire sur une branche canary instable à laquelle les gens doivent explicitement adhérer, et la branche principale devrait être LTS par défaut. Non seulement vous n’offrez pas d’améliorations progressives, mais vous n’offrez pas non plus de dégradations gracieuses. C’est un choix, pas une partie inhérente du développement logiciel. Vous choisissez d’aller plus vite que vos utilisateurs ne peuvent suivre.
Et vos communautés hébergées n’ont aucun choix. Ceux qui vous paient pour leur communauté, pas pour être une démo technologique et un bac à sable JS.
C’EST pourquoi c’est un problème culturel et non technique. Merci d’être au moins prêt à le dire à voix haute. Vous avez pesé les coûts de cela en heures de développement par rapport aux impacts estimés sur les utilisateurs, et dans vos calculs, les utilisateurs valent moins que le coût qu’il faudrait pour créer une version de base pour la publication. Il n’y a pas d’autre façon de le dire : vous ne valorisez pas vos vrais utilisateurs et communautés autant que les raccourcis développeurs 
Désolé de sortir cette citation un peu de son contexte, mais… si vous arrêtiez de penser en termes de pourcentages et pensiez aux impacts sur de vraies personnes individuelles dans leurs communautés, peut-être que les calculs seraient différents ?
Tout cela ressemble un peu à du stalinisme, disant aux gens qu’ils sont essentiellement une statistique jetable parce qu’ils sont trop pauvres pour mettre à niveau leur matériel ou que c’est leur faute s’ils ne sont pas disposés et capables de faire des acrobaties pour installer un autre système d’exploitation, une couche de compatibilité ou un fork de navigateur… juste pour qu’ils puissent continuer à poster des messages texte sur un forum dont ils font partie depuis de nombreuses années ?
C’est le genre de rapport coût-bénéfice que j’attendrais d’une nouvelle version majeure, comme une réécriture complète, pas de quelques fonctionnalités mineures et invisibles pour les développeurs qui pourraient avoir de petits avantages en termes de performance =/ Il est vraiment regrettable que votre entreprise adopte cette position, à mon avis, mais quand même… j’apprécie vraiment la transparence.
OK. Bref, assez de plaintes. J’ai une question potentiellement/espérons-le plus constructive…
Si nous supposons qu’un mode HTML de base serait utile pour un petit nombre d’utilisateurs, mais que ce n’est pas quelque chose sur lequel Discourse souhaite dépenser des ressources pour le construire lui-même… est-ce que ce serait réalisable pour la communauté open-source de s’en charger ? Cela semble un peu trop grand pour être quelque chose comme un plugin, tout en étant trop petit pour un projet entièrement séparé (comme Discorkie).
Serait-il concevable d’essayer de définir cela comme un frontend ouvert alternatif qui fonctionne avec les API actuelles, et si oui, y aurait-il une chance que cela (une fois construit et testé) soit « officiellement » accepté/intégré au logiciel principal de telle sorte qu’il puisse également être utilisé sur des instances Discourse hébergées (où se trouve l’une de mes communautés affectées) ?
Dans ce sens, avez-vous un système de versionnement/stabilité d’API qu’un frontend alternatif pourrait suivre ?
Peut-être que la réponse sera toujours une variété de « non » pour diverses raisons, et si c’est le cas, ce n’est pas grave, mais si c’est tout à fait réalisable… cela pourrait être intéressant d’y réfléchir ? Je ne demande pas une étude de faisabilité à grande échelle, peut-être juste quelques intuitions ?
Je ne suis pas certain qu’une telle chose puisse jamais décoller ou être maintenue. Peu de développeurs aiment travailler sur de vieux logiciels utilisant HTML et un minimum de JS (mais il y en a encore, comme les gens de HTMX). Juste une pensée.