Bun v1.0.0 – schnelles All-in-One-Toolkit zum Ausführen, Bauen, Testen und Debuggen von JavaScript und TypeScript

• Bun 1.0 verarbeitet das Ausführen, Bauen, Testen und Debuggen von JavaScript und TypeScript in einem einzigen Tool und ist nun stabil sowie produktionsreif
• Mit dem Ziel, Node.js zu ersetzen, unterstützt es Node-APIs und Modulauflösung wie fs, path, net, __dirname, process und die Auflösung von node_modules; auch Anwendungen auf Basis von Express, Koa, Hono sowie Next.js, Remix, Nuxt, Astro, SvelteKit, Nest, SolidStart und Vite laufen unter Bun
• Erstmals gibt es einen nativen Build für Windows, dieser ist jedoch stark experimentell; aktuell wird nur die JavaScript-Runtime unterstützt, während Paketmanager, Test Runner und Bundler deaktiviert sind
• Zu den Änderungen seit Bun 0.8 gehören die neu hinzugefügte Unterstützung für Next.js, Astro und Nest.js; der zuvor eingestellte Befehl bun dev wurde entfernt und führt nun stattdessen das "dev"-Skript aus package.json aus
• Neu unterstützte Node.js-APIs sind child_process.fork() und IPC, fs.cp(), fs.cpSync(), fs.watchFile(), fs.unwatchFile() sowie Unix-Sockets in node:http
• In die Runtime ist ein JavaScript-Transpiler integriert, sodass .js, .ts, .cjs, .mjs, .jsx und .tsx-Dateien ohne zusätzliche Abhängigkeiten ausgeführt werden können
• ESM und CommonJS werden gleichzeitig unterstützt, sodass import und require() in derselben Datei ohne Dateiendung oder die Einstellung "type": "module" in package.json verwendet werden können
• Web-Standard-APIs wie fetch, Request, Response, WebSocket und ReadableStream sind eingebaut und können ohne Pakete wie node-fetch oder ws genutzt werden
• Mit der Option --hot lässt sich Hot Reloading verwenden, und auch Bun.serve() wird dabei hot reloaded
• Die Bun-APIs Bun.file(), Bun.write(), Bun.serve(), bun:sqlite und Bun.password decken Datei-Ein/Ausgabe, HTTP-/WebSocket-Server, SQLite sowie das Hashing und Verifizieren von Passwörtern mit bcrypt und argon2 ab
• Der Paketmanager bietet bun install, bun add, bun remove und bun update und ist npm-kompatibel, da er package.json liest und in node_modules schreibt
• Der Test Runner bun:test bietet eine Jest-kompatible API und mappt @jest/globals- sowie vitest-Imports intern wieder auf bun:test
• Der Bundler unterstützt das Bundling und Minifying von JavaScript und TypeScript, bietet eine zu esbuild kompatible Plugin-API sowie JavaScript-Makros, die beim Bundling JavaScript-Funktionen ausführen und Werte inline einfügen

[GN⁺]

Hacker-News-Meinungen

• Ich arbeite an der Entwicklung von Bun mit. Wenn es Fragen gibt, kann ich sie beantworten.
  Es wäre gut, wenn ein Moderator den Link auf den Blogbeitrag ändern würde, weil er die Dinge besser erklärt als die GitHub-Release-Seite.
  Blogbeitrag: https://bun.sh/blog/bun-v1.0

  • Wurde von https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0 geändert.

• Am beeindruckendsten ist, dass man import und require() in derselben Datei verwenden kann und sich nicht um .js/.cjs/.mjs oder "type": "module" kümmern muss.
  Ohne das ist das Node.js-Ökosystem nahezu komplett kaputt, und Bun könnte es vielleicht retten. Das Großartigste an Bun ist meiner Meinung nach nicht die Performance, sondern die pragmatischen und entwicklerfreundlichen Entscheidungen, die Jarred konsequent getroffen hat.

  • Dieses Problem gibt es schon lange, und ich bin skeptisch, ob Bun es stärker „gelöst“ hat als andere Tools.
    Es hat lediglich einen anderen Kompromiss gewählt, was wahrscheinlich dazu führt, dass wiederum eine andere Menge an Paketen nicht funktioniert. Ich frage mich, ob es irgendeinen Grund gibt anzunehmen, dass Bun ein Geheimnis gelüftet hat, das andere Tools nicht lösen konnten.
  • Als Node vorgeschlagen hat, die Syntax aufzuteilen, habe ich mich dafür eingesetzt, genau diesen Ansatz zu unterstützen, und ich freue mich sehr, dass Bun ihn übernommen hat.
    Nach meinem Maßstab ist das der richtige Weg. Das gespaltene Ökosystem von Node hat der gesamten Sprache und Runtime erheblich geschadet.
  • Alle paar Jahre ergibt sich bei mir wieder eine Arbeit, bei der ich viel JavaScript verwenden muss, und als ich mich zuletzt wieder eingearbeitet habe, habe ich wegen import vs. require stundenlang gelitten.
    Wenn man keine React-App oder eine fertige Lösung verwendet, ist das moderne JS-Ökosystem wirklich schmerzhaft, besonders wenn man kleine Libraries baut. Ich kann mir kaum vorstellen, wie schwierig und wahnsinnig machend das für Einsteiger sein muss.
    Allein die Tatsache, dass Bun dieses Problem löst, ist Grund genug, es auszuprobieren. Ich hätte nicht gedacht, dass ich wegen noch einer JS-Runtime oder eines weiteren Build-Tools so erwartungsvoll sein würde, und ich freue mich darauf, dass mein Alltag dank des Bun-Teams etwas vernünftiger werden könnte.
  • Ich erstelle seit fast einem Jahr standardmäßig Modul-Projekte. Nachdem in TypeScript 5.0 die bundler-Auflösungsstrategie eingeführt wurde, waren die letzten sechs Monate größtenteils in Ordnung.
    Es gab sehr selten Probleme, aber bis die Projekte sie behoben hatten, habe ich sie mit pnpm patch und Metadaten-Anpassungen umgangen. 2023 kann man durchaus als Jahr der Module betrachten, und das Wasser ist in Ordnung.
  • Stimme zu. Eigentlich sollte ich inzwischen JavaScript-Experte sein, aber nichts lässt mich mich so dumm fühlen wie der Weg durch type: module und .js/.cjs/.mjs/.ts.
    In Produktions-Apps sollte natürlich klar sein, was man verwendet, aber beim Prototyping kann man dank Buns nachsichtigem Verhalten erst einmal Code schreiben und sich um den Rest später kümmern.

• Ich frage mich, ob man für ein 1.0-Release, das sich entschieden hat, nicht das gesamte node: zu implementieren, nicht eine bessere Formulierung als Drop-in-Ersatz verwenden könnte.
  Die ersten beiden Projekte, mit denen ich es versucht habe, waren nicht einfach per Drop-in ersetzbar, was ziemlich enttäuschend war, und jetzt misstraue ich der gesamten Kommunikation von Bun.
  Zum Kontext: Beide Projekte verwenden osc, das dgram benötigt. Ich habe ein neun Monate altes Tracking-Ticket für den Feature-Request gefunden, aber keinen Implementierungsplan, und wenn man auf der Ankündigungsseite nach dgram sucht, findet man nichts.
  Als schneller Vorschlag: Es wäre gut, die Module, die Bun 1.0 nicht unterstützt, explizit aufzuführen und in den Abschnitt zur Node.js-Kompatibilität aufzunehmen.
  Update: Ich habe die Dokumentation zur Node-Unterstützung gefunden — https://bun.sh/docs/runtime/nodejs-apis . Es wäre gut, sie in den Release Notes zu verlinken.
  Grob gezählt sieht es nach 17 implementierten, 17 teilweise implementierten und 7 nicht implementierten Modulen aus.

  • Die tatsächliche Version wirkt eher wie 1.0.0-beta als wie 1.0.0.
    Ich habe gerade v1.0.0 installiert und bun repl ausgeführt, was mit Exit-Code 1 fehlschlug; es stellte sich heraus, dass der REPL Port 3000 verwenden wollte, der in meiner Umgebung bereits belegt war. Den auf GitHub gemeldeten Bugs nach zu urteilen, dürfte es ziemlich viele solcher kleinen Probleme geben, daher sollte man allen Behauptungen mit einer gewissen Skepsis begegnen.
    Trotzdem bin ich von der Geschwindigkeit und dem Ergebnis sehr beeindruckt. Ich hätte nicht gedacht, dass dieses Projekt so schnell so weit kommt, sondern mit deutlich mehr Zeit gerechnet. Im Vergleich dazu hat Deno viel früher begonnen, wirkt jetzt aber weit zurückgefallen; für private Projekte werde ich Bun ausprobieren.
  • Entscheidend ist nicht, wie viele es sind, sondern welche Module.
    Anekdotisch: Wir testen Bun in einer großen Anwendung mit Millionen bestehender Kunden, und das bislang einzige Problem war nicht Bun selbst, sondern dass patch-package die Lockdatei bun.lockb noch nicht unterstützt.
    Bun ist zweifellos deutlich schneller als Yarn. Das sage ich als jemand, der Yarn wirklich mag.
  • Im Abschnitt zur Node.js-Kompatibilität steht bereits Folgendes:
    „Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.“
    In der detaillierten Liste sind die nicht unterstützten Module aufgeführt.
  • Ich stimme diesem Kommentar zu. Ich war wirklich gespannt und wollte es ausprobieren, aber die meisten unserer Projekte ließen sich nicht ausführen.
    Wegen eines Fehlers beim Parsen von Antworten konnten wir AWS SDK v3 nicht verwenden, und weil node:crypto nicht vollständig implementiert ist, konnten wir Dinge nicht nutzen, die von octokit oder jsonwebtoken abhängen. Da jest.resetAllMocks() fehlt, konnten wir die Tests nicht laufen lassen, und in einem anderen Projekt startete bun test gar nicht erst, weil es einen Aufruf einer Shared Library als fehlerhaft meldete.
    Unser lokaler Workflow ist daher: „Mit Bun ausführen und, wenn es fehlschlägt, erneut mit Node ausführen.“ Als npm-Ersatz kann man es zumindest verwenden, aber es ist noch schwer vorstellbar, damit Services auszuführen. Wenn es funktioniert, ist es wirklich beeindruckend, daher freue ich mich auf die Zukunft; aber wenn das Verkaufsargument Node-Kompatibilität ist, fällt es mir schwer, das 1.0 zu nennen.

• Ich frage mich, ob es Überlegungen gab, den Community-Chat auf eine andere Plattform als Discord zu verlegen.
  Discord wurde auf HN wegen Barrierefreiheit, Datenschutz und Abhängigkeit von einer proprietären Plattform mehrfach thematisiert und scheint auch nicht besonders gut zum Open-Source-Gedanken zu passen. Auch [1] ist lesenswert.
  [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

  • Selbst wenn es wichtig ist, Discord nicht zu nutzen, scheint eine Änderung eher unwahrscheinlich.
    In den Kommentaren zur Ankündigung von Bun 0.6 bekam eine ähnliche Frage so viele Downvotes, dass sie fast geflaggt wurde: https://news.ycombinator.com/item?id=35970869
    Auch in den Kommentaren zur Ankündigung von Bun 0.8 fand dieselbe Frage kaum Beachtung; die Reaktion war ungefähr: „Andere Projekte nutzen es ja auch …“: https://news.ycombinator.com/item?id=37244294
  • Die Barrierefreiheit von Discord hat sich ziemlich stark verbessert. Auch der Screenreader-Nutzer im Quellenabschnitt dieses Artikels stimmt inzwischen zu, dass die Barrierefreiheit von Discord besser geworden ist und dass mehr blinde Menschen es nutzen.
    Ehrlich gesagt ist Discord ein guter Ort für die Kommunikation von Free- und Open-Source-Softwareprojekten. Die Argumente des Artikels, „wenn man Discord wählt, legitimiert man die Plattform und entzieht FOSS-Plattformen Wert“, wirken ziemlich wackelig. Discord ist tatsächlich eine legitime Plattform, kostenlos, hat viele attraktive Funktionen und eine gute Barrierefreiheit. Vor allem verschwindet der Wert von FOSS-Kommunikationsplattformen nicht, nur weil man Discord wählt.
    Auch der Rat „Nutzt IRC“ passt nicht. IRC ist für viele Menschen, die mit Computern und Software nicht vertraut sind, sehr schwer zugänglich.
  • Gibt es eine FOSS-Alternative zu Discord, die kein Geld kostet?
  • Könnte answeroverflow.com eine Übergangslösung sein?

• Bun ist Venture-finanziert, daher interessiert mich der Monetarisierungsplan.
  Wenn ich mir eine neue Technologie ansehe, frage ich: „Wie wahrscheinlich ist es, dass diese Technologie in N Jahren noch aktiv entwickelt wird?“ Bun muss auf die eine oder andere Weise Geld verdienen, sonst versiegt die Finanzierung.
  Dass Buns Lizenz MIT ist, ist großartig und gibt Hoffnung, dass das Projekt nicht sterben muss, selbst wenn das Unternehmen scheitert. Ich hoffe, dass das Unternehmen Erfolg hat, aber wenn ich Bun einführe, würde mich interessieren, welche Art von Upsell später kommen könnte.

  • Der Geschäftsplan ist unter https://oven.sh/ beschrieben.
    Oven wird sehr schnelles Serverless Hosting und Continuous Integration für Backend- und Frontend-JavaScript-Apps anbieten und von Bun betrieben werden.
    Unterstützt werden sollen Frontend-Frameworks wie Next.js, Vite, SvelteKit und SolidStart sowie Backend-Frameworks wie Express, Fastify und NestJS.
    Geplant ist, eigene Server am Edge von Rechenzentren weltweit zu betreiben; Oven will den gesamten JavaScript-Stack bis hinunter zur Hardware End-to-End integrieren und so neue Möglichkeiten schaffen.
  • Da es ein Bundler ist, werden sie vermutlich mit dem Hosting von JS-Apps Geld verdienen, etwa in Form von bun deploy.
    Das ist eine gängige Strategie: zuerst in großem Maßstab Entwickleradoption gewinnen und sie dann sanft in Richtung des eigenen Application Hostings lenken.
  • Früher gab es einen tollen HMR-Dev-Server namens Pundle. Er war schnell genug, um sofort zu reagieren, wurde aber auch nur von einer Person aus einem armen Land gepflegt.
    Der Versuch, dem Side Project einer Einzelperson zu folgen, war so mühsam, dass wir alles auf Rollup umgestellt und nicht zurückgeblickt haben.
    Die Sorgen bei einem Venture-finanzierten Projekt und einem zufälligen Side Project sind sicher unterschiedlich, aber das grundlegende Risiko ist bei beiden: „Was passiert, wenn die Person, die es gebaut hat, mich nicht mehr unterstützen kann?“
  • Ich vermute, es wird in Richtung NextJS/Vercel oder Deno/Deploy gehen, und auch eine Lizenzänderung würde ich nicht ausschließen.
    Das Muster ist, alles als „Open Source“ zu bewerben, um kostenlose Bugreports, Beiträge, Marketing und Adoption zu bekommen, und es anschließend in ein kommerzielles Produkt zu schieben.

• Die Aussicht, das übereinandergeschichtete Chaos Node-basierter Tools ersetzen zu können, ist sehr attraktiv.
  Denn dadurch ließen sich node, ts-node, nodemon, tsc, jest, ts-jest, webpack, Babel, zwei nicht zueinander passende Modulspezifikationen, das UMD-Chaos, drei Paketmanager und die dadurch explodierende Zahl an Konfigurationsdateien reduzieren.
  Das Tooling-Umfeld rund um JavaScript ist definitiv der größte Schmerzpunkt und macht ES6 + TypeScript, eigentlich eine recht leistungsfähige und angenehme Sprache, zu reiner Plackerei. Ich hoffe, Bun schafft das.
  Es dürfte sich ähnlich anfühlen wie der Wechsel von CMake zu Cargo.

• Der Blogpost vermittelt das Wertversprechen einfacherer All-in-one-Software sehr überzeugend.
  In letzter Zeit spricht mich „batteries included“-Software stärker an als „bring alles selbst mit“, daher freue ich mich darauf, Bun auszuprobieren.
  Es fühlt sich an wie die Runtime-Version der Rome-Tools, die mehrere Softwarekomponenten durch eine schnellere einzelne ersetzen wollten. Rome ist gescheitert und als OSS unter einem neuen Team weitergeführt worden. Ich hoffe, Bun hat mehr Erfolg, aber es ist eindeutig ein schwer zu lösendes Problem.

  • Dem „batteries included“-Ansatz stimme ich zu. Wenn das Node.js-Ökosystem von Anfang an harmonisch gewesen wäre, bräuchte es diesen Ansatz nicht.
    Wenn man wie Apple Hardware und Betriebssystem selbst besitzt und kontrolliert, kann man das System tief optimieren und zugleich die Sicherheit geben, dass alle Geräte reibungslos zusammenspielen. Ein All-in-one-Toolset reduziert die Last, ständig der perfekten Lösung hinterherzulaufen, und lässt einen die Lösung nutzen, die bereits direkt vor einem liegt.

• Von Leuten, die sowohl Bun als auch Deno ausprobiert haben, würde ich gern hören, was in der Praxis der überzeugendere Node-Nachfolger ist.
  Die Bun-Website behauptet, deutlich performanter als Deno zu sein; ich frage mich, ob das in der Praxis wirklich stimmt. Falls ja, würde ich auch gern wissen, warum. Deno scheint ähnliche Ziele zu verfolgen.
  Ich frage mich auch, ob es große philosophische Unterschiede zwischen den beiden Projekten gibt. Etwa in dem Sinne, dass Bun alles Mögliche neu implementieren will, während Deno einen neuen Weg nach Node anstrebt — ich weiß es nicht. Gibt es jemanden, der beide ausreichend genutzt hat?

  • Beide ziehen mich nicht besonders an, aber ich frage mich grundsätzlich, warum überhaupt ein Node-Nachfolger nötig ist.
    Sowohl Bun als auch Deno sind Tools mit Venture-Capital-Finanzierung, weshalb ich grundsätzliche Zweifel an Monetarisierung und Nachhaltigkeit habe.
    Buns wichtigstes Verkaufsargument scheint Performance zu sein, aber ich hatte mit Node selten größere Performance-Probleme. Es ist nicht rasend schnell, aber man stößt sehr viel eher an I/O-Grenzen als an die Geschwindigkeit von Node.
    Denos wichtigstes Verkaufsargument war in vielerlei Hinsicht ein „richtig gemachtes Node“: besseres Packaging, vollständige Nutzung von ES6 usw. Dieses Argument fand ich attraktiv, aber offenbar hat man den Versuch aufgegeben, ein neues Ökosystem aufzubauen, und stattdessen Node-Kompatibilität ergänzt.
    Gleichzeitig sind jüngere Verbesserungen in Node selbst, etwa der eigene Test-Runner und eingebaute .env-Unterstützung, ermutigend. Deshalb fällt es mir schwer, einen starken Grund für Bun oder Deno zu finden; und selbst wenn man wechselt, bräuchte man einen konkreten Weg zurück zu Node, falls die neue Tool-Generation nicht nachhaltig ist.
  • Diese Tools sind zu jung, als dass wirklich jemand sagen könnte, er habe sie sehr lange genutzt.
    Bun bündelt alles und macht es sehr schnell, während es versucht, so weit wie möglich kompatibel mit Node zu bleiben. Es wirft das bestehende Ökosystem nicht weg.
    Deno hat dem Node-Ökosystem gegenüber eine zu konfrontative Haltung eingenommen und ergänzt jetzt wieder Support dafür.
    Aus Nachfolger-Perspektive sehe ich Bun als die einzige Option, weil es Node-Kompatibilität beibehält und zugleich mit neuen Funktionen innovieren will.
  • Ich bin kein Power-User und habe hauptsächlich mit Deno herumprobiert.
    Deno wirkt eher wie eine alternative Node-Runtime mit Sicherheit als oberstem Prinzip, inklusive eingebautem Support für TypeScript und JSX sowie Tools wie einem Linter. Es basiert ebenfalls auf V8. Es wirkt wie das, was Ryan Dahl im Nachhinein offenbar für die Form hielt, die Node hätte haben sollen.
    Bun basiert technisch auf WebKit, wobei ich nicht genau weiß, warum, und wirkt nicht nur wie eine Runtime, sondern eher wie ein besseres All-in-one-Tool. Es bietet auch standardmäßig Kompatibilität mit bestehenden Frameworks. Deno war bis vor Kurzem nicht npm-kompatibel, und ich frage mich, ob das von Anfang an so beabsichtigt war oder ob es sich um eine laufende Kursänderung handelte.
  • Wir sind ein Full-Stack-TypeScript-Team und verwalten etwa 50 interne Libraries sowie rund 500.000 Zeilen TypeScript.
    Im letzten Monat haben wir sowohl Deno als auch Bun als alternative Runtimes getestet. Kurz gesagt: Bei einer einigermaßen komplexen Codebase funktioniert Bun fast immer, während Deno fast immer nicht funktioniert.
    Derzeit führen wir alle Tests sowohl mit Node.js als auch mit Bun aus und haben den Versuch, Deno einzuführen, aufgegeben.
  • Wenn ich mich richtig erinnere, unterstützt Bun im Gegensatz zu Node/Deno kein Windows.
    Edit: Scheint sich zu ändern. Danke für die Korrektur.

• Ursprünglich war geplant, es gestern zu releasen, aber es gab einen fehlgeschlagenen Test für fetch()-Body-Streaming, der behoben werden musste.
  Der Blogbeitrag sollte eigentlich erst veröffentlicht werden, wenn Bun 1.0 auf GitHub verfügbar ist, aber der Link war öffentlich zugänglich, und es gab einen Bug, durch den der Entwurf im RSS-Feed nicht verborgen wurde.
  Der eigentliche Bug lag nicht beim fetch()-Body-Streaming, sondern in einem JavaScriptCore-Binding, das eine Property von einem Objekt holte, bei dem diese Property möglicherweise nicht definiert war. Ein Teil des Codes prüfte nicht, ob der Wert ein Objekt war, sondern nur, ob er ein JSCell war; JSCell ist normalerweise ein Objekt, aber Dinge wie Symbole oder BigInt sind keine JSObjects.
  Thread von gestern: https://news.ycombinator.com/item?id=37424724

  • Im Installationsabschnitt der Linux-Dokumentation fehlen DEB/RPM; es wäre gut, das zu aktualisieren.
    Als zusätzlicher Hinweis: Für Installationen nach dem Muster „aus dem Internet herunterladen statt aus dem Distributions-Repository“ könnte man Beispiel-Playbooks bzw. Task-Sets für Ansible mit passenden Prüfsummen wie SHA-256 bereitstellen. Für Puppet gilt das ebenfalls, wäre aber etwas komplexer.
    Das könnte Systemadministratoren etwas Arbeit abnehmen; und wenn man dem Ganzen einen Namen geben möchte, könnte man es SAX nennen, also System Administrator Experience.

• Ich frage mich, welchen Vorteil es hat, Vite.js darüber zu verwenden, wenn Bun TypeScript-React-Apps nativ ausführen und bundlen kann.
  Der Guide auf der offiziellen Website zeigt, wie man beim Erstellen einer TypeScript-React-App Bun + Vite.js verwendet, was verwirrend ist. [1]
  Auf GitHub gibt es dazu ebenfalls ein Issue. [2]
  Übernimmt Vite.js komplexere Szenarien oder fortgeschrittene Anwendungsfälle, die Bun nicht abdeckt? Meine Nutzung von Vite.js beschränkt sich darauf, mit einem einfachen TS+React-Setup zu starten und zu bauen; vielleicht übersehe ich also etwas.
  [1] https://bun.sh/guides/ecosystem/vite
  [2] https://github.com/oven-sh/bun/issues/250

  • Vite nutzt weiterhin Node, esbuild, swc, tsc usw. für Teile, für die es nicht selbst verantwortlich ist.
    Ich habe Bun noch nicht selbst ausprobiert, aber so verstehe ich es: Für den lokalen Entwicklungsserver kann man Bun statt Node verwenden, fürs Bundling Bun statt esbuild, tsc, Rollup oder einer Kombination davon, und für Transformationen Bun statt Babel und TypeScript.
    Was Vite bietet, ist eine Konfiguration, die die Entwicklung von Frontend-Anwendungen einfach einrichtet und lokal eine gute Developer Experience liefert.
  • Vite zusammen mit Bun habe ich bisher nur für HMR gesehen.
    Wegen der noch vorhandenen Konfigurationskomplexität finde ich die Kombination der beiden derzeit nicht besonders attraktiv.
  • Von Leuten zu verlangen, ein ganzes Ökosystem auf einmal zu übernehmen, ist eine große Hürde.
    Kompatibilität mit dem bestehenden Ökosystem ist ein zentrales Ziel von Bun; es soll ermöglichen, Bun direkt in bestehenden Codebases zu verwenden und schrittweise in immer mehr Bereichen einzuführen.
  • Man dürfte das Plugin-Ökosystem von Vite nutzen können, also Dinge wie PostCSS, Tailwind und Terser.
    Und da die meisten neuen Meta-Frameworks wie Nuxt, SvelteKit, Astro, SolidStart und Qwik auf Vite laufen, kann das einen Einstiegspfad für die Einführung von Bun eröffnen.
  • Das ist ähnlich wie die Frage, warum man Vite braucht, wenn es doch tsc gibt.
    Ich würde sagen, Bun „führt TypeScript-React-Apps aus“ weniger im umfassenden Sinne, sondern stellt eher JSX/TSX-Transformationen standardmäßig bereit.