Avons-nous perdu notre cap dans le développement logiciel efficace ?

• En tentant d’éditer dans le navigateur un document Word d’environ 30 Mo, l’auteur a subi une latence à la saisie, illustrant concrètement le coût en performance des applications web modernes
• Le document contenait principalement du texte, avec seulement quelques images et tableaux, mais Google Docs ou l’environnement Chrome ne l’ont pas traité de façon fluide
• À la place de Microsoft Office payant, l’auteur a installé LibreOffice, où le même document fonctionnait bien plus vite, mettant en évidence l’écart entre applications web et applications natives
• À mesure que les applications web modernes exigent davantage de mémoire et de CPU, cela alimente l’idée que la montée en gamme du matériel va de pair avec des applications web gourmandes en ressources
• Même si les PWA et les interfaces basées sur le navigateur se généralisent, la rendu natif et une conception logicielle efficace restent essentiels en matière d’utilisabilité

---

Le problème de performance des applications web révélé par un document de 30 Mo

• Google Docs a d’abord été choisi pour profiter d’un compte Google et de la synchronisation automatique dans le cloud
• Après avoir importé le document dans Google Docs et commencé à taper, plusieurs secondes s’écoulaient avant que les caractères n’apparaissent à l’écran
• Le fichier pesait environ 30 Mo ; il contenait quelques images et des tableaux simples, mais il s’agissait surtout de texte
• L’auteur en a conclu que Chrome ou Google Docs ne parvenaient pas à traiter correctement ce document
• Microsoft Office a été écarté car payant, et LibreOffice installé à la place faisait tourner le même document très rapidement

Une question plus large sur l’efficacité

• Cela amène à se demander si les outils, frameworks et langages modernes ne rendent pas les logiciels plus lourds sur le plan des performances
• Pour faire tourner des applications web gourmandes en ressources, les configurations matérielles ont gagné en puissance ; selon l’auteur, si seules des applications purement natives existaient, ces exigences pourraient être moindres
• L’exemple des appareils mobiles nécessitant 16 Go de RAM est cité pour dénoncer l’augmentation de l’usage des ressources par les logiciels
• Le web, plutôt que de rester un simple wrapper de moteur de rendu d’interface, devrait atteindre une efficacité de niveau rendu natif
• En 1966, l’ordinateur d’Apollo a permis l’alunissage avec 2 Ko de RAM, alors qu’en 2024 un navigateur peine à traiter un document d’environ 30 Mo : ce contraste souligne la nécessité de l’optimisation

[GN⁺]

Avis sur Hacker News

• Même si l’on veut créer une app native, on a l’impression qu’Apple et Microsoft continuent de mettre des bâtons dans les roues. Il faut accepter les comptes développeur, les certificats de signature de binaires, et même une commission de 30 % sur le chiffre d’affaires sans grande raison ; côté Microsoft en particulier, les API sont devenues déroutantes
  Du coup, on finit par choisir le web, plus simple et moins cher

  • Sur macOS, l’Apple Developer Program n’est nécessaire que si l’on veut signer des binaires ou distribuer via le Mac App Store. Microsoft aussi ne fait payer que si l’on publie sur le Microsoft Store, ou si l’on utilise Visual Studio dans une entreprise dépassant certains seuils
    Les apps non signées peuvent tout de même s’exécuter sur Windows et macOS, mais elles affichent davantage d’avertissements. La commission de 30 % ne s’applique elle aussi que si l’on utilise le Mac App Store ou le Microsoft Store ; et le Microsoft Store semble ne pas prélever de commission si ce n’est pas un jeu et que l’on utilise son propre système de paiement
  • C’est l’une des raisons pour lesquelles, après avoir longtemps fait du développement C/C++, je suis passé au développement web en JavaScript. Le processus de publication d’une app iPhone sur l’Apple App Store était infernal, alors qu’une web app n’a pas besoin de licence, d’approbation ni d’installateur
  • Pour le dire franchement, chez Microsoft, la création d’un compte développeur, la signature des binaires et le partage de 30 % du chiffre d’affaires ne sont pas obligatoires. Je ne trouve pas non plus les API Microsoft désastreuses : il y a des options comme Win32, .NET et UWP, qui fonctionnent plutôt bien et sont flexibles
    Je connais moins Apple, mais il est très probable qu’on puisse créer des apps Mac sans compte développeur ; pour l’iPhone, en revanche, il en faut un. Le prix que j’avais vu à l’époque était de 99 $ par an, ce qui n’est pas énorme si l’on compte sérieusement créer une app
  • Si l’on intègre directement le paiement par carte sur le web, il faut payer 2,9 % + 30 ¢ à Stripe. Il faut facturer 10 dollars pour que les frais de transaction descendent à environ 6 %, ce qui impose un prix plancher et des contraintes sur le modèle de facturation
    Le traitement des contestations de paiement et des remboursements coûte aussi de l’argent, et il faut consacrer du temps au support client ou embaucher quelqu’un. Sous 1 million de dollars de chiffre d’affaires annuel, la commission d’Apple est de 15 %, donc pour des apps peu chères ou à valeur ajoutée, Apple peut être une meilleure affaire que de gérer soi-même les paiements
  • Quand je créais des apps natives pour macOS, Windows et Linux, je n’avais pas besoin de faire tout ça : j’utilisais simplement Qt

• Il est ironique que cet article de 265 mots soit publié sur Medium, qui télécharge 10,88 Mo

  • Du point de vue de Medium, la publicité est le vrai contenu. L’article est le véhicule qui transporte jusqu’au navigateur le vrai contenu, c’est-à-dire les publicités, et la diffusion publicitaire exige beaucoup de complexité
  • Avec about:process dans Firefox, même 10 minutes après la fin du chargement, cet article utilisait encore 239 Mo de mémoire et 0,06 à 0,2 % de CPU, et 45 % du temps CPU semblait consommé par Google reCAPTCHA
    J’aimerais que des acteurs comme Mozilla ou Google collectent des statistiques d’utilisation CPU, mémoire et énergie par domaine, pour mettre publiquement dans l’embarras les développeurs qui ne se soucient pas des performances
  • Les navigateurs sont devenus plus gros que pas mal de systèmes d’exploitation, et l’écosystème donne lui aussi l’impression d’être fermé. WASM reste encore très contraint, et en développement web, les seuls choix réellement possibles sont JS/HTML/CSS
    Le web donne à nouveau l’impression d’être en 2005. Sauf que cette fois, les pop-ups sont intégrés dans la page
  • Dans ce genre de cas, j’ouvre gemini://gemi.dev/bin/waffle.cgi dans le navigateur Gemini et j’y colle l’URL. Ceux qui n’utilisent pas le réseau Gemini peuvent remplacer medium.com par scribe.rip dans l’URL
  • Dans un navigateur en mode texte, ça va

• Oui, on s’est perdus, et la raison est simple : parce qu’on pouvait le faire. C’était le chemin de moindre résistance, alors on l’a pris
  Pendant des décennies, le logiciel a profité gratuitement des progrès du matériel, surtout dans le web et les apps de bureau. La loi de Moore a été à la fois une bénédiction et une malédiction, et les logiciels que nous utilisons aujourd’hui sont créés par des gens qui ont appris la technologie au moment où cette rente battait son plein

  • Ce qui me rend fou, c’est que ce qu’on fait avec un ordinateur reste à peu près le même chaque année, alors que les logiciels deviennent de plus en plus lourds. En 2010 encore, une distribution Linux avec environnement de bureau démarrait avec 100 Mo de RAM, et les versions optimisées tournaient autour de 60 Mo
    Aujourd’hui, un ordinateur avec moins de 8 Go est inutilisable, et même 8 Go, c’est tout juste acceptable. Les nouveaux logiciels utilisent Electron et consomment au minimum 1 Go de RAM, et tout, y compris les navigateurs, utilise une quantité de mémoire absurde
    Windows est encore plus incompréhensible. Chaque fois que j’aide ma mère avec son ordinateur, c’est un PC récent avec un i5 et 8 Go de RAM, mais il est beaucoup trop lent ; le démarrage, le lancement des programmes et les mises à jour prennent une éternité. Un ordinateur qui met plus d’une minute à démarrer, j’ai envie de le jeter par la fenêtre
  • C’est vrai. Je pense qu’une bonne partie des problèmes difficiles du logiciel n’ont pas été résolus, mais contournés. Les conteneurs en sont un parfait exemple
    On n’a pas résolu le déploiement d’applications dans plusieurs langages et environnements ; on l’a esquivé avec un moteur de conteneurs. On pourrait fournir aux utilisateurs qui le souhaitent un script de build installant compilateurs et outils, mais comme c’est difficile à tester correctement, on finit par utiliser des conteneurs
    Redbean et Cosmopolitan libc m’ont semblé être ce qui se rapprochait le plus d’une “solution” à ce problème. Si l’on veut que les utilisateurs déploient une app facilement et de manière fiable, les conteneurs ont un avantage compétitif, et avec eux arrivent aussitôt plus de 100 Mo sur disque et un moteur de conteneurs
  • Si l’on pousse la logique du “parce qu’on peut” jusqu’à des essaims de robots tueurs IA, on obtient Slaughterbots
    Tant que la concurrence entre États ou entreprises reste le principe central du développement technologique, il sera difficile de maîtriser les crises mondiales comme le changement climatique, la destruction des écosystèmes ou l’IA létale. Nous avons besoin de collaboration et de coopération comme principes d’organisation au plus haut niveau ; la concurrence crée d’immenses externalités négatives à l’échelle de la planète
  • Je ne suis pas d’accord. La cause, ce sont les frameworks et les fonctions de sécurité des systèmes d’exploitation, par exemple la télémétrie, ainsi que leurs bibliothèques
    Lazarus, c’est-à-dire les programmes écrits en Free Pascal, tourne très vite même sur des Windows récents comme Windows 11. Pour la vitesse et la stabilité, le mieux est de maintenir des logiciels de bureau écrits pour un objectif précis
    Toute modernisation logicielle — qu’il s’agisse du matériel ou des frameworks — agit comme une taxe imposée à l’ensemble des fonctionnalités existantes
  • J’aime bien l’expression “chemin de moindre résistance”. On a l’impression que ce chemin a été abondamment saupoudré de développement piloté par le CV
    La complexité s’est accumulée exactement au mauvais endroit

• Ce type de plainte revient sans cesse, mais en pratique, presque personne ne souhaite vraiment changer cet état de fait
  Les développeurs aiment le Web, cette plateforme de calcul généraliste entièrement intégrée et connectée, et les utilisateurs semblent ne pas trop se soucier des performances tant que c’est suffisamment correct. Au final, on tolère que le logiciel se dégrade jusqu’au point où il n’agace pas trop les utilisateurs
  Les dirigeants non plus ne s’intéressent pas à la création de meilleurs logiciels si un logiciel suffisamment bon existe déjà. Rien ne change tant que quelqu’un ne juge pas qu’une rupture brutale est nécessaire, et quel que soit le point de vue, il y a peu d’incitations au changement

  • Les gens se plaignent bien des performances et de la taille des téléchargements, mais ils l’expriment généralement en parlant des effets secondaires. En demandant pourquoi leur ordinateur portable chauffe, ou pourquoi leur iPhone “se fige”
    Les personnes qui téléchargent de grosses apps sur un téléphone au signal faible, qui vivent dans des zones où Internet est instable, ou qui utilisent de vieux appareils parce qu’elles ont de faibles revenus ou vivent dans des pays en développement, sont frustrées par les apps lourdes et lentes. Si vous avez l’impression que les gens ne se soucient pas des performances ni de la taille des apps, vous posez peut-être les mauvaises questions aux mauvaises personnes
  • L’embonpoint logiciel n’est pas un phénomène nouveau. On s’en plaint au moins depuis le milieu des années 1990, et les plus anciens diront que cela remonte aux années 1980, voire 1970
    Avec le temps, seuls ceux qui se plaignent finissent par sembler atypiques ; les autres mettent à niveau, acceptent l’embonpoint ou continuent d’utiliser d’anciens logiciels
    Cela dit, il faut aussi regarder ce que cet embonpoint apporte. Si Google Docs n’avait été qu’un clone de Word, il n’aurait pas été beaucoup utilisé, mais certains l’utilisent parce qu’il est gratuit, accessible depuis plusieurs appareils et permet une collaboration fluide
    Et une partie de ce qui ressemble à de l’embonpoint correspond en réalité à des gains de confort. Les polices proportionnelles qui restent belles quelle que soit la taille, les polices Unicode, le traitement de documents plus gros que la mémoire disponible, le passage entre documents de travail et ressources, ou encore la protection mémoire consomment beaucoup de ressources, mais améliorent la qualité de vie
  • Je me demande si c’est vraiment le cas. Les développeurs Web, peut-être, mais je n’ai presque jamais fait de développement Web direct. L’interface Web est un choix, et le grand moteur semble être la nécessité commerciale de vouloir des revenus d’abonnement et d’éviter les ventes ponctuelles
    Le monde moderne fondé sur le cloud, ou à moitié en ligne, est assez artificiel du point de vue de l’utilisateur, et lorsqu’il n’y a pas besoin de monétisation, comme avec OpenOffice, on peut rester une application desktop
  • L’une des startups qui a réussi était une application monopage qui téléchargeait un bundle de 5 Mo et préchargeait les données ; son démarrage prenait près de 10 secondes
    Personne ne s’en plaignait, et même lorsque les performances de certaines parties de l’app étaient médiocres, les réclamations des clients étaient rares. Les plaintes ne commençaient à apparaître qu’autour de 60 secondes de chargement
    Malgré cela, le logiciel résolvait un problème très précieux en ramenant à quelques minutes un travail qui prenait une semaine, si bien que les clients en faisaient l’éloge. Quand la concurrence s’est intensifiée, il a fallu l’améliorer, mais la plupart des gens ne s’en souciaient vraiment pas et c’était toujours tout en bas des priorités
  • C’est lorsqu’on utilise un logiciel qui n’est pas tombé dans ce piège que cette différence se ressent le plus. Des systèmes comme MYOB EXO/CRM ou SAP ERP ont fait évoluer très lentement des bases de code vieilles de plusieurs décennies ; ce sont en pratique des technologies des années 2000, donc encore pénibles à utiliser, mais cela devient un énorme avantage
    C’est amusant d’ouvrir le gestionnaire des tâches et de voir qu’ils n’utilisent que 20 à 30 Mo de RAM, alors même qu’une bonne partie de la base de données courante est chargée. VLC et Blender sont des exemples similaires

• Il est intéressant de voir que la plupart des gens blâment les développeurs, alors qu’en réalité ce sont entièrement des décisions business
  Le passage au cloud se fait parce que les entreprises aiment les revenus stables de l’abonnement, et parce que les clients entreprises n’ont pas à embaucher d’équipe IT, tandis que la responsabilité est externalisée, ce qui leur permet d’exiger une disponibilité élevée. Les performances doivent simplement être “acceptables” pour l’utilisateur final
  Les clients qui refusaient les mises à niveau des logiciels on-premise ont entraîné de longs cycles de maintenance et une infinité de correctifs, et développer une seule fois pour le Web est plus avantageux économiquement que d’avoir des développeurs et des testeurs séparés pour chaque plateforme. La seule expertise des développeurs ne peut pas changer ces forces fondamentales

  • Au bout d’un certain temps, ce logiciel fonctionne simplement bien pour le client. Photoshop en est un bon exemple
    On ne pourra pas utiliser les dernières fonctionnalités tape-à-l’œil, mais sur une machine Win7, CS4 reste utilisable sans coût supplémentaire
  • On peut créer des apps Web efficaces même sur le cloud. Au fond, ce ne sont que des serveurs
    Le problème vient du fait que les développeurs développent sur des machines aux performances inaccessibles aux utilisateurs, et ne se soucient pas des performances ni du code efficace
  • Je pense que beaucoup de développeurs prendraient les mêmes décisions. Maintenir séparément des versions par plateforme du même logiciel est pénible, et gérer des serveurs grignote du temps de développement

• Au début des années 90, MS Word tenait sur quelques disquettes, et il me semble que l’exécutable principal faisait 2 Mo. Il tournait très bien même sur un 386 à 16 MHz avec seulement 2 Mo de RAM au total.
  On faisait déjà alors la plupart de ce qu’on fait aujourd’hui ; il ne manquait guère qu’un correcteur grammatical. Désormais, on compte en Go, c’est 1000 fois plus gros, et je ne sais pas ce qu’on y a gagné. Non seulement on s’est perdus, mais on ne sait même plus quelle était la destination.

  • Ce qu’on a gagné, ce sont des fonctionnalités et du graphisme.
    Par exemple, rien que dict.words sous Linux fait 4,8 Mo, et Arial Unicode est une police d’environ 20 Mo. Une seule icône de l’app sur laquelle je travaille fait 400 Ko, et le gestionnaire Google Crashpad pour le traitement des crashs fait aussi quelques Mo.
    Un écran 4K en vraies couleurs est 138 fois plus grand qu’un écran 640x480 en 16 couleurs.
  • Il y a quelques années, pour un poisson d’avril, j’avais mis des images disque DOS/Windows 3.11 sur un serveur de démarrage réseau PXE. Elles incluaient un Word 6 for Windows fonctionnel, et l’image compressée gzip tenait dans 12 Mo.
    Les PC de l’époque pouvaient démarrer sans UEFI, et avec une bonne configuration, Windows 3.11 se lançait presque instantanément, tout comme Word.
    Le Word actuel a ajouté pas mal de toutes petites fonctionnalités et quelques grosses, mais je suis convaincu que si Microsoft s’en souciait, ils pourraient réduire l’usage mémoire d’un facteur 10. Il n’y a simplement pas d’incitation. Les ordinateurs sont rapides, la mémoire est abondante, et comme on ne dépend plus des disquettes, cela ne fait qu’ajouter du coût.
    Je pense que l’obésité logicielle pourrait avoir un impact environnemental non négligeable, mais rien ne changera tant qu’il n’y aura pas un mécontentement assez fort, ou quelque chose comme une loi de l’UE anti-obésité logicielle.
    J’ai aussi vu récemment sur GitHub le code source de MS Word for Windows 1.0. La publication originale se trouve au Computer History Museum et peut être consultée ici : https://computerhistory.org/blog/microsoft-word-for-windows-.... C’était du C pur, avec de grandes parties en assembleur, mais le code était d’une saleté sans commune mesure avec les standards, patterns et fonctionnalités de langage C/C++ actuels.
  • Un jour, par nostalgie, j’ai lancé Word 5.1 sur un vieux PowerBook Duo arrivé pour être mis au rebut.
    J’ai déjà lu cette formule : le logiciel est comme un gaz, il se dilate jusqu’à remplir l’espace disponible.
    C’est pareil avec les distributions live. Avant, elles faisaient 700 Mo pour tenir sur un CD-R ; maintenant, il devient difficile d’en trouver une qui tienne sur une clé USB de 2 Go. Cela dit, c’est réjouissant de voir le “minimal” gagner du terrain.
  • Dans mon entreprise, le fichier Docker qui exécute du code de machine learning fait 6 Gio. Et il n’inclut même pas les fichiers de modèle.
    Nvidia, qu’est-ce que vous nous faites télécharger au juste ? Des milliers de combinaisons de code généré qu’on n’utilisera jamais ?
  • Les fonctionnalités de Word 6 sont, pour l’essentiel, celles qu’on utilise encore dans le Word le plus récent.
    Simplement, on met plus de temps à trouver ce qu’on veut au milieu de toutes les fonctionnalités lourdes qui ont été ajoutées.

• Les logiciels minimalistes existent, mais les gens ne les choisissent pas beaucoup. On passe pas mal de temps à sélectionner prudemment ses dépendances, et cela mène à des stacks légères et performantes.
  Ces temps-ci, j’aime des outils comme Lua, SQLite, Fennel[0], Althttpd[1], Fossil[2] et Mako Server[3]. On peut utiliser gratuitement d’excellents logiciels légers, stables et efficaces, mais il faut s’écarter un peu des sentiers battus. Ce ne sont pas les choses dont on entend le plus souvent parler sur Stack Overflow.
  Pour le frontend, je suis un peu partagé. Je préfère les applications natives et les pages web, mais j’utilise Tiddlywiki tous les jours, et je pense que les web apps ont leur place. Cela dit, un onglet contenant un fichier Tiddlywiki de 6 Mo consomme 155 Mo de RAM, tandis qu’une session Emacs très personnalisée n’en utilise que 88 Mo ; je partage donc le constat de l’auteur.
  [0]: https://fennel-lang.org/
  [1]: https://sqlite.org/althttpd/doc/trunk/althttpd.md
  [2]: https://fossil-scm.org/home/doc/trunk/www/index.wiki
  [3]: https://makoserver.net/

  • Lua est l’outil de programmation le plus sous-estimé que je connaisse. Maîtriser Lua est l’une des meilleures façons de faire progresser ses compétences en programmation.
    Bien sûr, on peut aussi mal l’utiliser, mais il est presque stupéfiant de voir à quel point les programmes Lua peuvent être petits et efficaces par rapport à la plupart des autres langages.

• À mon avis, le problème ressemble à peu près à ceci : un dirigeant d’entreprise estime que, pour être compétitifs, les développeurs ont besoin du meilleur matériel, et ceux-ci construisent des web apps sur des ordinateurs portables hautes performances avec 128 Go de RAM fournis par l’entreprise.
  Ensuite, ils ne testent pas dans un environnement comme le PC familial de 2010 utilisé par leur père, ou pas assez souvent ni assez rigoureusement pour se rendre compte qu’une grande partie de l’application y est cassée ou inutilisable.

  • C’est pareil pour la connexion réseau. L’expérience ne peut pas être la même entre quelqu’un qui utilise l’app au bureau avec du Wi‑Fi 7 et une fibre gigabit symétrique, et quelqu’un qui l’utilise avec le routeur Wi‑Fi médiocre d’un immeuble et une connexion grand public.
  • C’est facile à corriger. Pendant le développement, on configure les outils de développement en mode mobile et avec une connexion limitée.
    Cela met alors au premier plan le mobile first responsive, l’espace d’écran limité et les problèmes potentiels liés aux mauvaises connexions.
    En général, quand on signale le problème au responsable produit, il l’écarte simplement. On peut donc reformuler le troisième point ainsi : “on teste aussi sur le PC familial de 2010, mais ce n’est pas un sujet pour les parties prenantes les plus importantes”.
  • Une partie de mon travail actuel consiste à tester sur du vieux matériel ou du matériel peu performant, sur de vieux navigateurs encore utilisés, et surtout en environnement mobile.
  • Ce n’est pas une supposition complètement à côté. Mais le texte lui-même traitait d’un problème imaginaire.
  • À ce sujet, je me demande si les ingénieurs Google Android utilisent vraiment des téléphones Android pour tester. J’ai l’impression que la plupart sont des utilisateurs Apple.

• Récemment, nous avons migré une vieille page, auparavant en HTML pur généré côté backend, vers React, et un simple menu déroulant contenant environ un millier d’éléments mettait plusieurs secondes à s’ouvrir. Avant, la page entière s’ouvrait en environ 100 ms.
  Au début, quelqu’un a proposé de n’afficher que les 100 premiers éléments et de ne lancer le rendu qu’après que l’utilisateur a saisi trois caractères. C’est un peu la réalité d’aujourd’hui.
  Bien sûr, en pratique, nous avons corrigé le très mauvais code React pour que le rendu soit instantané.

  • Oui. C’est courant. Pendant que les articles sur les performances, comme le temps d’affichage initial, se multiplient, React a créé toute une nouvelle catégorie de problèmes de ce genre.
  • Il suffit d’utiliser un framework de rendu côté serveur comme Turbo. J’ai beaucoup utilisé les frameworks côté client que les gens veulent aujourd’hui, mais dès qu’il y avait beaucoup de données, ils étaient tous lents ; Turbo était la seule exception.
  • Une liste de sélection avec des milliers d’options semble offrir une expérience utilisateur désastreuse.
    Si un nouveau framework rend le problème tellement évident que cela donne à quelqu’un une vraie raison de le corriger, cela devient plutôt une raison supplémentaire d’utiliser ce framework.

• À force de mettre en avant des textes comme « idiomatic Ruby » ou « l’optimisation prématurée est la racine de tous les maux », et de dire que « le temps de développement compte plus que les performances », on en arrive là.
  Avant, il y avait des développeurs qui écrivaient un meilleur code en moins de temps.

  • Je ne suis pas d’accord. Aujourd’hui, il existe bien plus de ressources qu’autrefois pour aider à écrire du code efficace.
    J’ai aussi vu beaucoup de code ancien absolument affreux, qui ne serait pas écrit aujourd’hui.