Le destin du « petit » open source : l'ère des petites bibliothèques à faible valeur ajoutée comme blob-util est révolue, les LLM en sont le coup de grâce, par Nolan Lawson Le package npm le plus populaire que j'ai jamais écrit est de loin blob-util, qui a environ 10 ans et qui enregistre encore plus de 5 millions de téléchargements par semaine.
Il s'agit d'une petite collection d'utilitaires permettant de travailler avec des blobs en JavaScript. Je l'ai écrit parce que j'ai constaté que les utilisateurs de PouchDB étaient sans cesse perplexes quant à la manière de travailler avec les blobs et de les convertir en chaînes, en ArrayBuffers, etc.
Étant donné qu'environ 80 % des développeurs utilisent désormais l'IA dans leur travail quotidien, blob-util est très certainement le genre de chose que la plupart des développeurs seraient ravis de voir générer par un LLM. Bien sûr, vous pourriez utiliser blob-util, mais vous vous exposeriez alors à une dépendance supplémentaire, avec des risques inconnus en termes de performances, de maintenance et de chaîne d'approvisionnement.
Et bien sûr, Claude se fera un plaisir de vous fournir tous les utilitaires Blob dont vous avez besoin lorsque vous le lui demanderez :
> Écrivez-moi une fonction utilitaire en TypeScript pour convertir un Blob en ArrayBuffer. Elle doit renvoyer une promesse.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | function blobToArrayBuffer(blob: Blob): Promise<ArrayBuffer> { return new Promise((resolve, reject) => { const reader = new FileReader(); reader.onload = () => { if (reader.result instanceof ArrayBuffer) { resolve(reader.result); } else { reject(new Error('Failed to read Blob as ArrayBuffer')); } }; reader.onerror = () => { reject(reader.error); }; reader.readAsArrayBuffer(blob); }); } |
La version de Claude est assez proche de celle de blob-util (ce qui n'est pas surprenant, puisqu'il a probablement été formé sur celle-ci !). Elle est toutefois beaucoup plus verbeuse, vérifiant inutilement si readAsArrayBuffer vous donne réellement un ArrayBuffer (même si cela satisfait TypeScript). Pour être honnête, elle améliore également mon implémentation en rejetant directement avec une erreur plutôt qu'avec l'événement onerror, plus maladroit.
Remarque : pour ceux qui se poseraient la question, oui, Claude a bien suggéré la nouvelle méthode Blob.arrayBuffer(), mais il a également généré ce qui précède pour les « environnements plus anciens ».
Je suppose que certaines personnes y verraient un progrès : moins de dépendances, un code plus robuste (même s'il est un peu plus verbeux), un délai d'exécution plus rapide que l'ancienne approche « rechercher npm, trouver un paquet, lire la documentation, l'installer ».
Je ne suis pas particulièrement fier de cette bibliothèque et je me moque que le nombre de téléchargements augmente ou diminue. Mais je pense que l'approche IA fait perdre quelque chose. Lorsque j'ai écrit blob-util, j'ai adopté une mentalité d'enseignant : le README contient un tutoriel mignon et fantaisiste mettant en scène Kirby, dans toute sa splendeur blob. (À l'époque, j'avais tendance à mettre des personnages Nintendo dans toutes mes créations.)
L'objectif n'était pas seulement de vous fournir un utilitaire pour résoudre votre problème (même si c'est le cas), mais aussi d'apprendre aux gens à utiliser JavaScript efficacement, afin qu'ils comprennent comment résoudre d'autres problèmes à l'avenir.
Je ne sais pas dans quelle direction nous allons avec l'IA (enfin, environ 80 % d'entre nous ; aux autres, je vous salue et vous souhaite bonne chance !), mais je pense que c'est un avenir où nous privilégions les réponses instantanées plutôt que l'enseignement et la compréhension. Il y a moins de raisons d'utiliser quelque chose comme blob-util, ce qui signifie qu'il y a moins de raisons de l'écrire en premier lieu, et donc moins de raisons d'éduquer les gens sur le problème.
Même aujourd'hui, il existe un mouvement visant à placer la documentation dans un fichier [c]llms.txt[c], afin que vous puissiez simplement pointer un agent vers celui-ci et épargner à vos cellules cérébrales l'effort de déchiffrer la prose anglaise. (Est-ce encore de la documentation ? Qu'est-ce que la documentation ?)
Conclusion
Je crois toujours en l'open source, et je continue à m'y consacrer (par à-coups). Mais une chose m'apparaît désormais clairement : l'ère des petites bibliothèques à faible valeur ajoutée comme blob-util est révolue. Elles étaient déjà en voie de disparition grâce à Node.js et au navigateur qui prenait en charge de plus en plus de leurs fonctionnalités (voir node:glob, structuredClone, etc.), mais les LLM ont donné le coup de grâce.
Cela signifie qu'il y a moins d'occasions d'utiliser ces bibliothèques comme tremplin pour la formation des utilisateurs (Underscore.js avait également cette philosophie), mais ce n'est peut-être pas grave. S'il n'est pas nécessaire de trouver une bibliothèque pour, par exemple, regrouper les éléments d'un tableau, alors peut-être qu'il n'est pas nécessaire d'apprendre le fonctionnement de ces bibliothèques. De nombreux développeurs de logiciels diront qu'il est inutile de demander à un candidat d'inverser un arbre binaire, car cela ne se produit jamais dans le travail quotidien. On peut donc peut-être en dire autant des bibliothèques utilitaires.
J'essaie toujours de déterminer quels types d'open source méritent d'être développés dans cette nouvelle ère (indice : ceux qu'un LLM ne peut pas simplement recracher sur commande) et où l'éducation fait le plus défaut. Je pense actuellement que la plus grande valeur réside dans les projets plus importants, les projets plus inventifs ou les sujets plus spécialisés qui ne sont pas couverts par les données d'entraînement d'un LLM. Par exemple, quand je repense à mon travail sur fuite et à divers articles de blog sur la recherche de fuites de mémoire, je suis assez satisfait qu'un LLM ne puisse pas reproduire cela, car cela nécessite des recherches novatrices et des techniques créatives. (Mais qui sait : peut-être qu'un jour, un agent sera capable de se cogner la tête contre les instantanés de la pile Chrome jusqu'à ce qu'il trouve la fuite. Je le croirai quand je le verrai.)
Ces derniers temps, on s'est beaucoup interrogé sur la place de l'open source dans un monde dominé par les LLM, mais je vois encore des gens repousser les limites. Par exemple, beaucoup de détracteurs pensent qu'il est inutile d'écrire un nouveau framework JavaScript, car les LLM sont tellement entraînés sur React, mais voilà que l'infatigable Dominic Gannaway écrit Ripple.js, un autre framework JavaScript (avec quelques nouvelles idées, en plus !). C'est le genre de chose que j'aime voir : des humains qui rient au nez de la machine et continuent à faire leur truc d'humains.
Donc, s'il y a une conclusion à ce billet de blog décousu (excusez mon cerveau humain mou, je n'ai pas utilisé de LLM pour l'écrire), c'est simplement celle-ci : oui, les LLM ont rendu certains types d'open source obsolètes, mais il reste encore beaucoup d'open source à écrire. Je suis impatient de voir quelles idées nouvelles et inattendues vous allez trouver.
Source : "The fate of “small” open source"
Et vous ?
Pensez-vous que ces affirmations sont crédibles ou pertinentes ? Quel est votre avis sur le sujet ?Voir aussi :
Le produit open source est un outil de marketing, et souvent les programmeurs open source travaillent gratuitement pour enrichir les grandes entreprises technologiques, par Robert Vitonsky L'Open Source serait en difficulté et ce n'est pas la faute des grandes entreprises technologiques, d'après Jan Kammerath Réflexions sur l'avenir du développement de logiciels, suite à l'arrivée des grands modèles de langage (LLM) capables de générer du code, par Sheshbabu Chinnakonda
Vous avez lu gratuitement 17 079 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.