Ich mache mir Sorgen um Bun

(wwj.dev)

4 Punkte von GN⁺ 7 시간 전 | 3 Kommentare | Auf WhatsApp teilen

Bun ist eine schnelle JavaScript-Runtime und ein Tool, das die Arbeit mit TypeScript erleichtert, doch seit der Übernahme durch Anthropic im Dezember 2025 wächst die Sorge, dass Produktpolitik und Betriebsweise Einfluss darauf nehmen könnten
In der Übernahmeankündigung hieß es, Bun bleibe Open Source und unter der MIT-Lizenz, werde weiter vom selben Team entwickelt, und weil Claude Code als Bun-Executable ausgeliefert wird, habe Anthropic einen direkten Anreiz, Bun stabil und hochwertig zu halten
Seit April 2026 wurden bei Claude Code Qualitätsabfall, restriktives Verhalten, Einschränkungen für Third-Party-Harnesses, verwirrende Abrechnung und langsame Kommunikation kritisiert; im Engineering-Postmortem von Anthropic werden Probleme auf der Produktebene wie reduzierte Standardwerte für den Inferenzaufwand und Prompt-Änderungen als Ursache genannt
Berichten von TechCrunch und Gigazine zufolge verlangt Claude Code für die Unterstützung von Third-Party-Harnesses wie OpenClaw zusätzliche Gebühren oder kann allein durch die Erwähnung von OpenClaw in der Git-Historie Anfragen ablehnen bzw. Zusatzkosten auslösen; damit wurde unerwartetes Verhalten sichtbar
Nicht Bun selbst oder das Bun-Team stehen in der Kritik, sondern die Möglichkeit, dass sich Anthropic-Politik auf Bun überträgt; einige Projekte wechseln deshalb für das Paketmanagement zu pnpm und empfehlen pnpm auch für neue JavaScript- und TypeScript-Projekte

Warum die Sorge um Bun größer wird

Bun ist eine schnelle und praktische JavaScript-Runtime, die TypeScript-Arbeit bei kleinen Skripten, Apps, Tests und Tools bequemer macht
Wegen schneller Installation, schneller Tests, besserem Bundling und einer kleineren Toolchain-Belastung galt es als Tool mit Potenzial, als Alternative zu Node.js erfolgreich zu sein
Der Kern der Sorge ist nicht die Qualität von Bun selbst, sondern dass Bun nach der Eingliederung in Anthropic von dessen Produktpolitik und Betriebsweise beeinflusst werden könnte

Die Anthropic-Übernahme und die anfänglichen Erwartungen

Anthropic hat Bun im Dezember 2025 übernommen
Laut der Ankündigung bleibt Bun weiterhin Open Source und unter der MIT-Lizenz, wird vom selben Team weiterentwickelt, und die Roadmap bleibt auf performante JavaScript-Tools und Node.js-Kompatibilität fokussiert
In der Mitteilung stand der Satz: “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.”
Damals konnte man daraus schließen, dass Anthropic einen direkten Anreiz hat, Bun schnell und stabil zu halten, weil Claude Code auf Bun läuft
Diese Logik ist noch immer plausibel, doch inzwischen wächst die Sorge, dass sich in Anthropics Art, Softwareprodukte zu betreiben, Risse zeigen

Der Stimmungswandel bei Claude Code

Die Modellqualität von Anthropic selbst ist nicht die zentrale Sorge
Die mutmaßliche Modellfamilie um Claude Opus 4.6 gilt beim Coden, Schreiben, Schlussfolgern und bei allgemeinen Entwicklungsaufgaben weiterhin als stark
Das Problem liegt in der Produktebene rund um das Modell; entscheidend ist die Einschätzung, dass die Nutzbarkeit von Claude Code stark schlechter geworden ist
Vor etwa einem Jahr wirkte Claude Code noch wie ein Tool, das Projekte lesen, fokussierte Änderungen erstellen, Befehle ausführen, Fehler korrigieren und selbstständig weiterarbeiten konnte
Damals war Claude Code eines der frühen AI-Coding-Tools, das das Vertrauen vermittelte, dass sich Entwickler-Workflows von Autocomplete-zentriert zu agentenzentriert verschieben könnten
Schon im Dezember 2025 wurde Claude Code schlechter, war aber noch brauchbar, und auch die Bun-Übernahme ließ sich aus der Perspektive nachvollziehen, dass Anthropic die Zukunft von Coding-Tools aufbaut

Probleme mit Claude Code seit April 2026

Seit April 2026 kritisieren Entwickler die Qualität von Claude Code, restriktives Verhalten, Einschränkungen für Third-Party-Harnesses, verwirrende Abrechnung und langsame Kommunikation
Anthropic veröffentlichte ein Engineering-Postmortem, das Probleme auf der Produktebene wie reduzierte Standardwerte für den Inferenzaufwand, Bugs in alten Sessions und Prompt-Änderungen, die die Code-Qualität verschlechterten, als Ursache nennt
Diese Nachanalyse war besser, als so zu tun, als sei nichts passiert, und wurde als seltener Fall gewertet, in dem Anthropic Verantwortung übernahm
Laut einem Bericht von TechCrunch teilte Anthropic Claude-Code-Abonnenten mit, dass sie für die Unterstützung von OpenClaw und anderen Third-Party-Harnesses extra zahlen müssten
Laut einem Bericht von Gigazine kann bereits die Existenz von OpenClaw in der Git-Historie dazu führen, dass Claude Code Anfragen ablehnt oder zusätzliche Kosten auslöst
Der Bericht zitiert Theo mit der Aussage, dass schon die Erwähnung von OpenClaw in einem aktuellen Commit innerhalb eines JSON-Blobs das Verhalten auslösen konnte, selbst wenn in einem leeren Repository direkt claude -p "hi" aufgerufen wurde
Die betreffende Szene lässt sich auch in einem Videoclip sehen
Solches Verhalten lässt das Produkt wirken, als würden Änderungen ausgeliefert, ohne die tatsächliche Nutzungserfahrung auf Code-Ebene intern ausreichend selbst ausprobiert zu haben
Von außen betrachtet scheint Claude Code mit mehr Einschränkungen, seltsamer Abrechnung und unerwartetem, vom Commit-Text abhängigen Verhalten in die falsche Richtung zu gehen
Dieser Trend wird als enshittification bezeichnet

Die daraus folgende Unruhe um Bun

Bun ist tief in Claude Code eingebunden, und weil Claude Code sich offenbar verschlechtert, entsteht die Sorge, dass Bun denselben Weg gehen könnte
Das bedeutet nicht, dass Bun schlecht ist oder das Bun-Team das Interesse verloren hat
Das Problem ist vielmehr, dass mit stärkerer Integration von Bun und dem Bun-Team in Anthropic auch dessen Politik mitkommen könnte
Wenn die Politik, die Claude Code offenbar beschädigt hat, auch Bun beeinflusst, könnten dort ebenfalls Probleme auftreten, die so wirken, als nutze das Team sein eigenes Produkt nicht wirklich
Schon diese Möglichkeit macht es in einigen Projekten schwer, mit Überzeugung an Bun festzuhalten

Vorläufiger Wechsel zu pnpm

Bun bietet in einem einzigen Tool mehr Funktionen als pnpm
Bun unterstützt TypeScript ohne separaten Build-Schritt, bietet statt Vite einen Bundler und statt vitest eine Testfunktion
Dass diese Funktionen als eine zusammenhängende Toolchain bereitgestellt werden, ist tatsächlich ein großer Vorteil
pnpm ist weder ein Ersatz für Node.js noch für Bun, sondern einfach ein Paketmanager
Wenn Bun im Alltag aber vor allem für das Paketmanagement genutzt wird, dann bieten sowohl Bun als auch pnpm schnelle Installationen, guten Monorepo-Support und einen vernünftigen Festplattenverbrauch
Deshalb entscheiden sich einige Projekte, die aktuell Bun nutzen, dafür, Bun hinter sich zu lassen und zu pnpm zu wechseln
Auf die Frage, was man derzeit für JavaScript- oder TypeScript-Projekte empfehlen sollte, lautet die Antwort pnpm

Keine generelle Aufforderung, Bun zu verlassen

Zwar werden einige Projekte von Bun weg migriert, doch das muss nicht als allgemeingültige Antwort verstanden werden
Für neue Projekte ist pnpm sinnvoll
Bei bestehenden Projekten kann man sich auch dafür entscheiden, bei Bun zu bleiben, bis es einen ausreichend guten Grund zum Wechseln gibt

Verbleibende Hoffnung und Fazit

Die Hoffnung ist, dass Bun weiterhin großartig bleibt, das Bun-Team weiterhin gute Arbeit abliefert und Anthropic genug Autonomie gewährt, damit Entscheidungen getroffen werden können, die zum JavaScript-Ökosystem passen
Anthropic verfügt über Geld, Reichweite bei der Distribution und einen handfesten Grund, auf Performance und Stabilität von Bun zu achten
Bun könnte aus dieser Situation immer noch gestärkt hervorgehen
Trotzdem ist das Vertrauen in die Lage heute geringer als im Dezember 2025
Früher wirkte Claude Code wie ein Beleg dafür, dass Anthropic Entwickler-Tools versteht; heute wirkt es eher wie eine Warnung, dass Anthropic womöglich nicht versteht, was nötig ist, um Produkte langfristig zu pflegen und zu verbessern
Bun ist weiterhin großartig, aber wohin die Reise geht, ist schwer zu sagen
In einem Jahr kann die Lage völlig anders aussehen, daher ist geplant, dann erneut zu prüfen, ob sich diese Einschätzung bewahrheitet hat

3 Kommentare

click 3 시간 전

Ich erkenne an, dass sich dank Bun auch bei Node vieles verändert hat, aber wenn ich im Repository sehe, wie AIs sich gegenseitig mit PRs hochschaukeln, habe ich Angst, auf Regressionsminen zu treten, bei denen Dinge, die vorher funktioniert haben, plötzlich nicht mehr gehen.
Vor der Übernahme durch Anthropic habe ich Bun als Hauptumgebung genutzt, inzwischen bin ich aber wieder zu Node zurückgekehrt.
Ich halte die sfx-Funktion nach wie vor für ein Killer-Feature, aber wenn man die nicht braucht, sehe ich ehrlich gesagt keinen guten Grund, sofort Bun zu nutzen.

GN⁺ 7 시간 전

Hacker-News-Kommentare

Ich stimme der gesamten Prämisse nicht zu: Schon vor der Übernahme musste Bun irgendwann einen Weg zur Monetarisierung finden.
Nur weil die Muttergesellschaft bei anderer Software, nämlich Claude Code, schlechte Praktiken zeigt, heißt das nicht automatisch, dass Bun dadurch schlechter wird. Ich verstehe die Sorge, bin bei Bun aber noch optimistisch.
Claude Code ist das Kernprodukt von Anthropic und wächst extrem schnell; schon kleine Änderungen können direkt zu Abrechnungsproblemen führen. Bun dagegen ist eine JavaScript-Laufzeitumgebung und kann sich darauf konzentrieren, die beste Laufzeitumgebung zu werden. Es beeinflusst Umsatz oder Gewinn von Anthropic nicht direkt, daher ist der Druck geringer, wegen Missbrauchs schnell Notfall-Patches wie bei Claude Code auszurollen.
Wie es in den nächsten Jahren aussieht, ist noch unklar, aber direkt nach der Übernahme mache ich mir keine großen Sorgen.
- Interessant ist, wie schnell Leute die Erklärung mit dem Missbrauch übernehmen. Dass große AI-Labore mit Vielnutzern von Abos finanziell nicht profitabel sind, ist seit Langem bekannt, unabhängig davon, welche Agenten oder Execution-Tools verwendet werden. Ein faires, profitables Preismodell wäre tokenbasierte nutzungsabhängige Abrechnung.
  Diese Labore wollen Konkurrenz ausschalten, weil Drittanbieter-Execution-Tools ihre zugrunde liegenden Large Language Models zur Commodity machen könnten, und zugleich spielen sie gegeneinander ein Hühnerspiel darum, wer Verluste länger tragen kann.
  Am Ende müssen sie ihre Produkte korrekt bepreisen und können nur hoffen, bis dahin jede Konkurrenz ausgeschaltet zu haben. Aber dieses Spiel scheinen sie bereits zu verlieren. Nützliche Modelle werden jedes Jahr kleiner und günstiger im Betrieb, sodass wir den Punkt überschritten haben, an dem Drittanbieter-Execution-Tools auch ohne Abo-Nutzerbasis weiterentwickelt werden können.
  Die Kernwette „Nützliche AI braucht extrem teure Hardware“ ist bereits gescheitert, und auch die zweite Wette – Nutzer ins Ökosystem einsperren und später monetarisieren – wird scheitern. Am Ende werden sie nur noch über die Qualität des Produkts selbst konkurrieren können, und das ist viel weniger profitabel.
- Ich halte schon die Aussage „Auch vor der Übernahme musste Bun irgendwann monetarisiert werden“ für unsinnig. Schon dass Menschen sich von einer JavaScript-Laufzeitumgebung, die irgendwann monetarisiert werden muss, abhängig gemacht haben, ist seltsam, und noch merkwürdiger ist es, Hoffnung zu haben, nachdem sie von einem der Vorzeige-Verlustunternehmen in einem Bereich mit den größten Verlusten der Branche übernommen wurde.
- Du unterschätzt offenbar den Einfluss von Richtlinien und Unternehmenskultur auf ein Produkt.
  Manche Teams setzen inzwischen komplett auf AI und bewegen sich in Richtung „den Code bitte gar nicht mehr direkt ansehen“. Ich habe das tatsächlich gesehen, und das Ergebnis ist ungefähr so, wie man erwarten würde. Bis zu einem gewissen Punkt funktioniert es, aber besonders wenn Teams unterschiedliche Fachbegriffe und Verständnisse haben, wächst die Komplexität, Fehler häufen sich, und am Ende gibt es keine Person und kein Team mehr, die wirklich wissen, wie die Software tatsächlich funktioniert.
  Es gibt auch den Trend, dass Menschen weder testen noch Quality Assurance machen und man zusätzlich zu Unit- und Integrationstests AI Browser oder Tools steuern lässt. Die Kultur von Anthropic könnte die Arbeitsweise und Denkweise des Bun-Teams verändern.
  Wenn diese Kultur und Denkweise zum Standard werden, müssten die Modelle entweder viel besser werden, oder die Softwarequalität wird sinken.
  Dazu gibt es einen guten Vortrag von Matt Pocock: https://youtu.be/v4F1gFy-hqg
  „Code ist nicht billig. Schlechter Code ist teurer als je zuvor, weil man mit einer schwer veränderbaren Codebasis den von AI gebotenen Überfluss nicht nutzen kann. Bei einer guten Codebasis ist AI wirklich, wirklich gut.“
  Wenn sich schlechter Code selbst zu verstärken beginnt, ist es sehr schwer, da wieder herauszukommen.
- Nach derselben Logik hätte GitHub schon vor der Übernahme irgendwann monetarisiert werden müssen. Zu sagen, dass GitHub nicht schlechter wird, nur weil die Muttergesellschaft Microsoft bei Embrace, Extend, Extinguish oder bei MS Windows schlechte Praktiken gezeigt hat, ist im Grunde dasselbe Argument: Man versteht die Sorge, bleibt bei GitHub aber optimistisch.
- Anthropic hat Bun nicht für die gesamte JavaScript-Community übernommen, sondern um seine Investition in Claude Code zu schützen und auszubauen. Das wirkt offensichtlich, sollte aber ausdrücklich gesagt werden. Langfristig werden die Ergebnisse den Anreizen folgen.
Ich verstehe nicht, warum Leute Deno oder Bun statt Node verwenden. Es ist gut, dass es Konkurrenz für JavaScript-Laufzeitumgebungen gibt, aber ich sehe den Vorteil eines Umstiegs von Node nicht wirklich.
Bun hat kein REPL und eine schlechtere JavaScript-Engine, Deno wirkt auf mich wie Node mit einem restriktiven und nervigen Berechtigungssystem, und ich dachte, es hätte auch kein sqlite. Beide sollen zwar schnell sein, aber offenbar nur in ausgewählten Benchmarks; bei Workloads, die ich vor etwa einem Jahr selbst ausprobiert habe, waren beide langsamer als Node.
Ich erinnere mich aber, dass ich bei der Auslieferung eines kleinen ERP-Tools einmal Bun verwendet habe, weil dort das Tooling zum Verpacken eines Projekts als *.exe am solidesten war. Die eigentliche Anwendung war komplett Node, und nur für die Auslieferung habe ich Bun genutzt; diese Erfahrung war definitiv besser als mit Node.
- Deno hat auch sqlite: https://docs.deno.com/examples/sqlite/
- Die Developer Experience von Bun ist deutlich besser als bei Node, besonders bei TypeScript-Projekten.
- An Deno ist gut, dass Nutzer einfach direkt ausführen können, ohne einen separaten Installationsschritt.
Bun war eigentlich noch nie besonders gut geführt. In jeder Funktion steckten Bugs und Lücken, und mit jedem Release wurden zwar ein paar Dinge repariert, dafür gingen andere kaputt.
In einem einzigen Patch-Release steckten so viele große Features und Breaking Changes, wie die meiste Software sonst über zwei Major-Versionen verteilt erlebt.
Ich nutze es im Grunde nur als Script-Runner und npm-Paketmanager, und selbst dann ist der Aufwand, eine „gute“ Version zu finden, erstaunlich hoch. Mehrfach blieb die Installation in Patch-Versionen plötzlich hängen, weshalb ich eine Zeit lang nicht upgraden konnte.
Vor ungefähr zwei Minor-Versionen haben sie mit trustedDependencies wohl postinstall-Skripte komplett kaputtgemacht. In den Release Notes stand kein Wort dazu, und auch in den GitHub-Issues schien es niemand gemeldet zu haben. Um 1.1 herum konnte man Bun noch dazu bringen, trustedDependency-Builds in postinstall auszuführen, danach nicht mehr, und das ist seit Monaten kaputt.
- Es gibt ein GitHub-Issue zu dem Hängenbleiben bei der Installation. Ein Security-Scanner übergibt die vollständige Abhängigkeitsliste als Kommandozeilenargument, und in großen Monorepos unter Linux überschreitet das ARG_MAX.
  spawn hängt dann stillschweigend ohne Fehler, und weil der Scanner von postinstall getrennt ist, hilft auch --ignore-scripts nicht. Das ist mindestens seit 1.3.5 kaputt.
Ich arbeite bei Bun, und dieser Beitrag ist etwas verwirrend. Ich persönlich und auch das Bun-Team verwenden Bun jeden Tag selbst und verbessern es kontinuierlich, und die Entwicklungsgeschwindigkeit ist eher noch gestiegen. Seit dem Zusammenschluss mit Anthropic hat sich auch die Stabilität von Bun stark verbessert.
In der nächsten Bun-Version kommen unter anderem eine Verkleinerung des Windows-x64-Binaries um 17 MB [0], des Linux-Binaries um 8 MB [1], das CLI-Flag --no-orphans zum rekursiven Beenden verbleibender Child-Prozesse [3], SSL-Kontext-Caching für Client-TCP- und Unix-Sockets, das den Speicherverbrauch von Datenbank-Clients wie Mongoose/MongoDB stark senkt [4], experimentelle HTTP/3- und HTTP/2-Clients für fetch [5], experimenteller HTTP/3-Support für Bun.serve() [6] sowie die eingebaute Bildverarbeitungsbibliothek Bun.Image [7].
Dazu kommen Verbesserungen bei der Zuverlässigkeit von node:fs, Worker, BroadcastChannel und MessagePort.
Dank der Übernahme durch Anthropic muss Bun kein umsatzgenerierendes Geschäft mehr sein. Claude Code hängt von Bun ab, und viele Softwareingenieure hängen bei ihrer Arbeit von Claude Code ab, daher gibt es starke Anreize, Bun weiter zu verbessern.
[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
- Übernahmen in dieser Branche enden meist auf eine gewisse Weise zwangsläufig. Übernommene Software wird schlechter, wenn die ursprünglichen Teammitglieder ihre Belohnung mitnehmen und gehen, und die bestehende Kultur wird durch die des neuen Eigentümers ersetzt.
  Bun könnte eine Ausnahme sein, aber man kann die Sorgen nicht als unbegründet abtun.
  Der CEO von Anthropic hat häufig überzogene Prognosen abgegeben, als stünde AI kurz davor, menschliche Programmierer fast zu ersetzen, und Anthropic setzt diesen Glauben offenbar in Claude Code um und verwandelt es in unwartbaren Spaghetti-Code.
- Das beste Feature, das Bun in letzter Zeit geliefert hat, sind portable Binärdateien. Viele Nutzer verwenden alte Linux-Distributionen, daher ist Portabilität extrem wichtig. Node und Deno verlangen neueres Linux, genauer gesagt ein aktuelleres glibc.
- „Ich arbeite bei Bun“ ist eine gewaltige Untertreibung. Ich habe zwar Bedenken wegen Anthropic, aber solange Jarred das führt, glaube ich nicht, dass Bun entgleist. Vermutlich nutzt er die Stabilität und Finanzierung der größeren Organisation gut aus.
Ich habe ein paar Stunden darauf verwendet, das Backend einer Messerschärf-Website von Bun auf Node umzuziehen, und fühle mich gut dabei, den Lock-in-Effekt vermieden zu haben. Anfangs war ich ziemlich begeistert von Bun, aber nach und nach wurde ich skeptischer.
Vermissen werde ich Abfragen an sqlite per Tagged-Template-Literal, dass Bun.password.verify standardmäßig argon2 nutzt, HTML-Imports, JSX-Transformation und das automatische Laden von .env-Dateien.
https://burlyburr.com ruft https://backend.burlyburr.com auf.
- Node unterstützt auch sqlite-Abfragen per Tagged-Template-Literal.
  https://nodejs.org/api/sqlite.html#databasecreatetagstoremax...
- Man könnte doch einfach eine kleine Helper-Bibliothek verwenden, die die vermissten Features zurückbringt. Node hat zumindest SQLite und Argon2 bereits an Bord; wenn das Problem also nur das Interface ist, lässt sich das leicht beheben.
- Node unterstützt ebenfalls automatisches Laden von .env und sqlite.
Ich fand nicht, dass Bun schon vor der Übernahme wirklich gut funktioniert hat. Für kleine Skripte habe ich es weiter genutzt, aber bei der Arbeit hätte ich keinen Service mit Bun ausgerollt.
Wegen Speicherproblemen und nicht behobener Inkompatibilitäten sah ich es eher als nettes Spielzeug, das immerhin zeigte, dass Node.js Verbesserungspotenzial hat.
Ich habe zum Beispiel weiter https://github.com/oven-sh/bun/issues/14102 verfolgt, und am Ende begannen Bibliotheken Verzweigungen einzubauen wie „wenn Bun, dann mach x“, was das Gegenteil von Kompatibilität ist.
- Ich habe in ein paar Projekten versucht, es in Produktion einzusetzen, musste aber beide Male von Bun zurück zu Node wechseln. In einem Fall gab es, wie erwähnt, ein großes Speicherleck, im anderen schlugen API-Unterschiede etwa bei TextDecoderStream fehl. Vor Bun v2 werde ich es nicht noch einmal versuchen.
Die Entwicklung bei Claude Code und Anthropic wirkt auf mich wie der Versuch, Nutzern Dinge mit Gewalt zu verbergen. Manche erinnern sich vielleicht an das Chaos, als das Lesen von xxx.yy plötzlich zu einem oder zwei Dateilesevorgängen umdefiniert wurde.
Weitere Änderungen in dieser Richtung folgten, und sie ließen sich entweder gar nicht oder nur sehr schwer konfigurieren. Die geschäftliche Motivation verstehe ich: Man will so viel AI-Nutzung wie möglich, den Menschen aus dem Loop nehmen und mehr Trainingsdaten sowie mehr Token-Verbrauch erzeugen.
Aber ich finde, dadurch ist Claude Code viel schlechter und deutlich unzuverlässiger geworden. Es fühlt sich an wie ein Versuch, dem Nutzer heimlich das Lenkrad aus der Hand zu nehmen. Folgt man dieser Logik, lässt sich immer mehr rechtfertigen.
Aktuell hat das vor allem zu großem Misstrauen geführt.
Ich stimme dem Originalbeitrag zu und verstehe auch, dass das auf manche noch wie eine verfrühte Reaktion wirken kann.
Wir leben in einer Welt, die sich stark von früher unterscheidet, und die Menschen achten stärker auf ethische Bedenken und sind entschlossener, Widerstand zu leisten, um alte Fehler nicht zu wiederholen.
Nach technischen Maßstäben mag das verfrüht sein, nach Maßstäben ethischer Bedenken ergibt es aber Sinn. Fehlverhalten lässt sich nicht mehr so leicht rückgängig machen wie früher, und um die großen Folgen solcher Entscheidungen zu vermeiden, braucht es vorbeugendes Handeln.
- Mich würde interessieren, worauf sich die Aussage stützt, dass Menschen heute ethische Bedenken stärker beachten als früher. Auf mich wirkt es nicht so, als seien sie ethisch bewusster als früher. Ich sehe zum Beispiel, dass es etwas mehr Leute auf der BDS-Seite gibt, aber sonst nicht viel.
- Wenn man sich die Beschwerden darüber ansieht, dass Firefox und Safari die Chrome-OS-Plattform-APIs nicht übernehmen, oder die Realität, dass Chrome überall ausgeliefert wird, finde ich nicht, dass Menschen standhaft an ethischen Erwägungen festhalten.
Der Autor zählt am Ende Dinge auf, die er an Bun mag, die pnpm aber nicht hat. Die Liste besteht im Wesentlichen aus nativer TS-Unterstützung, einem Bundler im Stil von Vite und einem Test-Runner im Stil von Vitest/Jest.
Abgesehen vom Bundler gibt es das alles inzwischen auch in Node. Die Syntax des Test-Runners mag anders sein, aber TypeScript funktioniert standardmäßig „einfach so“, und der eingebaute Test-Runner ist durchaus brauchbar. Ich weiß nicht, ob man Bun deshalb so sehr betrauern muss.
- Fairerweise muss man sagen, dass Node diese Dinge nicht hatte, bevor Deno und Bun es herausforderten. Deno allein hat aus irgendeinem Grund keine großen Veränderungen ausgelöst, aber die Existenz von Bun hat das Technical Steering Committee von Node tatsächlich beeinflusst.
  Man kann auch sagen, dass Jarred Sumners kluges Social-Media-Marketing einen großen Teil des aktuellen Schwungs erzeugt hat. Er brachte die Leute zum Reden, und dadurch wurde auch Node besser.
  Außerdem hat Bun stark darauf gedrängt, möglichst viele Node-APIs zu unterstützen, wodurch Deno ebenfalls in Richtung derselben Kompatibilität gegangen ist. Inzwischen ist der meiste Code tatsächlich weniger stark an eine bestimmte Laufzeitumgebung gebunden. Ich weiß nicht, ob ich Bun in Produktion einsetzen würde, aber allein seine Existenz hat das JavaScript-Ökosystem deutlich verbessert, und das freut mich.
- Wann hat Node native TypeScript-Unterstützung hinzugefügt? Kann man wirklich ohne Abhängigkeiten einfach node main.ts ausführen?
- Wenn man sogar die Neuschreibung des TypeScript-Compilers berücksichtigt, wird Bun noch weniger relevant.
Ehrlich gesagt habe ich Bun nie besonders viel genutzt, außer gelegentlich zum Testen von Modulen. Im Alltag nutze ich überwiegend Deno und habe in den letzten Jahren auch viele Shell-Skripte mit Deno geschrieben.
Die aktuelle Nutzbarkeit gefällt mir ziemlich gut, und die Art, Module direkt aus dem Repository zu referenzieren, ist besonders für Shell-Skripte praktisch.
Ich frage mich allerdings, ob man damit bei offen gehaltenen Funktionen ausreichend Monetarisierung erreichen kann oder zumindest anderen ermöglichen kann, es zu klonen. Daher kann ich einen Teil der Sorge nachvollziehen.

jjpark78 3 시간 전

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

Wenn sie nur das hier beheben würden, würde ich es im Backend wohl mal ausprobieren...