3 points par GN⁺ 2023-11-28 | 1 commentaires | Partager sur WhatsApp
  • Prettier, le formateur de code JavaScript, a estimé que sa logique de formatage approchait d’un état de stabilité, et a cherché à stimuler une concurrence sur les performances via une implémentation compatible en Rust
  • Le 9 novembre, Prettier a lancé une prime de 10 000 dollars à condition de faire passer 95 % de la suite de tests ; avec l’ajout du CEO de Vercel Guillermo Rauch et de napi.rs, le montant total a atteint 22 500 dollars
  • Biome a remporté la prime après qu’une dizaine de personnes ont amélioré la compatibilité pendant environ trois semaines, ce qui a rapidement élargi l’étendue de la compatibilité réelle avec Prettier
  • En cherchant à faire passer les tests, des bugs et décisions discutables de Prettier ont aussi été mis en évidence, donnant à l’équipe Prettier des bases concrètes pour l’améliorer
  • Prettier verse depuis des dons 1 500 dollars par mois à deux mainteneurs, mais son budget actuel ne lui laisse plus que 8 mois de runway, ce qui rend de nouveaux dons nécessaires

Biome remporte la prime de Prettier

  • Prettier est un formateur de code JavaScript largement adopté, car il gère avec soin les façons très variées dont les développeurs écrivent leur code
  • Sa logique de formatage est déjà robuste, et l’équipe estime qu’elle atteindra un niveau satisfaisant une fois le travail sur les ternaries intégré
  • Le prochain défi est l’amélioration des performances
    • Prettier n’a jamais été un outil particulièrement rapide, mais il était suffisamment rapide pour la plupart des usages
    • Pour éviter de rester sur ses acquis, l’équipe a voulu encourager les progrès via une concurrence amicale
  • Conditions de la prime et participation

    • Le 9 novembre, Prettier a proposé une $10k bounty pour tout projet écrit en Rust capable de passer 95 % de la suite de tests de Prettier
    • Guillermo Rauch, CEO de Vercel, a ajouté la même somme, portant le total à 20 000 dollars
    • napi.rs a ajouté 2 500 dollars
    • Algora a créé une landing page dédiée à la prime
  • Le résultat obtenu par Biome

    • Le projet Biome a remporté la prime
    • Environ 12 personnes ont travaillé pendant trois semaines à améliorer la compatibilité
    • Les détails figurent dans le rapport complet de Biome
    • En cherchant à faire passer les tests, de nombreux bugs and questionable decisions de Prettier ont également été découverts, ce qui donne à Prettier des pistes d’amélioration

La pression créée par la concurrence sur les performances

  • Si l’équipe Prettier a financé un autre projet, c’était pour créer une concurrence sur les performances
    • Prettier occupait une position dominante dans le domaine des formateurs de code JavaScript
    • Le manque de concurrence réduisait la motivation à améliorer les performances et à corriger divers cas limites
  • Biome dispose désormais d’une implémentation compatible avec Prettier, mais beaucoup plus rapide, et les utilisateurs peuvent basculer vers elle
  • Fabio Spampinato a profité de ce challenge pour profiler sérieusement la CLI de Prettier, découvrant plusieurs inefficacités extrêmes
    • Ces problèmes devraient être corrigés d’ici la fin de l’année

Dons et budget de maintenance de Prettier

  • La prime de Prettier et son fonctionnement continu ont été rendus possibles grâce à d’importants dons de particuliers et d’entreprises
  • Principaux dons d’entreprises

    • Indeed : 20 000 dollars
    • Frontend Masters : 10 850 dollars
    • Sentry : 10 529 dollars
    • Salesforce : 10 025 dollars
    • Airbnb : 8 426 dollars
    • Cybozu : 6 086 dollars
  • Principaux dons de particuliers

    • Shintaro Kaneko : 1 635 dollars
    • Suhail Doshi : 1 000 dollars
    • icchiman : 500 dollars
    • Mariusz Nowak : 270 dollars
    • Benoît Burgener : 270 dollars
    • Jeremy Combs : 270 dollars
    • f_subal : 230 dollars
    • Grâce à ces dons, Prettier a pu verser 1 500 dollars par mois à deux personnes et poursuivre ses releases au cours des deux dernières années
    • Fisker Cheung et Sosuke Suzuki occupent ce rôle
    • Avec le budget actuel, il ne reste plus que 8 mois de runway, d’où le besoin de dons supplémentaires
    • Si vous utilisez Prettier et en avez bénéficié, vous pouvez faire un don sur https://opencollective.com/prettier
    • Open Collective aide grandement au fonctionnement du projet
    • Les mainteneurs peuvent s’y inscrire sans fournir d’informations personnelles
    • Le service fonctionne comme une banque et permet d’envoyer et de recevoir de l’argent dans le monde entier
    • Il gère correctement les documents fiscaux
    • Prettier a collecté au total 110 000 dollars et en a redistribué 75 000 dollars
    • Cette prime est ponctuelle, mais son objectif est d’insuffler de l’énergie dans l’écosystème du formatage de code afin d’améliorer l’expérience des développeurs

1 commentaires

 
GN⁺ 2023-11-28
Avis sur Hacker News
  • Je me demandais pourquoi l’équipe de Prettier finance un autre projet, mais la réponse ne me convainc pas vraiment
    Ils pourraient simplement proposer une prime pour améliorer Prettier ; on ne voit pas bien pourquoi créer un projet concurrent pour inciter à améliorer Prettier
    Je me demande aussi si l’objectif final est d’abandonner Prettier pour migrer vers un outil basé sur Rust, et cela donne l’impression de fragmenter encore davantage un écosystème déjà confus sans réelle nécessité

    • Il semble y avoir trois raisons pour lesquelles cela est devenu un projet distinct plutôt qu’une prime pour améliorer Prettier
      D’abord, écrire un formateur en Rust est de nature différente d’une amélioration de la base de code de Prettier. Prettier n’est pas écrit en Rust, et Rust a prouvé qu’il était un choix solide pour implémenter un formateur ; l’objectif est donc plus proche de l’écriture d’un formateur en Rust en soi
      Ensuite, demander à quelqu’un d’écrire un formateur Rust appartenant à Prettier pour 20 k$ n’est pas très attractif. Pour un excellent développeur, cela représente environ 100 heures de travail, donc insuffisant pour mener le projet à terme ; en revanche, être récompensé avec un projet dont il reste propriétaire est bien plus séduisant
      Enfin, si Prettier possédait le projet gagnant, la responsabilité de sa maintenance incomberait aussi à l’équipe Prettier. L’équipe qui l’a créé aurait alors moins d’incitation à le maintenir, et la concurrence disparaîtrait, rendant l’écosystème moins dynamique
    • Du point de vue d’un mainteneur open source, on se soucie davantage de la résolution du problème que du fait que tout le monde utilise mon implémentation particulière
      Le fait que quelqu’un utilise mon code ne m’apporte pas de bénéfice direct, et j’ai travaillé pour rendre la solution accessible. Si on est passionné par le formatage du code JS, voir quelqu’un résoudre ce problème plus rapidement d’une autre manière serait plutôt réjouissant
    • Il y a une grande différence entre « nous sommes l’acteur dominant établi et il n’existe pas d’alternative valable pour les développeurs JavaScript » et « cela a été réalisé côté Rust et une alternative assez viable a émergé »
      Cela ressemble davantage à un problème consistant à sortir d’un optimum local. On peut repérer le principal goulet d’étranglement de performance et dire qu’on peut l’améliorer, mais sans point de comparaison objectivement meilleur, il est difficile d’en être certain
      L’imitation est la forme de flatterie la plus sincère, et le simple fait qu’un problème difficile puisse aussi être résolu dans un autre langage crée de la valeur dans le processus concurrentiel
      Sans véritable alternative, il n’y a pas de concurrence complète. Si l’implémentation Rust est plus rapide même en ne prenant en charge que moins de 5 % de la suite de tests, cela nous apprend déjà beaucoup sur les limites théoriques de ce problème par rapport à l’implémentation de référence
      Je ne connais pas ce domaine en profondeur, mais je pense qu’il y a toujours une valeur intangible à avoir une implémentation similaire dans un autre langage
    • Quand des personnes avec des points de vue et des intentions différents implémentent quelque chose, de nouvelles pistes d’amélioration peuvent apparaître
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome n’a pas suivi les mêmes décisions que Prettier et a mis au jour plusieurs points de friction divergents ; cela suffit déjà à montrer la valeur d’un développement en parallèle
    • Une approche avec des contraintes et un bagage différents peut identifier des zones d’amélioration invisibles dans le projet d’origine
      C’est peut-être parce qu’elle n’est pas enfermée dans une manière de penser à la Prettier
  • On dirait que beaucoup de gens donnent des raisons sans considérer en même temps ce point-ci : « tout en faisant passer tous les tests, le projet Biome a découvert beaucoup de bugs et de décisions discutables de Prettier, et a permis de les améliorer »
    Pour moi, cela signifie qu’une autre implémentation a permis de faire une vérification de cohérence de leur propre implémentation

  • Cette nouvelle m’enthousiasme vraiment
    La vitesse à laquelle l’équipe Biome a atteint une compatibilité à 95 % avec Prettier était étonnamment rapide https://github.com/biomejs/biome/issues/720
    Grâce à Rust, ils peuvent fortement accélérer le formatage JavaScript, dans la lignée de ce qu’a fait le formateur Python ruff
    Ce n’est pas mentionné dans l’article, mais Wasmer a aussi proposé une prime de 2 500 $ pour compiler Biome vers WASIX, et c’était intéressant de voir cette équipe travailler dans ce but
    J’espère bientôt voir Biome fonctionner sur Wasmer : https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • Je découvrais WASIX, et en lisant à son sujet, j’ai eu l’impression de voir une réincarnation de la JVM
      Je me demande si cette compréhension est correcte. Si on peut accéder au système et que ce n’est pas un vrai sandbox, je ne vois pas bien l’intérêt d’exécuter du code sur WASIX
    • Je me demande si quelqu’un sait pourquoi ils veulent le rendre compilable vers WASIX
  • Les améliorations de vitesse sont toujours bienvenues, mais j’aimerais que Prettier soit un peu moins dogmatique
    En particulier pour la longueur de ligne, il ne laisse tout simplement pas mon formatage tranquille. Le code formaté avec Prettier est souvent bien moins lisible que le code non formaté, et c’est un problème que je ne rencontre pas avec d’autres formatteurs comme rustfmt

    • Je me demande s’il existe un exemple où le code produit par Prettier est nettement moins lisible
      Je n’ai pas vraiment rencontré ce problème et j’ai plutôt été satisfait de Prettier jusqu’ici
    • Je me demande si tu as essayé l’option print width : https://prettier.io/docs/en/options.html#print-width
    • Le vrai problème de Prettier, c’est qu’il est devenu quasiment un standard de fait
      Personnellement, je n’aime pas du tout Prettier, mais j’aime Svelte, et le formateur officiel de Svelte utilise Prettier, si je ne me trompe pas. Du coup, j’utilise Prettier pour Svelte, et pour quelques autres choses aussi
      Si l’utilisateur a réellement le choix de l’outil, le principe « très dogmatique, et si vous voulez de la configuration, allez voir ailleurs » peut être excellent. Mais quand cela devient en pratique le seul choix pour une certaine catégorie d’utilisateurs, il faudrait que ce soit un peu plus configurable
    • Sur la longueur de ligne, Prettier a aussi des effets de bord plus subtils, et c’est pour ça que j’évite les formatteurs dogmatiques
      Prettier modifie les diff d’une manière non intentionnelle
      Si on retire un membre dans une affectation par déstructuration et que ça repasse sous la limite de longueur de ligne, un diff peut devenir +1/-5 au lieu de 0/-1. Le relecteur a alors plus de mal à voir immédiatement ce qui a exactement disparu entre 5 lignes supprimées et 1 ligne ajoutée
      Si on essaie de corriger une faute de frappe dans un commit précédent avec le rebase interactif de Git, Prettier peut reformater tout le bloc de code, ce qui peut empêcher l’application des commits suivants
      Et si on exécute Prettier via un hook pre-commit puis qu’on ne stage qu’une partie des modifications du fichier, on obtient encore d’autres problèmes amusants. Je passe mon tour
    • D’accord. J’irais même jusqu’à dire qu’on aurait été mieux lotis si Prettier n’avait jamais existé
  • Je suis encore agacé que plusieurs plugins eslint aient supprimé un linter parfaitement correct pour le remplacer par Prettier
    Prettier est trop autoritaire, difficile à raisonner, et c’est encore un outil de plus que je n’ai jamais demandé

    • Les règles de style abandonnées ont été portées vers un nouveau projet : https://eslint.style/guide/why
    • Le but même de ce genre d’outil est précisément de mettre fin aux débats de style
    • Je ne vois pas très bien dans quels cas il faudrait « raisonner » sur Prettier
      Le seul cas qui me vient à l’esprit, ce sont les problèmes occasionnels de conflits de fusion
  • Il y a bien une tendance aux portages en Rust, mais comme Prettier s’exécute à chaque sauvegarde, le gain de vitesse devrait être assez important
    Je vais probablement essayer Biome bientôt, et je félicite l’équipe du projet Biome

    • Je n’ai jamais ressenti de latence quand Prettier s’exécute sur un seul fichier
      Les performances deviennent importantes quand on lance le formatage sur l’ensemble du dépôt
      En usage interactif, il faut utiliser un processus déjà lancé et déjà warm, et dans ce cas le temps de démarrage de Node n’a pas d’importance. Idéalement, vérification de types, linting, mise en évidence syntaxique et formatage devraient tous vivre dans un seul service de langage, faire du parsing incrémental à chaque frappe et mettre à jour un AST partagé
    • Ce travail me rappelle l’enthousiasme autour de ruff dans la communauté Python
      On peut s’attendre à des améliorations d’efficacité et de vitesse avec un impact large
    • Je recommande d’utiliser l’outil lint-staged pour que Prettier ne s’exécute, à chaque sauvegarde, que sur les fichiers modifiés plutôt que sur l’ensemble
      Sur les gros projets, la différence est énorme
  • « Nous pouvons maintenant nous concentrer sur l’autre aspect important : les performances. Prettier n’a jamais été intrinsèquement rapide, mais il a été suffisamment rapide pour la plupart des usages. Cela ne m’a jamais totalement satisfait, et j’ai donc voulu faire quelque chose. Quoi de mieux qu’une concurrence amicale ? Le 9 novembre, j’ai proposé une prime de 10 k$ à un projet Rust qui passerait 95 % de la suite de tests de Prettier »
    Je ne vois pas comment de meilleures performances découleraient du simple fait qu’une chose soit écrite en Rust. On aurait même pu transcompiler la base de code existante en Rust et toucher la récompense

    • Quand je vois le mot « simplement », j’ai tendance à penser que ce qui suit ne sera pas simple
      Si c’était vraiment simple, il n’y aurait pas besoin de le qualifier ainsi
      En l’occurrence, je ne sais pas si transcompiler une base de code JavaScript en Rust est simple. Les deux langages ont des modèles de pensée, des bibliothèques et des façons d’écrire le code assez différents, et même s’il existait un transpileur JS-vers-Rust, je doute qu’il soit assez robuste pour une base de code de la taille de Prettier
    • Du Rust idiomatique est souvent 5 à 10 fois plus rapide que du code JavaScript/TypeScript apparemment équivalent, même sans optimisations particulières
      Cela dépend de la tâche et ce n’est pas toujours vrai, mais c’est clairement le cas pour les parseurs qui font beaucoup de manipulation de chaînes
    • Pour le traitement de chaînes, Rust est bien plus rapide que JS
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • Voici la réponse que j’ai reçue de vjeux : « Il y a beaucoup d’outils web rapides écrits en Rust ces jours-ci »
      https://twitter.com/Vjeux/status/1722769322299609565
      Je ne suis pas convaincu, et j’ai l’impression que vjeux suit simplement la mode Rust
  • Le projet gagnant, Biome, est un fork ou un changement de nom de Rome, un projet lancé il y a quelques années par Sebastian McKenzie, le créateur de Babel
    Il a été forké parce que sebmck semble s’être absenté depuis environ un an, et comme il était le seul à avoir accès à beaucoup de ressources du projet, les contributeurs ne pouvaient pas faire de mises à jour
    J’espère qu’il va bien et, indépendamment de cela, je suis heureux de voir que le projet Biome semble bien avancer

  • Je ne vois pas pourquoi il fallait absolument que ce soit du Rust
    Le simple fait que ce soit « plus rapide » n’aurait-il pas suffi ? L’implémentation en Rust est-elle réellement plus rapide ? Et je me demande aussi si des choses comme la sécurité mémoire ou les fuites sont vraiment si importantes pour un programme comme Prettier

    • En particulier sur HN, il y a beaucoup de gens qui pensent que Rust est actuellement le langage le plus rapide et le plus sûr
      Donc, dans une certaine mesure, ça a peut-être été un défi avec prime du genre « si c’est vrai, prouvez-le vous-mêmes »
  • Je me demande s’il existe quelque part des benchmarks de Biome
    Ses performances sont exactement de combien supérieures à celles de Prettier ?

    • J’en ai trouvé une partie ici : https://github.com/biomejs/biome/blob/main/benchmark/README.md
      Ils parlent de 25 fois plus rapide, mais les chiffres datent un peu, donc je ne sais pas s’il faut encore les prendre pour argent comptant maintenant que beaucoup de fonctionnalités ont été ajoutées. Cela dit, si c’est encore dans cet ordre de grandeur, c’est un résultat énorme.