Bun v1.0.0

I work on Bun. Happy to answer any questions<p>Could the mods change the link to the blog post? It explains better than the github release page<p>Blog post: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;bun-v1.0" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;blog&#x2F;bun-v1.0</a>

<p><pre><code> &gt; The transition from CommonJS to ES modules has been slow and full of terrors. &gt; Bun supports both module systems, all the time. No need to worry about file &gt; extensions, .js vs .cjs vs .mjs, or including &quot;type&quot;: &quot;module&quot; in your &gt; package.json. &gt; &gt; You can even use import and require(), in the same file. It just works. </code></pre> This is the highlight for me. The Node.js ecosystem is more-or-less completely broken otherwise. This might save it.<p>(I think that the most impressive thing about Bun isn&#x27;t its performance but the pragmatic, developer-friendly choices that have been consistently made by Jarred.)

Is there a better phrasing you could use than &quot;drop-in replacement&quot; for a 1.0 release that has decided to not implement all of &quot;node:&quot;?<p>The let-down from the first two projects not being a drop-in replacement is jarring, now I have to be skeptical of <i>all</i> communications coming from bun.<p>For context, both projects use osc which requires dgram. I was able to find a feature request tracking ticket from 9 months ago with no communicated plans to implement, but searching for &#x27;dgram&#x27; in this announcement page doesn&#x27;t show anything.<p>For a quick suggestion - can you explicitly state what modules are not supported by bun 1.0 and put that in the section related to node.js compat?<p>edit: found the docs on node support - <a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;nodejs-apis" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;nodejs-apis</a> . Would be nice to link in the release notes.<p>Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented

Congrats!<p>This has probably been asked before, but has there been any thoughts about moving community chat to a platform other than Discord? Discord has been brought up many times on HN for its accessibility&#x2F;privacy&#x2F;proprietary lock-in concerns that don&#x27;t seem to be in line with the spirit of open-source. Also see [1].<p>[1] <a href="https:&#x2F;&#x2F;drewdevault.com&#x2F;2021&#x2F;12&#x2F;28&#x2F;Dont-use-Discord-for-FOSS.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;drewdevault.com&#x2F;2021&#x2F;12&#x2F;28&#x2F;Dont-use-Discord-for-FOSS...</a>

Since Bun is VC backed, what is the monetization plan? One of the things I consider with new tech is &quot;how likely will this tech still be actively developed in N years.&quot; Bun will need to make money somehow or funding will be pulled.<p>I see bun&#x27;s licensing is MIT, and that is fantastic. So that does give me some hope it won&#x27;t die should the business go under. I hope the business succeeds, but I&#x27;m curious should I adopt bun, what might the upsell be down the road.

The proposition of replacing the layered morass of node-based tooling (node, ts-node nodemon, tsc, jest, ts-jest, webpack, BABEL, 2 incompatible module specs, UMD insanity, 3 package managers!) and the Cambrian explosion of config files that it leads to is super compelling.<p>The tooling situation around JavaScript is certainly my biggest pain point around it and turns a really very capable and pleasant language (ES6 + TS) into a complete chore. Here’s hoping that Bun can deliver.<p>It has to be a similar feeling as going from CMake to Cargo.

Congrats! Your blog post paints a very compelling value proposition for simpler, all-in-one (yet extensible) software. I find I&#x27;m more compelled these days by &quot;batteries included&quot; software than &quot;bring your own everything&quot;, so I&#x27;m excited to try this out.<p>It reminds me as a runtime version of Rome tools, which had a similar goal (replace a bunch of software with a single faster one). It went under and has [transition to OSS under a new team](<a href="https:&#x2F;&#x2F;biomejs.dev&#x2F;blog&#x2F;annoucing-biome" rel="nofollow noreferrer">https:&#x2F;&#x2F;biomejs.dev&#x2F;blog&#x2F;annoucing-biome</a>). I hope you find more success than they did! It&#x27;s certainly a hard problem to solve.

I would be interested to learn from somebody with experience using both Bun and Deno: which one is actually the more compelling Node successor? Bun&#x27;s website makes some impressive performance claims over Deno. Are these true in practice? And if so, why? Seems like Deno also has similar goals. Also, are there large philosophical differences between the two projects? Like Bun tries to reimplement the kitchen sink but Deno wants a new post-Node way of doing things? (Just guessing, no idea if that&#x27;s true.)<p>Any seasoned users with time spent on both?

We originally planned to release yesterday, but there were test failures in fetch() body streaming that needed to be fixed. The blog post was not meant to be public until Bun 1.0 was available on GitHub, but the blog post link was publicly accessible and our RSS feed had a bug that didn&#x27;t hide drafts<p>The specific bug ended up not being in fetch() body streaming, but in our JavaScriptCore binding for getting a property from an object that may not have defined the property. Not all of our code was checking that the value was an object (only that it was a JSCell, which usually is an object, but things like symbols and BigInt are not JSObject)<p>Thread from yesterday: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37424724">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37424724</a>

If Bun is able to run and bundle a TypeScript React app out-of-the-box, what are the benefits of using Vite.js on top of it?<p>I&#x27;m confused cause this guide on the official site showcases how to use Bun + Vite.js to build a TypeScript React app. [1]<p>There is also this issue on their Github. [2]<p>Can Vite.js be used to handle more complicated scenarios &#x2F; advanced use cases that Bun doesn&#x27;t handle? My use of Vite.js is pretty basic (start &amp; build with the default TS+React config) so maybe I&#x27;m missing something here.<p>--<p>[1] <a href="https:&#x2F;&#x2F;bun.sh&#x2F;guides&#x2F;ecosystem&#x2F;vite" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;guides&#x2F;ecosystem&#x2F;vite</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;250">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;250</a>

Looks great but the fact that it uses zig which is pre 1.0 and describes itself “not for use in production” gives me pause.<p>Realistically how much of a problem is this likely to be?

Jarred congrats for the release!<p>I&#x27;ve been following the progress of bun since your initial announcement and today I decided to give it a try, just to play around.<p>Haven&#x27;t done much with it, but even for the 5 min I played with it I&#x27;m kind of impressed so far.<p>- Superquick install PLUS did not require root (like many other installs)<p>- It identified I was using fish shell and added to path (nice!)<p>- I ran a very quick bench on &quot;npm install&quot; vs &quot;bun install&quot; on one of the projects I have, and the performance is amazing. 50seconds vs 4.5 seconds on the first install. Moreover re-executing &quot;bun install&quot; takes 122ms on my machine. Removing node_modules and re-executing it takes 769ms (because of course, it uses a local cache elsewhere, but still). Amazing.<p>I&#x27;ll probably continue exploring tomorrow and see whether it is able to run the rest of the backend&#x2F;frontend or whether it gives me a hard time. I&#x27;ve seen there are certain things that are not 100% compatible with node yet, but since the initial impressions are great I&#x27;ll explore further.<p>BTW A code formatter and a linter would be a great addition to bun.<p>I know there is this ticket: <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;discussions&#x2F;712">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;discussions&#x2F;712</a><p>But one of the advantages of integrating both things in bun is that it makes it the perfect standard tool to be used inside of a team. So no extra installations from other projects, no extra mental burden of what to use, etc... bun would be the perfect dev companion with both ;)<p>Probably a linter is a different beast (and not sure you or the rest of people working in bun want to get in there... probably not important right now), but a formatter seems doable and it does add a lot of value from my point of view. Given that bun already runs, installs, tests and bundles, to the very least _formatting_ seems like a natural addition to the family. To me a formatter is part of the standard toolset for developers nowadays.<p>Once again, thanks a lot for the effort to you and the rest of the people contributing to the project!<p>(edit: re-formatted my comment :p)

Personal experience: Bun has been a flawless drop-in replacement for both NodeJS and npm&#x2F;yarn since I started using it around v0.4. Not only have I had zero issues running it, but it&#x27;s been WAY faster. No benchmarks, but very noticeable, from &quot;let&#x27;s start a new build and go grab a coffee while waiting for it&quot; on NodeJS, to &quot;hit run aaaaand it&#x27;s done.&quot;<p>I haven&#x27;t thought twice about it. Frankly, I forgot that bun has been happily running behind the scenes for me. I highly recommend anyone using NodeJS to give it a go.

Oh its a Friday. Deploying on Fridays is what we do. Here you go ... Bun 1.0 officially deployed on Platform.sh <a href="https:&#x2F;&#x2F;platform.sh&#x2F;blog&#x2F;bun-support-is-here&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;platform.sh&#x2F;blog&#x2F;bun-support-is-here&#x2F;</a> enjoy.

There was some criticism yesterday about bun being stable using a language (zig) that isn&#x27;t considered stable. Do you care to comment about it?<p>Ref: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37422894">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37422894</a>

Bun ships features and improvements fast and often, which is great<p>But from anecdotes, I have the impression people still run into bugs and missing functionality semi-commonly. I&#x27;m sure it works great for small&#x2F;personal projects, but I&#x27;ve been hesitant to recommend it for production use at my workplace because of this impression<p>So my question is: how feature-complete&#x2F;stable&#x2F;secure is it right now, what does the v1.0 label say about that, and what are the long-term plans&#x2F;prioritization&#x2F;guarantees around this area?

How does Bun support CJS and ESM in the same file? Is it transpiling CJS to ESM? Or is it transpiling ESM to CJS?<p>ESM can use top-level await and CJS can&#x27;t. So this can&#x27;t possibly work, right?<p><pre><code> &#x2F;&#x2F; x.mjs export const x = await &#x27;x&#x27;; &#x2F;&#x2F; y.cjs console.log(require(&#x27;.&#x2F;x.mjs&#x27;).x); </code></pre> And, indeed, it doesn&#x27;t work in Bun. When I `bun y.cjs` it gives me this error message:<p><pre><code> TypeError: require() async module &quot;&#x2F;tmp&#x2F;x.mjs&quot; is unsupported. use &quot;await import()&quot; instead. </code></pre> … but using &quot;await import()&quot; instead is exactly what I was trying to avoid! I can use &quot;await import()&quot; in Node, too.<p>But it looks like it does work in Bun if I drop the `await` from y.mjs. So, is it just transpiling ESM to CJS, and failing out if the ESM uses top-level await?<p>EDIT: I see the documentation page <a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;modules" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;runtime&#x2F;modules</a> has a &quot;low-level details&quot; section, explaining how import(CJS) works (by transpiling CJS to ESM), but it doesn&#x27;t say anything there about how require(ESM) works, which is unfortunate, because that&#x27;s by far the most interesting part! I&#x27;ve filed a doc bug on this. <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;4601">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;issues&#x2F;4601</a>

You write typescript and unit test without tsc, jest, webpack&#x2F;esbuild or a ton of config files. bun projects can be super lean and still cough out a tested bundle.js for execution on a browser.<p>I love it, it super simplifies project and for minimalists it&#x27;s perfect.

Love bun, but I disagree that blog post explains better what v1 is, but rather explaining what bun is in general.<p>It hardly mentions anything until the very bottom on what&#x27;s changed to reach v1, the github release page on the other hand clearly outlines it.<p>Personally found the blog post to read like documentation rather than a release announcement.

The fact that Bun has taken VC funding [0] (through Oven, the company behind Bun) makes me skeptical. There is also no mention of this on the project&#x27;s homepage.<p>[0] - <a href="https:&#x2F;&#x2F;oven.sh&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;oven.sh&#x2F;</a>

I love that you engage with the community on both HN and Twitter. It&#x27;s always interesting to see your polls on how certain features should be implemented.<p>Any plans for other interesting experimental features (like macros)?<p>I don&#x27;t know how much this is still a problem, but a few years ago one area where I used to experience a bit of pain was that package.json scripts would get pretty unwieldy and supporting windows required using third-party tools. Have you consider experimenting a bit with the scripts or are you happy with the state of that feature?

from that blog post:<p>&quot;<i>Unlike Node.js and other runtimes that are built using Google&#x27;s V8 engine, Bun is built using Apple&#x27;s WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It&#x27;s fast, efficient, and has been battle-tested for decades.</i>&quot;<p>That&#x27;s really interesting, does WebKit do less JITing or something to be faster for startup?

Congrats on the launch! The NextJS guide[0] claims that bun doesn&#x27;t support all the node APIs to run the dev server, is that still the case with 1.0?<p>[0]: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;guides&#x2F;ecosystem&#x2F;nextjs" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;guides&#x2F;ecosystem&#x2F;nextjs</a>

Congratulation to the project, it seems incredible.<p>I don&#x27;t know that much so I have some questions, sorry if they&#x27;re already answered. (share link if any if its possible)<p>Do you plan to support as much as possible the Node.js API (99%) or most features and make your own API for lets say Clustering module and such ?<p>Speaking of Cluster module, do you want to recreate Node.js Cluster module, or do you plan to create your own way for multi-processing using Bun in a more performant way ?<p>I&#x27;ve seen Deno putting a lot of effort into the platform around their runtime, making deploying Deno app easy, is that your goal too ?<p>I&#x27;ve seen that you use Zig instead of C++, what do you like the most about Zig while working on Bun ?<p>In anyway, I hope the project will make the JSRuntime world better, its promising.

How compatible is Bun with Remix[0]?<p>I’ve been loosely following the progress of Bun for awhile, but I haven’t actually tried it. The blog post you linked does make it sound very intriguing.<p>[0]: <a href="http:&#x2F;&#x2F;remix.run&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;remix.run&#x2F;</a>

Dumb question: since Bun is MIT licensed - why doesn’t Node just merge Buns code into Node?<p><a href="https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;project&#x2F;licensing" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;docs&#x2F;project&#x2F;licensing</a>

Are there any downsides? Cause from this blog post it sounds like I should just ditch everything I was doing and move completely to Bun.

Seems good! I really like the ability to combine CommonJS and ESM modules, and the built-in file-watcher. My reluctance is two-fold: nodejs is still dominant and mainstream, and Bun is VC funded which, as others have mentioned, doesn&#x27;t bode well for its longevity (I realize this concern is a bit circular, since it&#x27;s longevity would be improved with adoption). (It&#x27;s just that I&#x27;ve been burned adopting marginal technologies in the past. In the JavaScript space, I always liked Brunch, but it never caught on. In the Java space, I always preferred Dropwizard to the Spring Boot complexity, but it also never caught on.)

Seems very cool but hitting 1.0 without full windows support do not inspire me confidence. Using tools that consider your environment a second class citizen is never a great idea... I will give it a try in WSL though.

On your github release page [1], there are both &quot;bun-darwin-x64.zip&quot; and &quot;bun-darwin-x64-baseline.zip&quot;. What is the difference between them? Why the &quot;aarch64&quot; binaries don&#x27;t have the baseline versions?<p>In addition, your &quot;bun-linux-x64.zip&quot; doesn&#x27;t work on CentOS7 due to glibc compatibility. Would be good to provide a more portable binary.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;releases&#x2F;tag&#x2F;bun-v1.0.0">https:&#x2F;&#x2F;github.com&#x2F;oven-sh&#x2F;bun&#x2F;releases&#x2F;tag&#x2F;bun-v1.0.0</a>

&gt; It reads your package.json and writes to node_modules, just like other package managers, so you can replace:<p>&gt; ...<p>&gt; pnpm<p>pnpm&#x27;s flagship feature is global deduplication of packages, so sadly bun&#x27;s package manager doesn&#x27;t seem to be a replacement. Is there any plan or intention to support pnpm-like disk saving? (I suppose not having to esbuild etc. everywhere already helps.)<p>That said, I&#x27;m very impressed with the speed of `bun add` with already cached packages. Literally instant.

My experiences with Bun so far have been excellent. Its package manager and bundler in particular are extremely fast and pleasant to use. Not needing to care about transpilation or using ts-node for development is also wonderful. For all the tools I cared about, compatibility has been well documented.<p>I would have trusted it in production before 1.0 and moreso now. Unfortunately, I cannot use it for most projects right now. I package my applications with Nix for deployment and Nix and bundling JS dependencies is mostly not a great story right now. buildNpmPackage works just fine most of the time, but requires that I use npm to bundle my dependencies.<p>Of course, this is no fault of Bun whatsover. Bun can emit a yarn.lock that is compatible with Yarn 1. If it could also emit a package-lock.json that might unblock my use case. The more ideal solution would be to build an equivalent of buildNpmPackage that deals directly with Bun, but I&#x27;m afraid the effort would not be worth it right now.

It really seems impressive to me. I think I&#x27;ll try it as a tool first, later as a runtime. Just wondering why has been built using Apple&#x27;s WebKit engine vs V8, other then what they say on the blog which is just shallow infos. Anyone has a link to share or any better explanation?

I would like to ask if the BETH stack is the most suitable to work with Bun, and what are the recommendations from the community. I would like to start a project using this runtime.

OK, I&#x27;m impressed. It took 0.01s to run &#x27;bun install react&#x27;:<p><pre><code> % cd &#x2F;tmp % mkdir app % cd app % time bun install react bun add v0.6.1 (78229da7) installed react@18.2.0 3 packages installed [20.00ms] bun install react 0.01s user 0.01s system 50% cpu 0.041 total % find node_modules | wc -l 41</code></pre>

Is there an example one step above &quot;Hello world&quot; that new users can take a look at? There are a bunch of guides for different API&#x27;s &#x2F; constructs but I&#x27;m wondering if there&#x27;s a canonical example to get started.<p>Guides: <a href="https:&#x2F;&#x2F;bun.sh&#x2F;guides" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;guides</a>

Wondering what (if any) telemetry data Bun collects? Ever since the telemetry in front-end tools website (<a href="https:&#x2F;&#x2F;telemetry.timseverien.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;telemetry.timseverien.com&#x2F;</a>) was shared here a few months ago I&#x27;ve been wondering the same for other tools.

I love how much it includes out of the box. I wrote a little zero-dependency app in TypeScript. It’s got SQLite, routing, etc. It even understands JSX. The only tricky bit was writing a ~100 line JSX-to-HTML function. It’s quite nice and starts so much faster than the normal Node + npm + essbuild stack.

What happens with circular require&#x2F;import calls? Anything weird when requiring&#x2F;importing the same file, such as instantiating multiple singletons? The two systems have fundamentally inverted trees when it comes to running JavaScript files and I&#x27;m curious if anything funny happens.

Hi Jarred,<p>The docs say that Bun uses clonesfiles &#x2F; hardlinks (yay). But it also states that clonefiles don&#x27;t benefit space saving:<p>&gt; This benefit does not extend to macOS, which uses clonefile for performance reasons<p>As far as I know, clonefiles are COW, which should not take any space except the extra inode.

Congrats on the release. May I ask if the company is still hiring C++ engineer? I work full time in system programming, and the job post says &#x27;post something you built with bun along with resume&#x27; which really confused me as I don&#x27;t typically build things ON Bun.

It’s been so fun watching Bun progressing as quickly as it has! Truly incredible work, and the blog post is full of real value and time saved for future me from beginning to end - huge congrats on the 1.0.0 release, excited to see where bun goes from here!

Amazing work Jarred.<p>I am still absolutely amazed at how much more performant websockets throughput in bun vs node.<p>Congrats on 1.0!

Just wanted to say thanks. I’ve not been as excited to tryout some new tech in a *long* time.

I have been testing out Bun w&#x2F; Nest JS, and oddly it can run a dev server but can&#x27;t run my E2E tests (using the Bun test runner). I think this has something to do with Nest&#x27;s heavy reliance on old-school TS decorators.

Wow, that is a compelling landing page. It&#x27;s almost too good to be true! Is it fudging the numbers or using highly cherry-picked examples? Or is it really that much better than the competition?

A few weeks ago, I tried to compile a little bit of TS code and was shocked at how long it took. 5 seconds! I can&#x27;t believe people put up with this. Glad to see there is a solution.

Congrats on the launch! I have been following Bun’s journey since the beginning. Excited to make the transition once it’s got more compatibility with our Node tooling (prisma specifically).

Has anyone managed to run a non trivial Nest.js application with bun already?<p>With non trivial I mean an application using a lot of Nest.js features and libraries like TypeORM, Swagger-UI.

If someone from the Nuxt team is around: I have 5+ projects with different module usage and all of them just log when trying to run bun —bun run dev:<p>ERROR Cannot build module „nuxt“ {}

Hey Jarred, congrats on the 1.0 release!<p>I&#x27;ve tried this release on one of my projects and encountered some errors, where is the best place to send reports about compatibility issues?

Would love to see bun work as a replacement for electron, using the existing os web browser, similar to neutralino, tauri, and muon. All told Im super excited to try this.

Why would I want to choose Bun instead of Deno?<p>As a library author, how convenient is it to have one suite of tests that can execute in both Bun and Node.js? (E.g. with jest?)

Would be amazing if this had its own formatter and linter as well, like go. That would make go + bun a dream for writing web apps<p>Either way still excited to check it out

As of today, what are the primary use cases for bun vs Node?<p>what type of project can I use Bun on without regretting it (due to unforeseen bugs, incompatibilities, etc)?

Just curious about the degree of compatibility with node, can I alias&#x2F;symlink node to bun and everything will continue to work but faster?

Reading the features I wonder if there are plans to also add linter and formatter to bun, it sounds compelling to use one tool for everything.

Congratulations on reaching 1.0 !<p>Performance comparisons to Go&#x2F;Java on the backend would be insightful. Would be interesting to see how close the gap is.

<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37424724">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37424724</a>

@jarred will bun work with pm2 out of the box?

So it is intended as drop-in replacement and is tested against React. Will there be support for angular apps as well?

Congrats, Jarred. Have really enjoyed following along with your progress on Twitter. Excited to give Bun a deep dive :)

Congratulations on the release! Looks really promising. I wish I was smart enough to solve some my own issues

From a quick glance, it doesn&#x27;t seem to support building vuejs or electron projects out of the box

I&#x27;m curious about the Bun Framework API, is there a release date set for that?

Oh that&#x27;s awesome! Now to find out if this works for SvelteKit projects...

Thanks sir! Been looking forward to this and spinning it up right now :)

superseded by <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37442646">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37442646</a><p>====<p>Doc&#x27;s install section for Linux missing DEB&#x2F;RPM

Just to double-check, Bun doesn’t support targeting the web, right?

Are there any edge cases when using bun with react-native?

I don&#x27;t suppose this can cope with Node-RED yet?

The development environment does not work anywhere except Mac OS. This is not FOSS, just a startup that Apple is going to buy really soon and make it there cloud computing platform.

Any plans for Electron support (or similar)?

When will Bun open up to libre and&#x2F;or federated chat options instead of requiring users sign up for and agree to Discord’s ToS?

Congratulations for the release.

Congrats on the release!

Congrats!

deno or bun for learning?

Congrats on 1.0!

[dupe]

I thought we, as an industry, had all agreed that `curl <a href="https:&#x2F;&#x2F;bun.sh&#x2F;install" rel="nofollow noreferrer">https:&#x2F;&#x2F;bun.sh&#x2F;install</a> | bash` was something we should never do and never encourage.