9 ms·

Bun 1.2 Is Released

277 points by ksec 2y ago

Rizu 2y ago
i am not a JavaScript programmer, but can someone explain exactly what bun does ? does it compile JavaScript and target a backend like LLVM equivalent for the browser ?
- ch4s3 2y ago
  Bun is a build tool and code runner primarily. It can run a tsx or js file, and it can do bundling or the compilation of TypeScript into regular JS. It also manages packages and can run tests. It aims (I think) to be a node compatible replacement for node.
- javier123454321 2y ago
  It doesn't really do anything for the browser. It provides a really fast runtime for JS to run in a server, a stdlib for http, crypto, and filesystem (among others) that JS lacks, a bundler for JS projects to go to a browser and a compiler for typescript to JS, among a few other things.
- sureIy 2y ago
  > what bun does ? It installs npm packages, it executes JS and TS code, it bundles code for front end, it runs tests. Plus it has a lot of random pieces related to this development, like integrated database access. Compare it to node, npm, webpack, and jest, all in one, and whatever the guy dreams of. It's certainly fast and offers great DX, but I wouldn't bet on it to stay around for, say, 5 years.
Karupan 2y ago
Using bun has been a great experience so far. I used to dread setting up typescript/jest/react/webpack for a new project with breaking changes all over the place. With bun, it’s been self contained and painless and it just works for my use. Can’t comment on the 3rd party libraries they are integrating like s3, sql etc but at least it looks like they are focused on most common/asked for ones. Thanks for the great work and bringing some much needed sanity in the node.js tooling space!
- Raed667 2y ago
  i have been setting up these react/ts/etc project with vite or next.js, just fine , i think you're underestimating how much progress happened in other tooling as well
  - nsonha 2y ago
    Idk about next 15 but you can literally bootsrap next 13 using a single index.tsx with typescript & next being the only 2 dependencies in package.json. No typescript is fine too. It's not new, has been the case for a few years, so honestly I don't get people complaining about next's complexity.
- herpdyderp 2y ago
  How does bun make a difference in the frontend tech stack that you mentioned?
  - nsonha 2y ago
    not up to this point, but with this release, bun is now a bundler. That means potentially no webpack, vite and their jungle of dependencies. It's possible to have bun as a sole dependency for your front and back end. Tbh I'll likely add React and co, but it's possible do do vanilla front end with plain web components.
    - cal85 2y ago
      Bun has always been a bundler (and package manager, and Node runtime). This release adds "HTML imports" as a way to use the bundler.
      - matt_kantor 2y ago
        Doesn't the name "bun" come from the fact that it's a bundler?
        2y ago
fithisux 2y ago
Congratulations!!!
- revskill 2y ago
  Why ?
  - Cthulhu_ 2y ago
    What? Why would you ask that?
voiper1 2y ago
>To work around this, we had to change the assertion logic in some tests to check the name and code, instead of the message. This is also the standard practice for checking error types in Node.js. Sounds like something they should try upstreaming? Now they'll need to track all the tests to manually modify/import...
rcarmo 2y ago
url and dgram are still not all there yet, but I’m going to see if Node-RED runs now.
- heimskr 2y ago
  dgram is at 90% compatibility, and all of the methods listed in the advanced dgram methods issue[0] have been implemented in 1.2. The url package has currently only one unimplemented test out of 13. If you've had any issues with dgram in 1.2, open an issue in our repo and I'll take a look :) [0] https://github.com/oven-sh/bun/issues/10381 https://github.com/oven-sh/bun/issues/10381
  - rcarmo 2y ago
    Well, I can now actually _run_ Node-RED 4.0 and receive multicast UDP packets, so that's great. I will be testing it with more complex stuff soon, and let you know.
Imustaskforhelp 2y ago
HTML imports In Bun 1.2, we've added support for HTML imports. This allows you to replace your entire frontend toolchain with a single import statement. To get started, pass an HTML import to the static option in Bun.serve: import homepage from "./index.html"; Bun.serve({ static: { "/": homepage, }, async fetch(req) { // ... api requests }, }); this is amazing and so cool thanks a lot !!
- sampullman 2y ago
  How does this allow me to replace e.g. Vite? Is there a way to do hot module reloading, css pre-processing, or load framework specific plugins (like the Vue SFC compiler)? Serving a static file isn't exactly new, so I feel like I must be missing something.
  - nsonha 2y ago
    > framework specific plugins (like the Vue SFC compiler)? They have a plugin api, but honestly I don't like the sound of "framework-specific plugins". It is because of this, all front-end frameworks are now a mini compiler (inside a bundler/compiler) and being too comfortable now to come up with new wacky syntaxes. I prefer frameworks to just be frameworks and being able to write normal typescript.
    - sampullman 2y ago
      If that's what you prefer, there are plenty of options. I'm happy writing Typescript with no framework (or even plain es6), as long as there isn't UI complexity. But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.
  - mythz 2y ago
    From its documentation [1] it looks a lot like a parceljs replacement [2], i.e. a zero config bundler which processes and bundles the dependencies in .html pages. So great for simple websites, not for replacing an entire Vite stack. [1] https://bun.sh/docs/bundler/fullstack https://bun.sh/docs/bundler/fullstack [2] https://parceljs.org https://parceljs.org
culi 2y ago
looking forward to updating more .gitignores with 3 of these 4 package-lock.json yarn.lock deno.lock bun.lock
- conradludgate 2y ago
  Why would you gitignore those? Adding lockfiles to git repositories is considered good practice
  - Cthulhu_ 2y ago
    And why would they use multiple competing package managers and runtimes? It isn't a good faith comment.
    - diggan 2y ago
      > And why would they use multiple competing package managers and runtimes? Some of us work across multiple projects and aren't up in our arms about what package manager the current project use. Some days you touch 3-4 projects that happen to all use different package managers.
  - phinnaeus 2y ago
    It’s not just good practice it’s the whole point
  - culi 2y ago
    I said 3 out of 4 of these. Committing multiple lockfiles is not good practice but I see people that struggle with the idea that package managers are not interchangeable all the time
    - Etheryte 2y ago
      Surely you would enforce this at pull request time, no? Ignoring the file works from a functional perspective, yes, but does nothing to solve the actual problem.
lvncelot 2y ago
Really liking the text-based lockfile. I know there's a way to get diffing locally via a `[diff "lockb"]`, `textconv = bun` git setting, but that's still 1. manual setup, and 2. not really webui friendly. Other stuff, like the C interop and psql client sounds amazing as well. I'm currently only using Bun for smaller sideprojects where I'm also trying to use some of the more out-there features, and it has been a blast so far. Though the most important question for me (as always with these announcement videos): where can I get a bun plush?
culi 2y ago
I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-repeated early on that seemed to contribute to it but they've been able to really capitalize on its hype since then. I guess choosing a small up-and-coming language like zig has the added benefit of making that entire community rally behind you
- int_19h 2y ago
  OTOH it's strange to me that they're shipping v1.2, when Zig itself is at v0.13 (and generally considered a moving target).
  - sampullman 2y ago
    A bit ambitious maybe, but I don't necessarily see why breaking changes in Zig would need to be exposed to end users.
  - culi 2y ago
    Zig is following a different versioning philosophy. It's not semver, it's https://0ver.org/ https://0ver.org/
    - AndyKelley 2y ago
      Fun website, I like it. I actually gave this some serious thought when I saw it, but, the reality is that every release so far has had major breaking changes, or was a bug fix release. So, that's indeed a fit for semver with the major version zero: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. There's nothing to gain from a different versioning scheme. People just want 1.0 and this is just another way to ask for it. It'll be done when it's done.
    - int_19h 2y ago
      I know that it's not semver, but the notice about the language itself not being stable yet is on the website.
msoad 2y ago
I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free. I'm wishing to be wrong. I'll give it a spin in a future project. From a project management perspective I'm a little confused why would you spend time on S3 support while you're still not 100% Node.js compatible. Next.js is a very big ecosystem and if you can get Next.js customers onboard you'll grow much more than supporting S3.
- re-thc 2y ago
  > From a project management perspective This assumes you know what the project(s) is/are. Also the people working on it aren't robots. Maybe certain things take time to figure out and meanwhile you can do something else? It's also not just 1 person on the task. > if you can get Next.js customers onboard you'll grow much more than supporting S3 Towards what? That doesn't make $$$. This is VC-backed. The goal isn't to provide Bun for free and gain all the users in the world.
  - msoad 2y ago
    This is a very uniformed response IMO. S3 seems very niche compared to Node.js compatibility. Not sure why you're attacking me for saying this?
    - yoavm 2y ago
      You mentioned Next.js and then Node.js. As for Next.js, it is supported by Bun (https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs). I don't think it's safe to assume that every single Node API is more commonly used than S3, which really is the standard cloud-based object storage API.
    - elchangri 2y ago
      S3 and niche don't fit in same sentence
- swiftcoder 2y ago
  > while you're still not 100% Node.js compatible 100% compatibility is a nice marketing win, but the long tail of compatibility may not make much difference to the average user. What percentage of the total Node.js API surface area do you actually use in your day-to-day? How many weird edge-cases therein are you actually depending on?
sausagefeet 2y ago
Can anyone speak to the performance numbers on the Bun page? It represents itself as significantly faster than the existing options, but why is that the case? Is it related to Bun itself? It must be the JavaScript engine they chose right? My understanding is it uses the Safari one rather than V8. Is JSC really that much faster? If so, what are the trade-offs of choosing that over V8 or any other option?
- pansa2 2y ago
  > My understanding is it uses the Safari [JavaScript engine] rather than V8 Looks like you’re right. Thanks for clearing up my misunderstanding: I’m not sure why, but I thought Bun was using a custom JS implementation.
  - DanielHB 2y ago
    From their docs it is "written in zig" which implies "all of it is Zig". They don't hide that they use JSC but they don't like to advertise either. It is a bit manipulative advertising to draw hype people in I would say. You know those tech influencers who like to peddle stuff to get views. edit: I was a bit unfair, it feels like those "hype tech influencers" are the ones who downplay JSC in favor of promoting Zig, not the project itself. The frontpage of Bun mentions JSC twice and Zig once.
  - intelVISA 2y ago
    Well in their defense it would hard to get funding for JavaScriptCoreWrapper.sh so it's a useful misunderstanding to curate.
- nicoburns 2y ago
  > Is JSC really that much faster I think it is a bit faster. But a lot of Bun's speed comes from implementing API's in Zig rather than JS (which node does a lot)
- rob74 2y ago
  It's surprisingly hard to find an answer to this (an FAQ on the Bun site would be a good idea?), but I suspect it has to do with reimplementing some stuff (bundler, package manager, test runner etc.) in a compiled language (Zig) rather than using the JS runtime for everything (this is probably also the reason why Bun integrates so many functions into one "kitchen-sink" executable), and using a JS runtime which is faster than V8 at least in some regards.
Cthulhu_ 2y ago
Why are they putting 3rd party (databases) and external (s3) librares into their core / std lib? Wouldn't that be better as an optional library? I think a runtime like this should be very, very careful with what they put into the std lib, adding these already makes it feel like a kitchen sink project.
- sod 2y ago
  Those packages exist already though. Pretty sure the bun maintainers (or Ciro Spaciari in this case) asked the question "how fast could it be if written in zig?".
  - izietto 2y ago
    Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT
    - culi 2y ago
      Tree shaking means it won't bother you if you don't use it
- supriyo-biswas 2y ago
  This is for their managed offerings. The problem of VC backed software was always that there would be these integrations that'd try to provide something unique to it, or IOW, lock-in.
  - zaphirplane 2y ago
    What’s the monetisation plan
    - timeon 2y ago
      Since at least web2.0 I've been burned many times. So my default position on VC backed projects without clear monetization plan is that it is probably bait-and-switch.
mythz 2y ago
Couldn't think of a project that was more doomed to fail than a competing alternative to Node.js, but glad that I gave it a shot when I needed to create lots of stand-alone scripts to process text files and SQLite DB updates which I was able to create with TypeScript, bun:sqlite [1] and bun $ Shell [2] working OOB without needing to manage any configuration files or local npm dependencies. I've since tried it with new JS/TypeScript Projects which also makes use of its built-in Bundler [3] and testing support [4], installing deps is also instant. Having everything work OOB, fast, are real quality of life improvements where Bun has now become my first choice for any new JS project. [1] https://bun.sh/docs/runtime/shell https://bun.sh/docs/runtime/shell [2] https://bun.sh/docs/api/sqlite https://bun.sh/docs/api/sqlite [3] https://bun.sh/docs/bundler https://bun.sh/docs/bundler [4] https://bun.sh/docs/cli/test https://bun.sh/docs/cli/test
- boodleboodle 2y ago
  Same for me. I was in the “whats the point npm will have all these next year” camp. Finally tried bun and was blown away. Subtle things in DX add up. For my project Bun is so “next generation”.
0xferruccio 2y ago
I love the direction, especially including s3 and Postgres support natively - it makes a ton of sense for this to exist as an alternative to the “build your own framework” status quo This is the standard in every web framework like Rails and Laravel, and the JS ecosystem will really benefit from this. The next steps are migration and schema management and a better out of the box testing story (w/ nice way to setup factories)
danr4 2y ago
npmrc support is huge
tmikaeld 2y ago
Batteries included makes a huge difference, this is why i love that Web APIs (Fetch API, Service Workers, Web Components, and ES6+, WebRTC etc) are now native on both V8 and Webkit runtimes. But it has to be to a certain degree, maybe S3 is too far, but SQL drivers makes sense - but again, to which degree? There are _many_ databases out there, should there be drivers for half of them? Even at that level it's a lot of added code which means slower executable. Also, I think Bun is missing out on security by adding such sensitive APIs to Bun, imagine bun taking all your source files and uploading it to your private S3 due to some script or path issue that allowed eval to run! It's game over right there.
- chrisandchris 2y ago
  There was a discussion here on HN a while sgo, why browser will not support SQLite 1st hand. Maybe that point applies to Bun too: Point is, who is responsible for maintaining the Lib and how do you change the Lib when SQLite changes. There might be a bug in SQLite. How do you fix it in Bun? Which versions receive a fix? How do you handle that a parch of your runtime (Bub) now might change behaviour of code running on it (because users worked around it)? These are solvable issues, to some degree and with some downsides. However, at some point you stop being a runtime and start being a platform, which will bring other resposibilities and issues with it.
  - otabdeveloper4 2y ago
    Well, also there isn't a reliable consensus on what "sqlite" actually is, due to extensions and build flags.
- chipgap98 2y ago
  I think the argument in favor of S3 is that there are many object storage services that implement an S3-compatible API. I know its not truly a web standard, but it is also something that a lot of people have standardized around.
- jjice 2y ago
  > Even at that level it's a lot of added code which means slower executable. Does it? Legitimate question. I would've assume that this could be almost entirely negligible depending on how the code is loaded into the runtime. If the code being loaded is only triggered when an import statement is seen, wouldn't that lead to essentially no speed overhead? Even if it was statically linked in, I don't see why having the code would slow down the executable by any amount that we'd want to consider. Maybe literally more of an executable to load into memory, but I don't see that being a tangible slow down. Would love to know if I'm missing a big piece here though.
Jarred 2y ago
I work on Bun. Happy to answer any questions.
- Y-bar 2y ago
  Are there plans for a stripped-down version without S3 and SQL and things like that for those like us who just want a fast runtime to build our frontend resources to static files?
  - Jarred 2y ago
    No plans to do that. If you're worried about binary size from features you don't use: the binary size cost of Bun.sql is less than 50 KB (you can check this yourself via the .linker-map file in the *-profile.zip builds of Bun or via https://bloaty-csv-reader.vercel.app https://bloaty-csv-reader.vercel.app which was a tool I wrote a little while ago to see how much space various features of Bun use) If you're worried about runtime overhead, practically everything in Bun is lazily loaded. So if you never access Bun.sql or Bun.S3Client, it will not load it. And, even if it does load it, because we implement it in native code and worry about this a lot, it doesn't really cost much to load.
    - ksec 2y ago
      Thank You Jarred. I seriously dont understand why there is such a huge resistance in including those. Especially when they are faster and more memory efficient.
      - diggan 2y ago
        > why there is such a huge resistance in including those I don't know about all the reasons, but personally I stay away from projects who try to bundle in as much functionality as possible into one "all-in-one" thing. I prefer approaches where you yourself chose the right library for the problem at hand, as it tends to be that different libraries have different tradeoffs, and I want to chose those tradeoffs myself. Summarized as The Unix Philosophy or "do one thing and do it well" I suppose. I'm not saying it's wrong of Bun to include those things, their value proposition is the "all-in-one" approach, which a large group of people seem to like, so seems they're doing right by their audience. But again, personally I don't like the tradeoffs involved with that approach, but I wouldn't try to convince Bun either to go against their explicit goals.
hamandcheese 2y ago
Re: bun patch, it would be great if it were possible to fetch remote patches (with a sha specified). I aim to have an "upstream first" policy when it comes to patching/forking dependencies. And fun fact about GitHub, you can append .patch to a PR url or commit URL to get a patch file. This makes patches self-documenting (they literally are a link to the upstream PR) if the tool can fetch remote patches. Nix is the only tool I'm aware of that makes this easy.
joshstrange 2y ago
I actually used Bun for the first time the other day and it was an amazing experience. All my projects have Webpack or Vite configured to let me write Typescript and once setup they work almost flawlessly but it’s a pain to set it all and not worth it for small scripts. On the other hand Bun worked right out of the box. I had spent 10-30 minutes futzing around with node-ts or whatever the tool is to run TS “directly” on the CLI and I was dealing with the all the dreaded messages “not a module”, “can’t use import/require”, “ESM/CJS” and trying all the normal fixes (changing package.json module type, changing tsconfig, changing the way import/require) all to get a ~200 line script to run. I switched to Bun as a Hail Mary and it worked wonderfully.
- graynk 2y ago
  Latest node.js now supports „just running ts“ for cases like these: node --experimental-strip-types index.ts On non-latest Node tsx package worked great for me (as oppposed to ts-node) But both of those options just throw away type information (and so does Bun)
crakhamster01 2y ago
These improvements look amazing! I'm always blown away by the performance benchmarks of Bun. Can anyone speak to how much adoption it's getting professionally? Even anecdotal points are useful. When v1.0 was released I briefly tried testing it out in my employer's monorepo. It unfortunately wasn't a drop-in replacement and we hit compatibility issues/couldn't invest time debugging. While we could have migrated smaller projects to it, we decided not to split our tooling and just stuck with pnpm. Curious if others have had a different experience!
- atonse 2y ago
  I've been using it for a greenfield NextJS 14 project for a client for about 8 months. It's been very smooth. No issues whatsoever. (edit: one issue was that I wasn't getting stack traces for error pages but they fixed that a few months ago) The only issue I hit is that Vercel only runs node, so builds that may have passed on bun, sometimes fail on Vercel. So just before I deploy, I run `npm run build` to catch any node-specific build issues and fix them before Vercel finds them. I hope Vercel will add support for bun in their edge runtime.
hu3 2y ago
A recent client uses bun in production. I'm told their dev experience with Bun is out of this world bonkers good because of speed and simplicity. Dev experience can play a big role long term. If your codebase and/or process sucks, you'll lose good people unless you pay FAANG tier compensation.
iainmerrick 2y ago
Lots of good stuff here, but I do wonder if some of the default behaviour is getting a little too magical: When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file. That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
- hombre_fatal 2y ago
  Pass a stream into the response. Response(file.stream())
  - mort96 2y ago
    I mean thanks but that doesn't change the fact that > That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
    - iainmerrick 2y ago
      To be fair, it does answer my “not at all obvious” bit -- just calling stream() is pretty clear! I should have thought a little longer.
- adam_arthur 2y ago
  I respect the area Bun is trying to carve out, but if you follow the creator on Twitter, you'll see the decision making process is very focused on short-term wins/convenience and very light on the deeper implications of the "magic" I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials. It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
- steve_adams_86 2y ago
  I don't like this design, thought I get why they did it. Personally I think this is very 'side effecty', and it reads like you'd be returning the file contents and not a URL. Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility. I'd prefer an API like this where it's explicit: Response((file(...).getPresignedURL())) Alternatively, the option to set an env variable or bun config which turns this behaviour on
atoko 2y ago
From what I can tell, this change was merged and released without a passing build. Indicating that the project’s quality assurance process is little more than lip service. I’m not sure how you would track regressions if your tests are flakey to begin with.
- martpie 2y ago
  TBH, all of what’s in this release came from previous 1.1.x patches. It seems they just drafted a new release to communicate the groups of change from the previous releases.
hollowturtle 2y ago
aws sdk apis embedded in a runtime? aside from lockin it looks a terrible thing to do, to me it seems just a driver to increase adoption, I'd actually expect free performance gains by just importing s3 from aws-sdk in bun. this way the path forward is clear: a bloated runtime full of 3rd party integrations
- moooo99 2y ago
  Apparently their S3 is running entirely based on a native implementation and offers substantial performance improvements over the AWS SDK. Bun seems to be a little inspired by the Go language design. It is batteries included and it has a substantial stdlib. Integrating something like an S3 SDK - what I would consider to be a high level feature - seems like an interesting choice, but makes a lot of sense considering Bun specifically targets cloud environments
cdmckay 2y ago
I just tried Bun to make a script to copy files from a service we were moving off of to S3 and it's pretty great. Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`. Then it's just `bun run index.ts`. And it's fast! Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.
- XCSme 2y ago
  > Node is great but there's just too many options to configure What exactly do you have to configure in Node?
  - wiseowise 2y ago
    Typescript, to start with.
    - XCSme 2y ago
      Latest Node can run TypeScript: https://2ality.com/2025/01/nodejs-strip-type.html https://2ality.com/2025/01/nodejs-strip-type.html
  - gr4vityWall 2y ago
    TypeScript, maybe handle some CJS vs ESM incompatibility while at it, and a hot reload solution are what come to mind initially.
    - XCSme 2y ago
      Latest Node can run TypeScript: https://2ality.com/2025/01/nodejs-strip-type.html https://2ality.com/2025/01/nodejs-strip-type.html
      - gr4vityWall 2y ago
        I'm aware of that initial support, I've been followed that since they added the experemental flag. As far as I know, it requires some non-standard usages in TS code, like adding the .ts extension to your imports at the top of your TypeScript files. It doesn't support .tsx files or any TypeScript feature that requires more than type striping. The initial support is appreciated, but it's not on part with Deno or Bun yet. TL;DR you will still need to work on adding proper TypeScript support anyway, compared to Bun.
monroewalker 2y ago
If building a desktop app with the intention of having JavaScript plugins, would it not be viable to include bun in the app bundle to use to run the plugins? Curious if anyone has played around with this idea
XCSme 2y ago
How's the Windows support? I check every few months, and it always fails to even run bun install on my projects on Windows.
- mort96 2y ago
  Why does it matter
  - XCSme 2y ago
    Because I develop on Windows?
    - otabdeveloper4 2y ago
      My condolences.
      - XCSme 2y ago
        With Docker, it isn't that bad. Default Windows UI/UX + PowerToys can be quite efficient. Maybe I should try dual-booting with Ubuntu.
        garbagepatch 2y ago
        With docker you don't really need to care about Bun's support on Windows. But I've been using it without issues so far. If you have issues, it might be specific to some package.
- CrimsonRain 2y ago
  Works just fine for me
  - XCSme 2y ago
    Maybe it depends on the project/dependencies. Still a lot of open/recent Windows issues: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20label%3Awindows https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
shadofx 2y ago
Baked in S3 and PGSQL feels like it's just waiting for AWS to undercut Bun's future monetization model. Deno has KV and even they are being pushed to the point of cutting regions.
yard2010 2y ago
Jarred is a gift to the FOSS world. It's quite inspiring to see such a success creating a product like this.
punkbit 2y ago
Congratulations!
deleted 2y ago
[deleted]

277 points by ksec 2y ago

Rizu 2y ago

i am not a JavaScript programmer, but can someone explain exactly what bun does ? does it compile JavaScript and target a backend like LLVM equivalent for the browser ?

ch4s3 2y ago
Bun is a build tool and code runner primarily. It can run a tsx or js file, and it can do bundling or the compilation of TypeScript into regular JS. It also manages packages and can run tests. It aims (I think) to be a node compatible replacement for node.
javier123454321 2y ago
It doesn't really do anything for the browser. It provides a really fast runtime for JS to run in a server, a stdlib for http, crypto, and filesystem (among others) that JS lacks, a bundler for JS projects to go to a browser and a compiler for typescript to JS, among a few other things.
sureIy 2y ago
> what bun does ? It installs npm packages, it executes JS and TS code, it bundles code for front end, it runs tests. Plus it has a lot of random pieces related to this development, like integrated database access. Compare it to node, npm, webpack, and jest, all in one, and whatever the guy dreams of. It's certainly fast and offers great DX, but I wouldn't bet on it to stay around for, say, 5 years.

Karupan 2y ago

Using bun has been a great experience so far. I used to dread setting up typescript/jest/react/webpack for a new project with breaking changes all over the place. With bun, it’s been self contained and painless and it just works for my use. Can’t comment on the 3rd party libraries they are integrating like s3, sql etc but at least it looks like they are focused on most common/asked for ones. Thanks for the great work and bringing some much needed sanity in the node.js tooling space!

Raed667 2y ago
i have been setting up these react/ts/etc project with vite or next.js, just fine , i think you're underestimating how much progress happened in other tooling as well
- nsonha 2y ago
  Idk about next 15 but you can literally bootsrap next 13 using a single index.tsx with typescript & next being the only 2 dependencies in package.json. No typescript is fine too. It's not new, has been the case for a few years, so honestly I don't get people complaining about next's complexity.
herpdyderp 2y ago
How does bun make a difference in the frontend tech stack that you mentioned?
- nsonha 2y ago
  not up to this point, but with this release, bun is now a bundler. That means potentially no webpack, vite and their jungle of dependencies. It's possible to have bun as a sole dependency for your front and back end. Tbh I'll likely add React and co, but it's possible do do vanilla front end with plain web components.
  - cal85 2y ago
    Bun has always been a bundler (and package manager, and Node runtime). This release adds "HTML imports" as a way to use the bundler.
    - matt_kantor 2y ago
      Doesn't the name "bun" come from the fact that it's a bundler?
      - 2y ago

fithisux 2y ago

Congratulations!!!

revskill 2y ago
Why ?
- Cthulhu_ 2y ago
  What? Why would you ask that?

voiper1 2y ago

>To work around this, we had to change the assertion logic in some tests to check the name and code, instead of the message. This is also the standard practice for checking error types in Node.js. Sounds like something they should try upstreaming? Now they'll need to track all the tests to manually modify/import...

rcarmo 2y ago

url and dgram are still not all there yet, but I’m going to see if Node-RED runs now.

heimskr 2y ago
dgram is at 90% compatibility, and all of the methods listed in the advanced dgram methods issue[0] have been implemented in 1.2. The url package has currently only one unimplemented test out of 13. If you've had any issues with dgram in 1.2, open an issue in our repo and I'll take a look :) [0] https://github.com/oven-sh/bun/issues/10381 https://github.com/oven-sh/bun/issues/10381
- rcarmo 2y ago
  Well, I can now actually _run_ Node-RED 4.0 and receive multicast UDP packets, so that's great. I will be testing it with more complex stuff soon, and let you know.

Imustaskforhelp 2y ago

HTML imports In Bun 1.2, we've added support for HTML imports. This allows you to replace your entire frontend toolchain with a single import statement. To get started, pass an HTML import to the static option in Bun.serve: import homepage from "./index.html"; Bun.serve({ static: { "/": homepage, }, async fetch(req) { // ... api requests }, }); this is amazing and so cool thanks a lot !!

sampullman 2y ago
How does this allow me to replace e.g. Vite? Is there a way to do hot module reloading, css pre-processing, or load framework specific plugins (like the Vue SFC compiler)? Serving a static file isn't exactly new, so I feel like I must be missing something.
- nsonha 2y ago
  > framework specific plugins (like the Vue SFC compiler)? They have a plugin api, but honestly I don't like the sound of "framework-specific plugins". It is because of this, all front-end frameworks are now a mini compiler (inside a bundler/compiler) and being too comfortable now to come up with new wacky syntaxes. I prefer frameworks to just be frameworks and being able to write normal typescript.
  - sampullman 2y ago
    If that's what you prefer, there are plenty of options. I'm happy writing Typescript with no framework (or even plain es6), as long as there isn't UI complexity. But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.
- mythz 2y ago
  From its documentation [1] it looks a lot like a parceljs replacement [2], i.e. a zero config bundler which processes and bundles the dependencies in .html pages. So great for simple websites, not for replacing an entire Vite stack. [1] https://bun.sh/docs/bundler/fullstack https://bun.sh/docs/bundler/fullstack [2] https://parceljs.org https://parceljs.org

culi 2y ago

looking forward to updating more .gitignores with 3 of these 4 package-lock.json yarn.lock deno.lock bun.lock

conradludgate 2y ago
Why would you gitignore those? Adding lockfiles to git repositories is considered good practice
- Cthulhu_ 2y ago
  And why would they use multiple competing package managers and runtimes? It isn't a good faith comment.
  - diggan 2y ago
    > And why would they use multiple competing package managers and runtimes? Some of us work across multiple projects and aren't up in our arms about what package manager the current project use. Some days you touch 3-4 projects that happen to all use different package managers.
- phinnaeus 2y ago
  It’s not just good practice it’s the whole point
- culi 2y ago
  I said 3 out of 4 of these. Committing multiple lockfiles is not good practice but I see people that struggle with the idea that package managers are not interchangeable all the time
  - Etheryte 2y ago
    Surely you would enforce this at pull request time, no? Ignoring the file works from a functional perspective, yes, but does nothing to solve the actual problem.

lvncelot 2y ago

Really liking the text-based lockfile. I know there's a way to get diffing locally via a `[diff "lockb"]`, `textconv = bun` git setting, but that's still 1. manual setup, and 2. not really webui friendly. Other stuff, like the C interop and psql client sounds amazing as well. I'm currently only using Bun for smaller sideprojects where I'm also trying to use some of the more out-there features, and it has been a blast so far. Though the most important question for me (as always with these announcement videos): where can I get a bun plush?

culi 2y ago

I maybe chose the wrong horse and hopped onto deno early on. Bun's success has really surprised me. It had some really misrepresented benchmarks that were oft-repeated early on that seemed to contribute to it but they've been able to really capitalize on its hype since then. I guess choosing a small up-and-coming language like zig has the added benefit of making that entire community rally behind you

int_19h 2y ago
OTOH it's strange to me that they're shipping v1.2, when Zig itself is at v0.13 (and generally considered a moving target).
- sampullman 2y ago
  A bit ambitious maybe, but I don't necessarily see why breaking changes in Zig would need to be exposed to end users.
- culi 2y ago
  Zig is following a different versioning philosophy. It's not semver, it's https://0ver.org/ https://0ver.org/
  - AndyKelley 2y ago
    Fun website, I like it. I actually gave this some serious thought when I saw it, but, the reality is that every release so far has had major breaking changes, or was a bug fix release. So, that's indeed a fit for semver with the major version zero: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. There's nothing to gain from a different versioning scheme. People just want 1.0 and this is just another way to ask for it. It'll be done when it's done.
  - int_19h 2y ago
    I know that it's not semver, but the notice about the language itself not being stable yet is on the website.

msoad 2y ago

I have not tried Bun yet but the long list of features makes me skeptical that it's all solid and bug-free. I'm wishing to be wrong. I'll give it a spin in a future project. From a project management perspective I'm a little confused why would you spend time on S3 support while you're still not 100% Node.js compatible. Next.js is a very big ecosystem and if you can get Next.js customers onboard you'll grow much more than supporting S3.

re-thc 2y ago
> From a project management perspective This assumes you know what the project(s) is/are. Also the people working on it aren't robots. Maybe certain things take time to figure out and meanwhile you can do something else? It's also not just 1 person on the task. > if you can get Next.js customers onboard you'll grow much more than supporting S3 Towards what? That doesn't make $$$. This is VC-backed. The goal isn't to provide Bun for free and gain all the users in the world.
- msoad 2y ago
  This is a very uniformed response IMO. S3 seems very niche compared to Node.js compatibility. Not sure why you're attacking me for saying this?
  - yoavm 2y ago
    You mentioned Next.js and then Node.js. As for Next.js, it is supported by Bun (https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs). I don't think it's safe to assume that every single Node API is more commonly used than S3, which really is the standard cloud-based object storage API.
  - elchangri 2y ago
    S3 and niche don't fit in same sentence
swiftcoder 2y ago
> while you're still not 100% Node.js compatible 100% compatibility is a nice marketing win, but the long tail of compatibility may not make much difference to the average user. What percentage of the total Node.js API surface area do you actually use in your day-to-day? How many weird edge-cases therein are you actually depending on?

sausagefeet 2y ago

Can anyone speak to the performance numbers on the Bun page? It represents itself as significantly faster than the existing options, but why is that the case? Is it related to Bun itself? It must be the JavaScript engine they chose right? My understanding is it uses the Safari one rather than V8. Is JSC really that much faster? If so, what are the trade-offs of choosing that over V8 or any other option?

pansa2 2y ago
> My understanding is it uses the Safari [JavaScript engine] rather than V8 Looks like you’re right. Thanks for clearing up my misunderstanding: I’m not sure why, but I thought Bun was using a custom JS implementation.
- DanielHB 2y ago
  From their docs it is "written in zig" which implies "all of it is Zig". They don't hide that they use JSC but they don't like to advertise either. It is a bit manipulative advertising to draw hype people in I would say. You know those tech influencers who like to peddle stuff to get views. edit: I was a bit unfair, it feels like those "hype tech influencers" are the ones who downplay JSC in favor of promoting Zig, not the project itself. The frontpage of Bun mentions JSC twice and Zig once.
- intelVISA 2y ago
  Well in their defense it would hard to get funding for JavaScriptCoreWrapper.sh so it's a useful misunderstanding to curate.
nicoburns 2y ago
> Is JSC really that much faster I think it is a bit faster. But a lot of Bun's speed comes from implementing API's in Zig rather than JS (which node does a lot)
rob74 2y ago
It's surprisingly hard to find an answer to this (an FAQ on the Bun site would be a good idea?), but I suspect it has to do with reimplementing some stuff (bundler, package manager, test runner etc.) in a compiled language (Zig) rather than using the JS runtime for everything (this is probably also the reason why Bun integrates so many functions into one "kitchen-sink" executable), and using a JS runtime which is faster than V8 at least in some regards.

Cthulhu_ 2y ago

Why are they putting 3rd party (databases) and external (s3) librares into their core / std lib? Wouldn't that be better as an optional library? I think a runtime like this should be very, very careful with what they put into the std lib, adding these already makes it feel like a kitchen sink project.

sod 2y ago
Those packages exist already though. Pretty sure the bun maintainers (or Ciro Spaciari in this case) asked the question "how fast could it be if written in zig?".
- izietto 2y ago
  Isn't it possible to write it in Zig as a separate extension? Every mature language I'm aware of supports this AFAICT
  - culi 2y ago
    Tree shaking means it won't bother you if you don't use it
supriyo-biswas 2y ago
This is for their managed offerings. The problem of VC backed software was always that there would be these integrations that'd try to provide something unique to it, or IOW, lock-in.
- zaphirplane 2y ago
  What’s the monetisation plan
  - timeon 2y ago
    Since at least web2.0 I've been burned many times. So my default position on VC backed projects without clear monetization plan is that it is probably bait-and-switch.

mythz 2y ago

Couldn't think of a project that was more doomed to fail than a competing alternative to Node.js, but glad that I gave it a shot when I needed to create lots of stand-alone scripts to process text files and SQLite DB updates which I was able to create with TypeScript, bun:sqlite [1] and bun $ Shell [2] working OOB without needing to manage any configuration files or local npm dependencies. I've since tried it with new JS/TypeScript Projects which also makes use of its built-in Bundler [3] and testing support [4], installing deps is also instant. Having everything work OOB, fast, are real quality of life improvements where Bun has now become my first choice for any new JS project. [1] https://bun.sh/docs/runtime/shell https://bun.sh/docs/runtime/shell [2] https://bun.sh/docs/api/sqlite https://bun.sh/docs/api/sqlite [3] https://bun.sh/docs/bundler https://bun.sh/docs/bundler [4] https://bun.sh/docs/cli/test https://bun.sh/docs/cli/test

boodleboodle 2y ago
Same for me. I was in the “whats the point npm will have all these next year” camp. Finally tried bun and was blown away. Subtle things in DX add up. For my project Bun is so “next generation”.

0xferruccio 2y ago

I love the direction, especially including s3 and Postgres support natively - it makes a ton of sense for this to exist as an alternative to the “build your own framework” status quo This is the standard in every web framework like Rails and Laravel, and the JS ecosystem will really benefit from this. The next steps are migration and schema management and a better out of the box testing story (w/ nice way to setup factories)

danr4 2y ago

npmrc support is huge

tmikaeld 2y ago

Batteries included makes a huge difference, this is why i love that Web APIs (Fetch API, Service Workers, Web Components, and ES6+, WebRTC etc) are now native on both V8 and Webkit runtimes. But it has to be to a certain degree, maybe S3 is too far, but SQL drivers makes sense - but again, to which degree? There are _many_ databases out there, should there be drivers for half of them? Even at that level it's a lot of added code which means slower executable. Also, I think Bun is missing out on security by adding such sensitive APIs to Bun, imagine bun taking all your source files and uploading it to your private S3 due to some script or path issue that allowed eval to run! It's game over right there.

chrisandchris 2y ago
There was a discussion here on HN a while sgo, why browser will not support SQLite 1st hand. Maybe that point applies to Bun too: Point is, who is responsible for maintaining the Lib and how do you change the Lib when SQLite changes. There might be a bug in SQLite. How do you fix it in Bun? Which versions receive a fix? How do you handle that a parch of your runtime (Bub) now might change behaviour of code running on it (because users worked around it)? These are solvable issues, to some degree and with some downsides. However, at some point you stop being a runtime and start being a platform, which will bring other resposibilities and issues with it.
- otabdeveloper4 2y ago
  Well, also there isn't a reliable consensus on what "sqlite" actually is, due to extensions and build flags.
chipgap98 2y ago
I think the argument in favor of S3 is that there are many object storage services that implement an S3-compatible API. I know its not truly a web standard, but it is also something that a lot of people have standardized around.
jjice 2y ago
> Even at that level it's a lot of added code which means slower executable. Does it? Legitimate question. I would've assume that this could be almost entirely negligible depending on how the code is loaded into the runtime. If the code being loaded is only triggered when an import statement is seen, wouldn't that lead to essentially no speed overhead? Even if it was statically linked in, I don't see why having the code would slow down the executable by any amount that we'd want to consider. Maybe literally more of an executable to load into memory, but I don't see that being a tangible slow down. Would love to know if I'm missing a big piece here though.

Jarred 2y ago

I work on Bun. Happy to answer any questions.

Y-bar 2y ago
Are there plans for a stripped-down version without S3 and SQL and things like that for those like us who just want a fast runtime to build our frontend resources to static files?
- Jarred 2y ago
  No plans to do that. If you're worried about binary size from features you don't use: the binary size cost of Bun.sql is less than 50 KB (you can check this yourself via the .linker-map file in the *-profile.zip builds of Bun or via https://bloaty-csv-reader.vercel.app https://bloaty-csv-reader.vercel.app which was a tool I wrote a little while ago to see how much space various features of Bun use) If you're worried about runtime overhead, practically everything in Bun is lazily loaded. So if you never access Bun.sql or Bun.S3Client, it will not load it. And, even if it does load it, because we implement it in native code and worry about this a lot, it doesn't really cost much to load.
  - ksec 2y ago
    Thank You Jarred. I seriously dont understand why there is such a huge resistance in including those. Especially when they are faster and more memory efficient.
    - diggan 2y ago
      > why there is such a huge resistance in including those I don't know about all the reasons, but personally I stay away from projects who try to bundle in as much functionality as possible into one "all-in-one" thing. I prefer approaches where you yourself chose the right library for the problem at hand, as it tends to be that different libraries have different tradeoffs, and I want to chose those tradeoffs myself. Summarized as The Unix Philosophy or "do one thing and do it well" I suppose. I'm not saying it's wrong of Bun to include those things, their value proposition is the "all-in-one" approach, which a large group of people seem to like, so seems they're doing right by their audience. But again, personally I don't like the tradeoffs involved with that approach, but I wouldn't try to convince Bun either to go against their explicit goals.

hamandcheese 2y ago

Re: bun patch, it would be great if it were possible to fetch remote patches (with a sha specified). I aim to have an "upstream first" policy when it comes to patching/forking dependencies. And fun fact about GitHub, you can append .patch to a PR url or commit URL to get a patch file. This makes patches self-documenting (they literally are a link to the upstream PR) if the tool can fetch remote patches. Nix is the only tool I'm aware of that makes this easy.

joshstrange 2y ago

I actually used Bun for the first time the other day and it was an amazing experience. All my projects have Webpack or Vite configured to let me write Typescript and once setup they work almost flawlessly but it’s a pain to set it all and not worth it for small scripts. On the other hand Bun worked right out of the box. I had spent 10-30 minutes futzing around with node-ts or whatever the tool is to run TS “directly” on the CLI and I was dealing with the all the dreaded messages “not a module”, “can’t use import/require”, “ESM/CJS” and trying all the normal fixes (changing package.json module type, changing tsconfig, changing the way import/require) all to get a ~200 line script to run. I switched to Bun as a Hail Mary and it worked wonderfully.

graynk 2y ago
Latest node.js now supports „just running ts“ for cases like these: node --experimental-strip-types index.ts On non-latest Node tsx package worked great for me (as oppposed to ts-node) But both of those options just throw away type information (and so does Bun)

crakhamster01 2y ago

These improvements look amazing! I'm always blown away by the performance benchmarks of Bun. Can anyone speak to how much adoption it's getting professionally? Even anecdotal points are useful. When v1.0 was released I briefly tried testing it out in my employer's monorepo. It unfortunately wasn't a drop-in replacement and we hit compatibility issues/couldn't invest time debugging. While we could have migrated smaller projects to it, we decided not to split our tooling and just stuck with pnpm. Curious if others have had a different experience!

atonse 2y ago
I've been using it for a greenfield NextJS 14 project for a client for about 8 months. It's been very smooth. No issues whatsoever. (edit: one issue was that I wasn't getting stack traces for error pages but they fixed that a few months ago) The only issue I hit is that Vercel only runs node, so builds that may have passed on bun, sometimes fail on Vercel. So just before I deploy, I run `npm run build` to catch any node-specific build issues and fix them before Vercel finds them. I hope Vercel will add support for bun in their edge runtime.

hu3 2y ago

A recent client uses bun in production. I'm told their dev experience with Bun is out of this world bonkers good because of speed and simplicity. Dev experience can play a big role long term. If your codebase and/or process sucks, you'll lose good people unless you pay FAANG tier compensation.

iainmerrick 2y ago

Lots of good stuff here, but I do wonder if some of the default behaviour is getting a little too magical: When you use new Response(s3.file(...)), instead of downloading the S3 file to your server and sending it back to the user, Bun redirects the user to the presigned URL for the S3 file. That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.

hombre_fatal 2y ago
Pass a stream into the response. Response(file.stream())
- mort96 2y ago
  I mean thanks but that doesn't change the fact that > That's a rather surprising choice for the default, and it's not at all obvious how you'd disable it if you don't want to expose your S3 bucket directly.
  - iainmerrick 2y ago
    To be fair, it does answer my “not at all obvious” bit -- just calling stream() is pretty clear! I should have thought a little longer.
adam_arthur 2y ago
I respect the area Bun is trying to carve out, but if you follow the creator on Twitter, you'll see the decision making process is very focused on short-term wins/convenience and very light on the deeper implications of the "magic" I was initially excited about the project, but have no faith in the long term direction given the spurious (and often poor IMO) design decisions. At least as it's publicized on socials. It would have been fine if they kept it v0.x, but releasing 1.0 should have significantly raised the bar for increasing API surface area
steve_adams_86 2y ago
I don't like this design, thought I get why they did it. Personally I think this is very 'side effecty', and it reads like you'd be returning the file contents and not a URL. Even so, what would bother you about exposing the bucket? It's also a presigned URL so it doesn't have broad access utility. I'd prefer an API like this where it's explicit: Response((file(...).getPresignedURL())) Alternatively, the option to set an env variable or bun config which turns this behaviour on

atoko 2y ago

From what I can tell, this change was merged and released without a passing build. Indicating that the project’s quality assurance process is little more than lip service. I’m not sure how you would track regressions if your tests are flakey to begin with.

martpie 2y ago
TBH, all of what’s in this release came from previous 1.1.x patches. It seems they just drafted a new release to communicate the groups of change from the previous releases.

hollowturtle 2y ago

aws sdk apis embedded in a runtime? aside from lockin it looks a terrible thing to do, to me it seems just a driver to increase adoption, I'd actually expect free performance gains by just importing s3 from aws-sdk in bun. this way the path forward is clear: a bloated runtime full of 3rd party integrations

moooo99 2y ago
Apparently their S3 is running entirely based on a native implementation and offers substantial performance improvements over the AWS SDK. Bun seems to be a little inspired by the Go language design. It is batteries included and it has a substantial stdlib. Integrating something like an S3 SDK - what I would consider to be a high level feature - seems like an interesting choice, but makes a lot of sense considering Bun specifically targets cloud environments

cdmckay 2y ago

I just tried Bun to make a script to copy files from a service we were moving off of to S3 and it's pretty great. Instead of having to tinker with my package.json, tsconfig.json, etc. to get everything just right, it works right of the box the way you expected with `bun init`. Then it's just `bun run index.ts`. And it's fast! Node is great but there's just too many options to configure. I appreciate that Bun went ahead and made a bunch of assumptions and pulled commonly used stuff directly into it.

XCSme 2y ago
> Node is great but there's just too many options to configure What exactly do you have to configure in Node?
- wiseowise 2y ago
  Typescript, to start with.
  - XCSme 2y ago
    Latest Node can run TypeScript: https://2ality.com/2025/01/nodejs-strip-type.html https://2ality.com/2025/01/nodejs-strip-type.html
- gr4vityWall 2y ago
  TypeScript, maybe handle some CJS vs ESM incompatibility while at it, and a hot reload solution are what come to mind initially.
  - XCSme 2y ago
    Latest Node can run TypeScript: https://2ality.com/2025/01/nodejs-strip-type.html https://2ality.com/2025/01/nodejs-strip-type.html
    - gr4vityWall 2y ago
      I'm aware of that initial support, I've been followed that since they added the experemental flag. As far as I know, it requires some non-standard usages in TS code, like adding the .ts extension to your imports at the top of your TypeScript files. It doesn't support .tsx files or any TypeScript feature that requires more than type striping. The initial support is appreciated, but it's not on part with Deno or Bun yet. TL;DR you will still need to work on adding proper TypeScript support anyway, compared to Bun.

monroewalker 2y ago

If building a desktop app with the intention of having JavaScript plugins, would it not be viable to include bun in the app bundle to use to run the plugins? Curious if anyone has played around with this idea

XCSme 2y ago

How's the Windows support? I check every few months, and it always fails to even run bun install on my projects on Windows.

mort96 2y ago
Why does it matter
- XCSme 2y ago
  Because I develop on Windows?
  - otabdeveloper4 2y ago
    My condolences.
    - XCSme 2y ago
      With Docker, it isn't that bad. Default Windows UI/UX + PowerToys can be quite efficient. Maybe I should try dual-booting with Ubuntu.
      - garbagepatch 2y ago
        With docker you don't really need to care about Bun's support on Windows. But I've been using it without issues so far. If you have issues, it might be specific to some package.
CrimsonRain 2y ago
Works just fine for me
- XCSme 2y ago
  Maybe it depends on the project/dependencies. Still a lot of open/recent Windows issues: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20label%3Awindows https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...

shadofx 2y ago

Baked in S3 and PGSQL feels like it's just waiting for AWS to undercut Bun's future monetization model. Deno has KV and even they are being pushed to the point of cutting regions.

yard2010 2y ago

Jarred is a gift to the FOSS world. It's quite inspiring to see such a success creating a product like this.

punkbit 2y ago

Congratulations!

deleted 2y ago

[deleted]