3 points par GN⁺ 2024-04-30 | 1 commentaires | Partager sur WhatsApp

La difficulté d’ouvrir des fichiers Microsoft Word dans Google Docs

  • Le père de l’auteur a dû installer Word sur son ordinateur portable pour travailler sur des fichiers de documents Microsoft Word
  • L’auteur lui a proposé Google Docs
    • parce qu’il avait déjà un compte Google, que c’est facile à utiliser, basé sur le cloud et synchronisé automatiquement
  • Mais lorsqu’il a ouvert un fichier de document d’environ 30 Mo dans Google Docs, Chrome ou Google Docs avaient du mal à le gérer, au point qu’il fallait plusieurs secondes pour que le texte saisi s’affiche à l’écran
  • Finalement, LibreOffice a été installé, et cela y fonctionnait très rapidement

Réflexion sur les standards logiciels d’aujourd’hui

  • L’auteur se demande si le développement logiciel n’est pas en train de régresser du point de vue des performances
    • et si les outils, frameworks et langages modernes les plus élégants ne nous font pas reculer en matière d’efficacité
  • Les exigences matérielles augmentent pour faire tourner des web apps et des navigateurs
    • ce qui aurait été inutile s’il n’existait que des applications nativement conçues
    • pourquoi les téléphones mobiles ont-ils besoin de 8 Go ou 16 Go de RAM ?
  • Le web aurait besoin d’un rendu natif plutôt que d’un simple wrapper autour d’un moteur de rendu d’interface
    • si même un ordinateur portable bien équipé ne peut pas ouvrir un fichier Word de 30 Mo dans Google Docs, c’est parce que le navigateur exige davantage de mémoire et de CPU
  • Nous semblons avoir perdu la manière de développer des applications optimisées, efficaces et performantes. Il faut corriger ce problème
    • l’ordinateur Apollo de 1966 avec 2 Ko de RAM a envoyé l’humanité sur la Lune, mais en 2024, un navigateur ne peut pas gérer un fichier de document de 30 Mo
  • L’auteur se concentre sur le web, car aujourd’hui toute l’industrie mise sur les applications PWA pour l’avenir

L’importance de l’optimisation des API

  • L’optimisation des API est importante aussi bien pour les web apps que pour les applications natives, car les performances des API peuvent contribuer aux performances globales de l’application
  • Le produit de l’auteur, Onradar(https://onradar.io), aide à l’optimisation grâce au monitoring des API
    • Onradar fournit une surveillance de disponibilité des API et un monitoring basé sur des flux
    • Dans l’éditeur de flux, il est possible de créer des scénarios utilisateur avec les API concernées et de laisser Onradar les tester 24/7
    • Des alertes sont fournies lorsqu’un incident se produit

L’avis de GN⁺

  • Les problèmes de compatibilité entre Google Docs et MS Office sont signalés depuis longtemps. Ils ne sont toujours pas parfaitement résolus, ce qui cause des désagréments aux utilisateurs. Il serait souhaitable que les deux entreprises coopèrent plus activement pour résoudre ce problème
  • Résoudre les problèmes de performance des web apps par une simple hausse des spécifications matérielles n’est pas une solution de fond. Il faut un développement logiciel capable d’utiliser efficacement des ressources limitées
  • Défendre les applications natives est une approche possible, mais améliorer les performances des web apps tout en conservant les avantages du web serait une meilleure direction. La portabilité et l’accessibilité des web apps sont des atouts difficiles à abandonner
  • L’optimisation et le monitoring des API sont des éléments importants qui peuvent contribuer à améliorer les performances de l’ensemble du système. À l’heure où l’architecture microservices devient la norme, l’attention portée à la couche API ne peut que croître
  • La comparaison avec l’époque d’Apollo ne semble pas vraiment appropriée. Il est difficile de mettre sur le même plan le contrôle d’un vaisseau spatial et le traitement de texte. Les logiciels actuels sont devenus tellement vastes et complexes qu’il est difficile d’attendre l’efficacité de l’époque d’Apollo

1 commentaires

 
GN⁺ 2024-04-30
Avis Hacker News

Résumé :

  • Apple et Microsoft entravent le développement d’applications natives avec l’obligation d’avoir un compte développeur, d’acheter des certificats de signature binaire, de partager les revenus, etc. Le web est une alternative bien plus simple et moins coûteuse.
  • Grâce à la loi de Moore, le logiciel a profité pendant des décennies des progrès du matériel sans réel effort. Cela a été à la fois une bénédiction et une malédiction.
  • Les développeurs aiment une plateforme informatique universelle, entièrement intégrée et connectée : le web. Les utilisateurs s’en soucient peu tant que les performances sont suffisamment bonnes. Créer de bons logiciels n’est pas ce qui compte le plus.
  • Les décisions métier en sont la cause principale :
    1. Migration vers le cloud — les entreprises préfèrent les abonnements récurrents, et les clients n’ont pas besoin d’embaucher directement une équipe IT
    2. Les clients refusent les mises à niveau des logiciels on-premise, ce qui allonge les cycles de maintenance et entraîne une succession sans fin de correctifs
    3. Le développement web coûte moins cher que le développement multi-plateforme
  • Au début des années 90, MS Word était distribué sur disquette et son exécutable faisait 2 Mo. Aujourd’hui, on mesure cela en Go, sans qu’il soit très clair de voir ce qui s’est amélioré.
  • Il existe des logiciels légers, mais ils sont rarement choisis. On peut citer d’excellents logiciels légers comme Lua, SQLite, Fennel, Althttpd, Fossil et Mako Server.
  • Côté frontend, les applications natives et les pages web sont préférées, mais des web apps comme Tiddlywiki ont aussi leurs avantages. Elles consomment toutefois encore plus de ressources qu’Emacs.
  • Il y a eu un cas où le rendu d’un menu déroulant lors d’une transition de page React prenait beaucoup de temps. Le problème a finalement été résolu en modifiant le code React.
  • Comme les entreprises fournissent aux développeurs du matériel haut de gamme, il y a un risque de ne pas tester suffisamment sur de vieux PC ordinaires.
  • On voit beaucoup de billets de blog sur le « code idiomatique » ou sur l’idée que « l’optimisation des performances est la racine du mal », et on accorde davantage d’importance au temps de développement. Autrefois, il y avait des développeurs capables d’écrire plus vite un code meilleur.