Je m’inquiète pour Bun

 (wwj.dev)
4 points par GN⁺ 7 시간 전 | 3 commentaires | Partager sur WhatsApp
  • Bun est un runtime JavaScript rapide et un outil qui facilite le travail en TypeScript, mais les inquiétudes grandissent quant au fait qu’il puisse subir l’influence de la politique produit et du mode de fonctionnement d’Anthropic depuis son acquisition en décembre 2025
  • L’annonce de l’acquisition précisait que Bun resterait open source sous licence MIT et continuerait à être développé par la même équipe. Comme Claude Code est distribué sous la forme d’un exécutable Bun, Anthropic indiquait aussi avoir un intérêt direct à maintenir Bun dans un excellent état
  • Depuis avril 2026, Claude Code fait l’objet de critiques sur la baisse de qualité, des comportements restrictifs, des limitations envers les harness tiers, une tarification confuse et une communication lente. Le postmortem engineering d’Anthropic attribue ces problèmes à des soucis de couche produit, comme une baisse de la valeur d’effort de raisonnement par défaut et des changements de prompt
  • Selon des articles de TechCrunch et de Gigazine, Claude Code peut exiger un surcoût pour prendre en charge des harness tiers comme OpenClaw, ou refuser des requêtes et déclencher une facturation supplémentaire sur la seule présence de la mention OpenClaw dans l’historique git, révélant ainsi des comportements inattendus
  • L’inquiétude ne vient pas de Bun lui-même ni de l’équipe Bun, mais de la possibilité que les politiques d’Anthropic finissent par imprégner Bun. Certains projets migrent donc vers pnpm pour la gestion de paquets et recommandent désormais pnpm pour les nouveaux projets JavaScript et TypeScript

Pourquoi les inquiétudes autour de Bun grandissent

  • Bun est un runtime JavaScript rapide et pragmatique, qui simplifie le travail en TypeScript pour de petits scripts, applications, tests et outils
  • Grâce à des installations rapides, des tests rapides, un meilleur bundling et une chaîne d’outils allégée, c’est un outil dont on espère la réussite comme alternative à Node.js
  • Le cœur de l’inquiétude ne concerne pas la qualité de Bun en elle-même, mais le fait qu’une fois Bun intégré à Anthropic, il puisse être affecté par sa politique produit et sa manière d’opérer

L’acquisition par Anthropic et les attentes initiales

  • Anthropic a acquis Bun en décembre 2025
  • D’après l’annonce, Bun resterait open source sous licence MIT, continuerait à être développé par la même équipe, et sa feuille de route resterait centrée sur des outils JavaScript haute performance et la compatibilité avec Node.js
  • L’annonce comprenait cette phrase : “Claude Code ships as a Bun executable to millions of users. If Bun breaks, Claude Code breaks. Anthropic has direct incentive to keep Bun excellent.”
  • À l’époque, puisque Claude Code fonctionnait sur Bun, on pouvait considérer qu’Anthropic avait une motivation directe à maintenir Bun rapide et fiable
  • Ce raisonnement reste valable, mais une inquiétude est apparue : celle de voir des fissures dans la manière dont Anthropic exploite ses produits logiciels

Le changement de perception de Claude Code

  • La qualité des modèles d’Anthropic en elle-même n’est pas l’inquiétude principale
  • La famille de modèles supposée correspondre à Claude Opus 4.6 est toujours considérée comme solide pour le code, la rédaction, le raisonnement et le développement général
  • Le problème se situe dans la couche produit autour du modèle, et l’idée centrale est que l’utilisabilité actuelle de Claude Code s’est fortement dégradée
  • Il y a environ un an, Claude Code donnait l’impression d’être un outil capable de lire un projet, de produire des modifications ciblées, d’exécuter des commandes, de corriger ses erreurs et de continuer à avancer
  • À l’époque, Claude Code faisait partie des premiers outils de codage IA à donner la conviction que le workflow développeur pouvait passer d’une logique d’autocomplétion à une logique agentique
  • Même en décembre 2025, Claude Code se dégradait déjà, mais restait utilisable, et l’acquisition de Bun pouvait encore se comprendre sous l’angle d’Anthropic en train de construire l’avenir des outils de codage

Les problèmes de Claude Code depuis avril 2026

  • En avril 2026, les développeurs ont commencé à pointer du doigt la qualité de Claude Code, ses comportements restrictifs, les limitations imposées aux harness tiers, une facturation confuse et une communication lente
  • Anthropic a publié un postmortem engineering qui attribue les causes à des problèmes de couche produit : baisse de la valeur d’effort de raisonnement par défaut, bug de session ancienne et modifications de prompts ayant nui à la qualité du code
  • Cette analyse postmortem a été perçue comme préférable à un simple passage sous silence, et comme l’un des rares cas où Anthropic reconnaissait sa propre responsabilité
  • D’après TechCrunch, Anthropic a informé les abonnés de Claude Code qu’ils devraient payer un supplément pour le support d’OpenClaw et d’autres harness tiers
  • D’après Gigazine, la simple présence de OpenClaw dans l’historique git peut suffire à faire rejeter une requête par Claude Code ou à déclencher une facturation supplémentaire
  • L’article cite des propos de Theo selon lesquels la simple mention d’OpenClaw dans un commit récent, à l’intérieur d’un blob JSON, pouvait suffire à déclencher ce comportement lorsqu’on appelait directement claude -p "hi" dans un dépôt vide
  • La scène correspondante peut aussi être vérifiée dans cet extrait vidéo
  • Ce genre de comportement donne l’impression d’un produit où des changements sont mis en production sans avoir été suffisamment éprouvés en interne au niveau de l’expérience réelle de codage
  • Vu de l’extérieur, Claude Code semble prendre une mauvaise direction, avec davantage de restrictions, une tarification étrange et des comportements inattendus selon le texte des commits
  • Cette évolution est décrite comme une enshittification

L’inquiétude qui s’étend à Bun

  • Bun est profondément intégré à Claude Code, et comme Claude Code semble se détériorer, l’inquiétude naît de voir Bun suivre la même direction
  • Cela ne signifie pas que Bun soit mauvais ni que l’équipe Bun ait perdu son intérêt
  • Le problème est que, plus Bun et son équipe sont intégrés à Anthropic, plus les politiques d’Anthropic risquent de les accompagner
  • Si les politiques qui semblent avoir détérioré Claude Code affectent aussi Bun, on pourrait voir apparaître chez Bun les mêmes signes d’un produit dont l’équipe ne semble pas réellement utiliser ce qu’elle construit
  • Cette seule possibilité suffit déjà à rendre plus difficile, sur certains projets, la décision de continuer à utiliser Bun avec confiance

Migration vers pnpm pour le moment

  • Bun offre plus de fonctionnalités que pnpm dans un seul outil
  • Bun prend en charge TypeScript sans étape de build séparée, fournit un bundler à la place de Vite et des fonctions de test à la place de vitest
  • Le fait de rassembler ces fonctionnalités dans une seule chaîne d’outils constitue en pratique un avantage majeur
  • pnpm n’est ni un remplaçant de Node.js ni un remplaçant de Bun : c’est seulement un gestionnaire de paquets
  • Cela dit, si dans le travail quotidien l’usage principal de Bun est la gestion de paquets, alors installations rapides, bon support du monorepo et usage raisonnable du disque sont des qualités que Bun et pnpm offrent tous deux
  • Une partie des projets qui utilisaient Bun choisissent donc aujourd’hui de s’en éloigner pour passer à pnpm
  • À la question de savoir quoi recommander aujourd’hui pour un projet JavaScript ou TypeScript, la réponse devient pnpm

Ce n’est pas une recommandation de quitter Bun

  • Même si certains projets sont en train de quitter Bun, il ne faut pas prendre cela comme une réponse universelle
  • Pour les nouveaux projets, pnpm est un choix cohérent
  • Pour les projets existants, il reste possible de conserver Bun tant qu’il n’existe pas de raison suffisamment forte d’en partir

Ce qui reste possible, et la conclusion

  • L’espoir demeure que Bun reste excellent, que l’équipe Bun continue à produire un bon travail, et qu’Anthropic lui laisse l’autonomie nécessaire pour prendre des décisions adaptées à l’écosystème JavaScript
  • Anthropic dispose d’argent, d’une force de distribution et de raisons concrètes de se soucier des performances et de la fiabilité de Bun
  • Bun pourrait encore sortir renforcé de cette situation
  • Mais la confiance dans la situation actuelle est plus faible qu’en décembre 2025
  • L’ancien Claude Code ressemblait à une preuve qu’Anthropic comprenait les outils pour développeurs ; il apparaît maintenant plutôt comme un signal d’alerte montrant qu’Anthropic pourrait ne pas savoir ce qu’il faut pour maintenir et améliorer durablement un produit
  • Bun reste excellent, mais il est difficile de savoir dans quelle direction il ira ensuite
  • La situation pourrait être totalement différente dans un an, et il est prévu de vérifier à nouveau si cette prévision s’est révélée juste

À lire aussi

3 commentaires

 
click 3 시간 전

Je reconnais que grâce à Bun, Node a lui aussi beaucoup évolué, mais quand je vois des IA se renvoyer la balle à coups de PR dans le dépôt, j’ai peur de tomber sur une régression minée qui casse des choses qui marchaient jusque-là.
Avant le rachat par Anthropic, j’utilisais surtout Bun, mais maintenant je suis revenu à Node.
Je pense toujours que la fonctionnalité sfx est une killer feature, mais si on n’en a pas besoin, je ne vois pas vraiment de raison d’utiliser Bun tout de suite.
 
GN⁺ 7 시간 전
Avis Hacker News

  • Je ne suis pas d’accord avec l’idée générale : même avant son rachat, Bun devait bien finir par trouver un modèle de monétisation un jour.
    Ce n’est pas parce que la maison mère montre de mauvaises pratiques dans un autre logiciel, Claude Code, que Bun va forcément devenir pire. Je comprends l’inquiétude, mais je reste pour l’instant optimiste sur Bun.
    Claude Code est le produit cœur d’Anthropic et sa croissance est extrêmement rapide, donc le moindre petit changement peut vite se transformer en problème de facturation. Bun, à l’inverse, est un runtime JavaScript qui peut se concentrer sur le fait de devenir le meilleur runtime possible, et comme il n’a pas d’impact direct sur le chiffre d’affaires ou la rentabilité d’Anthropic, il y a moins de risque de le voir recevoir en urgence des correctifs comme Claude Code à cause d’abus.
    On ne sait toujours pas clairement ce qui se passera dans les prochaines années, mais juste après le rachat, à ce stade, je ne suis pas particulièrement inquiet.

    • Je trouve intéressant que les gens acceptent si vite l’explication par les abus. On sait depuis longtemps que les grands labos IA ne gagnent pas d’argent avec les utilisateurs qui consomment beaucoup d’abonnements, quel que soit l’agent ou l’outil d’exécution utilisé. Le juste prix rentable, c’est une facturation au token basée sur l’usage.
      Ces labos cherchent à tuer la concurrence, parce que les outils d’exécution tiers risquent de transformer les grands modèles de langage sous-jacents en commodité, et en parallèle ils jouent une partie de chicken game pour voir lequel pourra supporter des pertes le plus longtemps.
      Au final, il faudra bien fixer un vrai prix pour les produits, et d’ici là ils n’ont plus qu’à espérer avoir éliminé toute concurrence. Mais ils semblent déjà en train de perdre cette partie. Les modèles utiles deviennent plus petits chaque année et leur coût d’exécution baisse, au point qu’on a déjà franchi le seuil où le développement d’outils d’exécution tiers peut continuer même sans base d’utilisateurs abonnés.
      Leur pari central — « une IA utile nécessite un matériel extrêmement coûteux » — a déjà échoué, et leur second pari, qui consiste à enfermer les utilisateurs dans l’écosystème puis à monétiser plus tard, échouera aussi. Au bout du compte, ils devront se battre uniquement sur la qualité intrinsèque du produit, et c’est bien moins rentable.
    • L’idée même que « Bun devait de toute façon trouver un moyen de se monétiser un jour » n’a aucun sens, selon moi. Le fait que des gens en soient déjà venus à dépendre d’un runtime JavaScript censé être monétisé un jour est étrange, et le fait de garder encore espoir après son rachat par l’une des entreprises les plus déficitaires d’un secteur déjà le plus déficitaire de l’industrie l’est tout autant.
    • J’ai l’impression que vous sous-estimez l’impact des politiques et de la culture d’une entreprise sur ses produits.
      Certaines équipes misent désormais tout sur l’IA, jusqu’à adopter une logique du type « ne regardons même plus le code nous-mêmes ». Je l’ai vu en vrai, et le résultat est à peu près celui qu’on imagine. Jusqu’à un certain point ça tourne, mais surtout quand chaque équipe a son propre vocabulaire technique et sa propre compréhension, la complexité s’accumule, les erreurs aussi, et on finit sans personne ni équipe qui sache réellement comment le logiciel fonctionne.
      Il existe aussi une tendance où il n’y a plus de test humain ni d’assurance qualité, et où, en plus des tests unitaires et d’intégration, on laisse l’IA piloter le navigateur ou les outils. La culture d’Anthropic pourrait changer la façon dont l’équipe Bun opère et réfléchit.
      Si cette culture et cette façon de penser deviennent la norme, soit les modèles devront devenir bien meilleurs, soit la qualité logicielle baissera.
      Matt Pocock a une très bonne présentation : https://youtu.be/v4F1gFy-hqg
      « Le code n’est pas bon marché. Le mauvais code est devenu le plus coûteux qu’il ait jamais été, parce que si votre base de code est difficile à faire évoluer, vous ne pouvez pas profiter de l’abondance que l’IA peut offrir. Sur une bonne base de code, l’IA est vraiment, vraiment performante. »
      Une fois que le mauvais code commence à s’accumuler tout seul, il devient très difficile d’en sortir.
    • Avec la même logique, GitHub aussi devait bien finir par trouver un modèle de monétisation avant son rachat. Dire qu’il serait excessif de penser que GitHub allait se dégrader simplement parce que sa maison mère Microsoft avait eu de mauvaises pratiques avec Embrace, Extend, Extinguish ou MS Windows, et donc qu’on comprend l’inquiétude mais qu’on reste optimiste sur GitHub, ce n’est pas très différent comme argument.
    • Anthropic n’a pas racheté Bun pour l’ensemble de la communauté JavaScript, mais pour protéger et développer son investissement dans Claude Code. Ça paraît évident, mais ça mérite d’être rappelé. À long terme, les résultats suivront les incitations.

  • Je ne comprends pas pourquoi les gens utilisent Deno ou Bun au lieu de Node. C’est bien qu’il y ait des concurrents parmi les runtimes JavaScript, mais je vois mal ce qu’on gagne à quitter Node.
    Bun n’a pas de REPL et son moteur JavaScript est moins bon, Deno ressemble à Node avec un système de permissions limité et pénible, et j’avais même vu qu’il n’avait pas sqlite. Tous les deux ont la réputation d’être rapides, mais seulement sur des benchmarks bien choisis, et sur les charges que j’ai essayées moi-même il y a environ un an, ils étaient tous les deux plus lents que Node.
    Cela dit, quand j’ai livré un petit outil ERP il y a quelque temps, l’outil d’empaquetage de projet en *.exe était clairement plus solide côté Bun, donc j’ai utilisé Bun. Tout était fait en Node avec du JavaScript sans dépendances, et seul le déploiement passait par Bun ; sur ce point précis, l’expérience était nettement meilleure qu’avec Node.

    • Deno a aussi sqlite : https://docs.deno.com/examples/sqlite/
    • L’expérience développeur de Bun est bien meilleure que celle de Node, surtout sur les projets TypeScript.
    • Deno est appréciable parce que l’utilisateur peut simplement l’exécuter sans étape d’installation séparée.

  • En réalité, Bun n’a jamais été particulièrement bien géré. Il y avait beaucoup de bugs et de trous dans chaque fonctionnalité, et à chaque release, on en corrigeait quelques-uns pour en casser d’autres.
    Une simple patch release récente contenait plus de fonctionnalités majeures et de breaking changes que la plupart des logiciels n’en subissent en deux versions majeures.
    Même en l’utilisant essentiellement comme exécuteur de scripts et gestionnaire de paquets npm, la quantité de travail nécessaire pour trouver une « bonne » version est étonnante. Plusieurs patch versions se sont déjà figées pendant l’installation, ce qui m’a empêché de mettre à niveau pendant un temps.
    Il y a environ deux versions mineures, ils semblent avoir complètement cassé les scripts postinstall avec trustedDependencies. Pas un mot dans les notes de release, et personne ne semblait l’avoir signalé dans les issues GitHub. Vers la 1.1, on pouvait faire en sorte que Bun exécute les builds de trustedDependency dans postinstall, mais depuis, ce n’est plus possible et c’est cassé depuis des mois.

    • Il existe une issue GitHub sur le blocage pendant l’installation. Un scanner de sécurité passe la liste complète des dépendances comme argument en ligne de commande, ce qui dépasse ARG_MAX sur les gros monorepos Linux.
      Le spawn se bloque silencieusement sans erreur, et comme le scanner est séparé de postinstall, --ignore-scripts ne sert à rien. C’est cassé au moins depuis la 1.3.5.

  • Je travaille sur Bun, et ce billet me paraît un peu confus. Personnellement comme pour l’équipe Bun, nous utilisons Bun tous les jours et nous l’améliorons en continu, et le rythme de développement a même encore accéléré. Depuis l’arrivée chez Anthropic, la stabilité de Bun s’est nettement améliorée.
    Dans la prochaine version de Bun, il y aura notamment une réduction de 17 MB du binaire Windows x64 [0], une réduction de 8 MB du binaire Linux [1], le flag CLI --no-orphans pour tuer récursivement les processus enfants restants [3], la mise en cache des contextes SSL pour les sockets TCP et Unix côté client, ce qui réduit fortement l’usage mémoire des clients de base de données comme Mongoose/MongoDB [4], un client HTTP/3 et HTTP/2 expérimental pour fetch [5], un support expérimental de HTTP/3 dans Bun.serve() [6], ainsi que la bibliothèque intégrée de traitement d’image Bun.Image [7].
    À cela s’ajoutent des améliorations de fiabilité pour node:fs, Worker, BroadcastChannel et MessagePort.
    Grâce au rachat par Anthropic, Bun n’a plus besoin d’être une activité génératrice de revenus. Claude Code dépend de Bun, et comme beaucoup d’ingénieurs logiciels dépendent de Claude Code pour travailler, il existe une forte incitation à rendre Bun meilleur.
    [0]: https://github.com/oven-sh/bun/pull/30219
    [1]: https://github.com/oven-sh/bun/pull/30098
    [2]: https://github.com/oven-sh/WebKit/pull/211
    [3]: https://github.com/oven-sh/bun/pull/29930
    [4]: https://github.com/oven-sh/bun/pull/29932
    [5]: https://github.com/oven-sh/bun/pull/29863
    [6]: https://github.com/oven-sh/bun/pull/30032

    • Dans ce secteur, les acquisitions débouchent généralement sur une issue plus ou moins inévitable. Le logiciel acquis se dégrade quand les membres de l’équipe d’origine encaissent leur gain puis partent, et la culture existante est remplacée par celle du nouveau propriétaire.
      Bun fera peut-être exception, mais on ne peut pas dire que l’inquiétude soit sans fondement.
      Le CEO d’Anthropic a souvent avancé des prédictions exagérées selon lesquelles l’IA remplacerait presque les programmeurs humains, et Anthropic applique cette croyance à Claude Code au point d’en faire un plat de spaghettis ingérable.
    • La meilleure fonctionnalité apportée récemment par Bun, ce sont les binaires portables. Beaucoup d’utilisateurs sont sur d’anciennes distributions Linux, donc la portabilité est cruciale. Node et Deno exigent des Linux plus récents, ou plus précisément des versions plus récentes de glibc.
    • Dire « je travaille sur Bun » est un énorme euphémisme. J’ai des inquiétudes à propos d’Anthropic, mais tant que Jarred est aux commandes, je ne pense pas que Bun parte dans la mauvaise direction. À mon avis, ils exploitent bien la stabilité et les financements d’une organisation plus grande.

  • J’ai passé quelques heures à migrer le backend d’un site d’aiguisage de couteaux de Bun vers Node, et je suis content d’avoir évité un effet de verrouillage. J’étais assez enthousiaste à propos de Bun au début, mais j’ai progressivement perdu confiance.
    Les fonctionnalités qui vont me manquer sont les requêtes sqlite via des tagged template literals, le fait que Bun.password.verify utilise argon2 par défaut, l’import de HTML, la transformation JSX et le chargement automatique des fichiers .env.
    https://burlyburr.com appelle https://backend.burlyburr.com

    • Node prend aussi en charge les requêtes sqlite via des tagged template literals.
      https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
    • J’imagine qu’il suffit d’utiliser une petite bibliothèque utilitaire pour retrouver les fonctionnalités qui te manqueront. Node intègre déjà au moins SQLite et Argon2, donc si le problème est l’interface, ce sera facile à corriger.
    • Node prend aussi en charge le chargement automatique de .env et sqlite.

  • Je n’ai jamais trouvé que Bun fonctionnait vraiment bien, même avant le rachat. Je continuais à l’utiliser pour de petits scripts, mais je n’aurais pas déployé un service en production avec Bun au travail.
    À cause de problèmes mémoire et d’incompatibilités jamais corrigées, je l’ai toujours vu comme un jouet intéressant qui montrait surtout que Node.js avait encore de la marge pour s’améliorer.
    Par exemple, j’ai longtemps suivi https://github.com/oven-sh/bun/issues/14102, et au final des bibliothèques ont dû ajouter des branches du genre « si c’est Bun, faire x », ce qui est l’exact opposé de la compatibilité.

    • J’ai essayé de l’utiliser en production sur quelques projets, mais dans les deux cas il a fallu revenir de Bun vers Node. L’un avait, comme tu le disais, une grosse fuite mémoire, et l’autre plantait à cause de différences d’API dans des choses comme TextDecoderStream. J’ai décidé de ne pas réessayer avant Bun v2.

  • Avec Claude Code et Anthropic, on a l’impression d’une évolution vers quelque chose qui cherche à cacher de force certaines choses à l’utilisateur. Certains se souviennent sans doute du chaos quand la lecture de xxx.yy est passée d’une lecture d’un fichier à une lecture de un ou deux fichiers.
    D’autres changements de ce type ont suivi, et ils étaient impossibles ou très difficiles à configurer. Je comprends l’intention business : faire en sorte qu’on utilise l’IA autant que possible, retirer l’humain de la boucle, obtenir plus de données d’entraînement et plus de consommation de tokens.
    Mais le résultat, selon moi, c’est que Claude Code est devenu bien pire et bien moins fiable. On a l’impression d’une tentative de retirer discrètement le volant des mains de l’utilisateur. En poussant cette logique, de plus en plus de choses deviennent justifiables.
    Pour l’instant, cela a surtout créé beaucoup plus de méfiance.

  • Je suis d’accord avec l’auteur, et je comprends aussi que pour certains cela puisse sembler une réaction encore prématurée.
    Nous vivons dans un monde très différent de celui d’avant, et les gens sont davantage sensibles aux préoccupations éthiques et plus déterminés à tenir bon pour ne pas répéter les erreurs du passé.
    D’un point de vue technique, c’est peut-être un jugement trop tôt, mais du point de vue des préoccupations éthiques, cela se défend. Les comportements fautifs ne se renversent plus aussi facilement qu’avant, et si l’on veut éviter l’ampleur des conséquences que produisent de telles décisions, il faut agir de manière préventive.

    • Je me demande sur quoi repose l’idée que les gens sont plus sensibles aux préoccupations éthiques qu’avant. Je n’ai pas l’impression qu’ils soient plus conscients éthiquement. Par exemple, je vois un peu plus de gens du côté BDS, mais en dehors de ça, pas grand-chose.
    • Quand on voit les plaintes contre Firefox et Safari parce qu’ils n’adoptent pas les API de plateforme de Chrome OS, ou la réalité de la diffusion de Chrome partout, j’ai du mal à croire que les gens tiennent réellement bon par considération éthique.

  • À la fin, l’auteur énumère ce qu’il aime dans Bun et que pnpm n’a pas. La liste se résume surtout au support natif de TS, à un bundler façon Vite, et à un exécuteur de tests façon Vitest/Jest.
    À part le bundler, Node a déjà tout ça. La syntaxe de l’exécuteur de tests peut être différente, mais TypeScript « fonctionne simplement » par défaut et l’exécuteur de tests intégré est tout à fait utilisable. Je ne suis donc pas sûr qu’il faille autant pleurer Bun.

    • Pour être juste, Node n’avait rien de tout ça avant que Deno et Bun viennent le bousculer. Deno seul n’a, pour une raison ou une autre, pas réussi à provoquer de grand changement, mais l’existence de Bun a eu un impact réel sur le comité de pilotage technique de Node.
      On peut aussi dire que le marketing très habile de Jarred Sumner sur les réseaux sociaux a créé une bonne partie de l’élan actuel. Il a fait parler les gens, et grâce à cela Node s’est amélioré aussi.
      De plus, en poussant Bun à prendre en charge autant d’API Node que possible, Deno a fini par suivre au même niveau de compatibilité, et aujourd’hui la plupart du code est de fait moins lié à un runtime donné. Je ne sais pas si j’utiliserai Bun en production, mais je suis heureux que son existence ait énormément amélioré l’écosystème JavaScript.
    • Depuis quand Node a-t-il ajouté le TypeScript natif ? On peut lancer directement node main.ts sans dépendance ?
    • Si on tient compte aussi de la réécriture du compilateur TypeScript, la pertinence de Bun diminue encore davantage.

  • Honnêtement, je n’ai pas beaucoup utilisé Bun à part pour tester des modules de temps en temps. Au quotidien, j’utilise surtout Deno, et j’ai aussi écrit beaucoup de scripts shell en Deno ces dernières années.
    J’apprécie assez l’ergonomie actuelle, et la façon de référencer directement les modules du dépôt est particulièrement agréable pour les scripts shell.
    En revanche, je m’inquiète de savoir s’ils pourront assurer suffisamment de monétisation tout en gardant les fonctionnalités ouvertes, ou au moins permettre à d’autres de les répliquer. Donc je comprends une partie des inquiétudes.
 
jjpark78 3 시간 전

https://github.com/oven-sh/bun/issues/17723

S'ils corrigeaient déjà juste ça, j'aurais l'impression qu'on pourrait l'essayer une fois en backend...