Prettier-Bounty über 20.000 Dollar von Biome eingelöst

 (prettier.io)
3 Punkte von GN⁺ 2023-11-28 | 1 Kommentare | Auf WhatsApp teilen
  • Der JavaScript-Code-Formatter Prettier wollte, nachdem seine Formatierungslogik weitgehend stabil geworden war, durch eine Rust-basierte kompatible Implementierung Performance-Wettbewerb anstoßen
  • Am 9. November setzte Prettier eine Bounty von 10.000 Dollar aus, wenn 95 % der Testsuite bestanden werden; durch zusätzliche Beiträge von Vercel-CEO Guillermo Rauch und napi.rs stieg die Gesamtsumme auf 22.500 Dollar
  • Biome erhielt die Bounty, nachdem mehrere Personen über rund drei Wochen die Kompatibilität verbessert hatten; dabei erweiterte sich der tatsächlich mit Prettier kompatible Umfang schnell
  • Beim Anpassen an die Tests kamen auch Bugs und fragwürdige Entscheidungen in Prettier zum Vorschein, wodurch Prettier konkrete Ansatzpunkte für Verbesserungen erhielt
  • Prettier hat aus Spenden zwei Maintainer mit monatlich 1.500 Dollar bezahlt, doch das aktuelle Budget reicht nur noch für eine Runway von 8 Monaten, sodass weitere Spenden nötig sind

Biome erhält die Prettier-Bounty

  • Prettier ist ein JavaScript-Code-Formatter, der weit verbreitet ist, weil er die vielen unterschiedlichen Arten, wie Menschen Code schreiben, sorgfältig behandelt
  • Die Formatierungslogik ist bereits robust; mit der Arbeit an ternaries wird sie voraussichtlich einen zufriedenstellenden Stand erreichen
  • Die nächste Aufgabe ist die Performance-Verbesserung
    • Prettier war ursprünglich kein schnelles Tool, war aber für die meisten Anwendungsfälle schnell genug
    • Um nicht auf dem aktuellen Stand stehenzubleiben, sollen Verbesserungen durch freundschaftlichen Wettbewerb angeregt werden

  • Bounty-Bedingungen und Teilnahme

    • Am 9. November wurde eine $10k bounty ausgeschrieben, die ein in Rust geschriebenes Projekt erhalten kann, wenn es 95 % der Prettier-Testsuite besteht
    • Guillermo Rauch, CEO von Vercel, legte denselben Betrag oben drauf, wodurch die Summe auf 20.000 Dollar stieg
    • napi.rs ergänzte weitere 2.500 Dollar
    • Algora erstellte eine Landingpage für die Bounty

  • Ergebnis von Biome

    • Das Projekt Biome erhielt die Bounty
    • Über rund drei Wochen kamen etwa 12 Personen zusammen, um die Kompatibilität zu verbessern
    • Details stehen im full report von Biome
    • Beim Anpassen an die Tests wurden auch zahlreiche bugs and questionable decisions in Prettier gefunden, die Prettier nun verbessern kann

Der Druck durch Performance-Wettbewerb

  • Der Grund, warum das Prettier-Team Geld für ein anderes Projekt aussetzte, war die Schaffung von Performance-Wettbewerb
    • Prettier nahm im Bereich der JavaScript-Code-Formatter eine dominierende Stellung ein
    • Wegen fehlender Konkurrenz gab es wenig Anreiz, die Performance zu verbessern und diverse Edge Cases zu beheben
  • Biome verfügt nun über eine mit Prettier kompatible und deutlich schnellere Implementierung, zu der Nutzer wechseln können
  • Fabio Spampinato nahm die Challenge zum Anlass, die Prettier-CLI gründlich zu profilieren, und fand mehrere extreme Ineffizienzen
    • Diese Probleme sollen bis Jahresende behoben werden

Spenden und Maintenance-Budget von Prettier

  • Die Bounty und der laufende Betrieb von Prettier wurden durch große Spenden mehrerer Einzelpersonen und Unternehmen ermöglicht

  • Wichtige Unternehmensspenden

    • Indeed: 20.000 Dollar
    • Frontend Masters: 10.850 Dollar
    • Sentry: 10.529 Dollar
    • Salesforce: 10.025 Dollar
    • Airbnb: 8.426 Dollar
    • Cybozu: 6.086 Dollar

  • Wichtige private Spenden

    • Shintaro Kaneko: 1.635 Dollar
    • Suhail Doshi: 1.000 Dollar
    • icchiman: 500 Dollar
    • Mariusz Nowak: 270 Dollar
    • Benoît Burgener: 270 Dollar
    • Jeremy Combs: 270 Dollar
    • f_subal: 230 Dollar
    • Dank dieser Spenden konnte Prettier in den vergangenen zwei Jahren Releases fortsetzen und zwei Personen monatlich 1.500 Dollar zahlen
    • Fisker Cheung und Sosuke Suzuki übernehmen diese Rolle
    • Mit dem aktuellen Budget bleibt nur noch eine Runway von 8 Monaten, daher sind weitere Spenden nötig
    • Wenn du Prettier nutzt und davon profitiert hast, kannst du unter https://opencollective.com/prettier spenden
    • Open Collective hilft dem Projektbetrieb erheblich
    • Maintainer können sich anmelden, ohne persönliche Informationen bereitzustellen
    • Es funktioniert wie eine Bank und kann weltweit Geld senden und empfangen
    • Steuerdokumente werden ordnungsgemäß abgewickelt
    • Prettier hat insgesamt 110.000 Dollar gesammelt und davon 75.000 Dollar umverteilt
    • Diese Bounty ist einmalig, soll dem Ökosystem für Code-Formatting aber neue Energie geben und eine bessere Developer Experience schaffen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-28
Meinungen auf Hacker News

  • Ich habe mich zwar gefragt, warum das Prettier-Team ein anderes Projekt finanziert, aber die Antwort überzeugt mich nicht wirklich.
    Man könnte doch einfach ein Bounty für Verbesserungen an Prettier ausloben; unklar ist, warum man ein Konkurrenzprojekt schaffen sollte, um Anreize für Verbesserungen an Prettier zu setzen.
    Ich frage mich auch, ob das Endziel darin besteht, Prettier einzustellen und auf ein Rust-basiertes Tool umzusteigen; es wirkt so, als würde ein ohnehin schon unübersichtliches Ökosystem unnötig weiter fragmentiert.

    • Dass daraus kein Bounty für Verbesserungen an Prettier, sondern ein separates Projekt wurde, scheint drei Gründe zu haben.
      Erstens ist das Schreiben eines Formatters in Rust etwas anderes als die Verbesserung der Prettier-Codebasis. Prettier ist nicht in Rust geschrieben, und Rust hat sich als robuste Wahl für die Implementierung von Formattern erwiesen; das Ziel liegt also eher darin, einen Rust-Formatter zu schreiben.
      Zweitens ist es nicht besonders attraktiv, für 20.000 $ einen Rust-Formatter zu schreiben, der Prettier gehört. Für hervorragende Entwickler entspricht das ungefähr 100 Stunden Arbeit, was für die Fertigstellung eines Projekts nicht reicht; wenn sie aber mit einem Projekt belohnt werden, das ihnen selbst gehört, ist das viel attraktiver.
      Drittens läge auch die Wartungsverantwortung beim Prettier-Team, wenn Prettier das Siegerprojekt besäße. Das ursprüngliche Team hätte weniger Anreiz, es weiter zu pflegen, und auch der Wettbewerb verschwände, wodurch das Ökosystem weniger lebendig würde.
    • Aus Sicht von Open-Source-Maintainern geht es weniger darum, dass alle meine konkrete Implementierung verwenden, sondern vielmehr darum, dass das Problem gelöst wird.
      Ich habe keinen direkten Vorteil davon, dass jemand meinen Code nutzt; ich habe daran gearbeitet, eine zugängliche Lösung zu schaffen. Wenn man sich für JS-Codeformatierung begeistert, dürfte man sich ziemlich freuen, wenn jemand dieses Problem auf schnellere Weise löst.
    • Zwischen „wir sind der etablierte Platzhirsch und JavaScript-Entwickler haben keine brauchbare Alternative“ und „die Rust-Seite hat es geschafft und es gibt eine ziemlich viable Alternative“ besteht ein großer Unterschied.
      Das wirkt eher wie ein Problem, aus einem lokalen Optimum herauszukommen. Man kann auf den größten Performance-Flaschenhals schauen und sagen, dass man ihn verbessern kann, aber ohne objektiv bessere Vergleichsbasis ist es schwer, sicher zu sein.
      Nachahmung ist die aufrichtigste Form der Anerkennung, und schon die Tatsache, dass sich ein schwieriges Problem auch in einer anderen Sprache lösen lässt, schafft im Wettbewerbsprozess Wert.
      Ohne echte Alternative gibt es auch keinen vollständigen Wettbewerb. Wenn eine Rust-Implementierung weniger als 5 % der Testsuite opfert und trotzdem schneller ist, sagt das im Vergleich zur Standardimplementierung viel über die theoretischen Grenzen dieses Problems aus.
      Ich kenne diesen Bereich nicht im Detail, aber ich glaube, dass eine ähnliche Implementierung in einer anderen Sprache immer einen immateriellen Wert haben kann.
    • Wenn Menschen mit unterschiedlichen Perspektiven und Absichten etwas implementieren, können neue Verbesserungsrichtungen sichtbar werden.
      https://biomejs.dev/formatter/#differences-with-prettier
      Biome folgt nicht denselben Entscheidungen wie Prettier und hat mehrere divergierende Pain Points identifiziert; allein das reicht als Wert paralleler Entwicklung völlig aus.
    • Ein Ansatz mit anderen Einschränkungen und Lasten kann Verbesserungsbereiche finden, die im ursprünglichen Projekt nicht sichtbar waren.
      Vielleicht gerade deshalb, weil er nicht in der sogenannten Prettier-Denkweise gefangen ist.

  • Viele nennen zwar Gründe, scheinen diesen Teil aber nicht mitzulesen: „Beim Bestehen aller Tests hat das Biome-Projekt viele Bugs und fragwürdige Entscheidungen von Prettier entdeckt und konnte sie verbessern.“
    Für mich bedeutet das, dass man durch eine andere Implementierung die eigene Implementierung einem Sanity Check unterziehen kann.

  • Diese Nachricht freut mich wirklich sehr.
    Das Biome-Team hat erstaunlich schnell 95 % Kompatibilität mit Prettier erreicht: https://github.com/biomejs/biome/issues/720
    Dank Rust lässt sich die Geschwindigkeit der JavaScript-Formatierung deutlich steigern; im Grunde folgt es damit dem Trend des Python-Formatters ruff.
    Im Artikel steht es nicht, aber auch Wasmer hat ein Bounty von 2.500 $ dafür ausgesetzt, Biome nach WASIX zu kompilieren, und es war schön zu sehen, wie das Team daran gearbeitet hat.
    Ich hoffe, dass Biome bald auf Wasmer läuft: https://wasmer.io/, https://wasix.org/, https://console.algora.io/challenges/prettier

    • WASIX sehe ich zum ersten Mal; nach dem Lesen wirkt es wie die Wiedergeburt der JVM.
      Ich frage mich, ob dieses Verständnis stimmt. Wenn es auf das System zugreifen kann und keine echte Sandbox ist, verstehe ich nicht, welchen Vorteil es hat, Code in WASIX auszuführen.
    • Ich frage mich, ob jemand weiß, warum man es nach WASIX kompilierbar machen will.

  • Geschwindigkeitsverbesserungen sind immer willkommen, aber ich wünschte, Prettier wäre etwas weniger dogmatisch
    Besonders bei der Zeilenlänge lässt es meine Formatierung einfach nicht in Ruhe. Mit Prettier formatierter Code ist deutlich schlechter lesbar als unformatierter Code, und das ist ein Problem, das ich bei anderen Formattern wie rustfmt nicht habe

    • Mich würde interessieren, ob es Beispiele gibt, in denen Prettier-Code deutlich schlechter lesbar ist
      Ich hatte solche Probleme kaum und war mit Prettier ziemlich zufrieden
    • Hast du die Option print width ausprobiert? https://prettier.io/docs/en/options.html#print-width
    • Das eigentliche Problem mit Prettier ist, dass es fast zu einem De-facto-Standard geworden ist
      Persönlich mag ich Prettier überhaupt nicht, aber ich mag Svelte, und der offizielle Svelte-Formatter verwendet meines Wissens Prettier. Deshalb nutze ich Prettier für Svelte, und bei ein paar anderen Dingen ist es ähnlich
      Wenn Nutzer ihr Tool selbst auswählen, kann das Prinzip „sehr dogmatisch, und wenn du Konfiguration willst, geh woandershin“ hervorragend sein. Wenn es aber für eine bestimmte Nutzergruppe praktisch die einzige Wahl wird, sollte es etwas konfigurierbarer sein
    • Bei der Zeilenlänge hat Prettier subtilere Nebenwirkungen, und deshalb meide ich dogmatische Formatter
      Prettier verändert Diffs auf unbeabsichtigte Weise
      Wenn man bei einer Destructuring-Zuweisung ein Member entfernt und dadurch unter die Zeilenlängenbegrenzung kommt, kann aus dem Diff statt 0/-1 plötzlich +1/-5 werden. Für Reviewer ist dann nicht sofort ersichtlich, was genau zwischen 5 gelöschten Zeilen und 1 hinzugefügten Zeile fehlt
      Wenn man mit Git Interactive Rebase einen Tippfehler in einem früheren Commit korrigieren will, formatiert Prettier eventuell den gesamten Codeblock neu, sodass nachfolgende Commits möglicherweise nicht mehr angewendet werden
      Wenn man Prettier per Pre-commit-Hook laufen lässt und danach nur einen Teil der Änderungen einer Datei staged, entstehen ebenfalls interessante Probleme. Ich verzichte lieber darauf
    • Stimme zu. Ich würde sogar so weit gehen zu sagen: Es wäre besser gewesen, wenn es Prettier gar nicht gegeben hätte

  • Mich nervt immer noch, dass mehrere eslint-Plugins völlig brauchbare Linter entfernt und durch Prettier ersetzt haben
    Prettier ist zu zwanghaft, schwer nachvollziehbar und noch ein weiteres Tool, das ich nie wollte

    • Die abgeschafften Stilregeln wurden in ein neues Projekt portiert: https://eslint.style/guide/why
    • Genau darin liegt doch der Zweck solcher Tools: Stildebatten zu beenden
    • Ich bin mir nicht sicher, in welchen Fällen man Prettier „nachvollziehen“ muss
      Mir fallen höchstens gelegentliche Merge-Conflict-Probleme ein

  • Es gibt zwar einen Trend, Dinge nach Rust zu portieren, aber da Prettier bei jedem Speichern ausgeführt wird, dürfte die Geschwindigkeitssteigerung ziemlich groß sein
    Ich werde Biome demnächst ausprobieren und gratuliere dem Biome-Projekt

    • Ich habe noch nie eine Verzögerung gespürt, wenn Prettier auf einer einzelnen Datei läuft
      Performance wird erst wichtig, wenn man Formatierung über das gesamte Repository laufen lässt
      Für interaktive Nutzung sollte man einen lang laufenden, aufgewärmten Prozess verwenden; dann spielt die Node-Startzeit keine Rolle. Idealerweise sollten Type Checking, Linting, Highlighting und Formatting in einem einzigen Sprachdienst zusammenlaufen, der bei jedem Tastendruck inkrementell parst und einen gemeinsamen AST aktualisiert
    • Diese Arbeit erinnert mich an die Begeisterung der Python-Community für ruff
      Zu erwarten sind Effizienz- und Geschwindigkeitsverbesserungen mit großer Breitenwirkung
    • Ich empfehle, das Tool lint-staged zu verwenden, damit Prettier bei jedem Speichern nur auf geänderte Dateien läuft und nicht auf alles
      In großen Projekten macht das einen enormen Unterschied

  • „Jetzt können wir uns auf den nächsten wichtigen Aspekt konzentrieren: Performance. Prettier war von Natur aus nie schnell, aber für die meisten Anwendungsfälle schnell genug. Damit war ich nie ganz zufrieden, also wollte ich etwas dagegen tun. Gibt es einen besseren Weg als freundschaftlichen Wettbewerb? Am 9. November habe ich eine Prämie von 10.000 $ für ein Rust-Projekt ausgesetzt, das 95 % der Prettier-Test-Suite besteht“
    Mir ist nicht klar, wie aus der Tatsache, dass etwas in Rust geschrieben ist, automatisch bessere Performance folgt. Man hätte die bestehende Codebasis auch einfach nach Rust transpilieren und die Belohnung kassieren können

    • Wenn ich das Wort „einfach“ sehe, gehe ich davon aus, dass das Folgende nicht einfach sein wird
      Denn wenn es wirklich einfach wäre, müsste man es nicht so qualifizieren
      In diesem Fall weiß ich nicht, ob es einfach ist, eine JavaScript-Codebasis nach Rust zu transpilieren. Die beiden Sprachen unterscheiden sich ziemlich stark im Denkmodell, in den verwendeten Bibliotheken und in der Art, wie man Code schreibt, und selbst wenn es einen JS-zu-Rust-Transpiler gibt, bezweifle ich, dass er robust genug für eine Codebasis in der Größe von Prettier wäre
    • Idiomatischer Rust ist ohne besondere Optimierung oft 5- bis 10-mal schneller als ähnlich aussehender JavaScript/TypeScript-Code
      Das hängt von der Aufgabe ab und gilt nicht immer, aber Parser-artige Programme mit viel String-Verarbeitung fallen definitiv in diese Kategorie
    • Bei String-Verarbeitung ist Rust deutlich schneller als JS
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/fasta.html
      https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/knucleotide.html
    • Die Antwort, die ich von vjeux bekam, war: „Heutzutage gibt es viele schnelle Web-Tools, die in Rust geschrieben sind“
      https://twitter.com/Vjeux/status/1722769322299609565
      Das überzeugt mich nicht, und vjeux scheint auf den Rust-Hype aufgesprungen zu sein

  • Das Gewinnerprojekt Biome ist ein Fork oder eine Umbenennung des Rome-Projekts, das vor einigen Jahren von Babel-Erfinder Sebastian McKenzie gestartet wurde
    sebmck scheint seit ungefähr einem Jahr abwesend zu sein, und da nur er Zugriff auf viele Projektressourcen hatte, konnten die Beitragenden keine Updates vornehmen, weshalb geforkt wurde
    Ich hoffe, es geht ihm gut, und unabhängig davon freue ich mich, dass das Biome-Projekt offenbar gut vorankommt

  • Ich verstehe nicht, warum es unbedingt Rust sein musste.
    Hätte „etwas Schnelleres“ nicht gereicht? Ist die Rust-Implementierung tatsächlich schnell? Ich frage mich auch, ob Speichersicherheit oder Leaks bei einem Programm wie Prettier wirklich so wichtig sind.

    • Besonders auf HN gibt es viele lautstarke Stimmen, die Rust derzeit für die schnellste und sicherste Sprache halten.
      In gewisser Weise könnte es also eine Bounty-Challenge nach dem Motto gewesen sein: „Wenn ihr das behauptet, dann beweist es selbst.“

  • Ich frage mich, ob es irgendwo Biome-Benchmarks gibt.
    Wie viel besser ist die Performance im Vergleich zu Prettier genau?

    • Einen Teil habe ich hier gefunden: https://github.com/biomejs/biome/blob/main/benchmark/README.md
      Es werden 25× behauptet, aber die Zahlen sind alt, daher weiß ich nicht, ob man ihnen jetzt, nachdem viele Funktionen hinzugekommen sind, noch unverändert vertrauen kann. Wenn es aber ungefähr in diesem Bereich liegt, ist das trotzdem eine enorme Leistung.