25 ms·

Bun v1.0.0

1089 points by tuananh 3y ago

trinovantes 3y ago
From a quick glance, it doesn't seem to support building vuejs or electron projects out of the box
KaoruAoiShiho 3y ago
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.
- vichle 3y ago
  This is what I thought. After some fiddling it became clear that compatibility will be an issue for more applications than they claim. It's probably fine for new projects though.
- jrvarela56 3y ago
  I’ve been thinking about this anf trying it out. The only obviously bad thing is that the ‘drop-in replacement’ is bs: they’re aiming for it but there are a bunch of node std lib modules missing. Despite that it seems to work just fine for my Expo app and RNW project.
  - jrvarela56 3y ago
    Check compat status here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
- rwalle 3y ago
  limited Windows support -- I am surprised that this is hardly mentioned. People here may not admit this, but Windows-based developers are a huge group, and probably more than Linux or Mac (e.g. look at stackoverflow survey). If you tell people "You can't really use Bun as intended unless you use Mac or Linux or spend half an hour setting up WSL first", people are going to be turned away, especially for new developers. It may not matter to you personally, but if it is used in a project with developers working on different platforms, it is going to present some hurdles.
xavdid 3y ago
Congrats! Your blog post paints a very compelling value proposition for simpler, all-in-one (yet extensible) software. I find I'm more compelled these days by "batteries included" software than "bring your own everything", so I'm excited to try this out. 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](https://biomejs.dev/blog/annoucing-biome https://biomejs.dev/blog/annoucing-biome). I hope you find more success than they did! It's certainly a hard problem to solve.
- kaizoku111 3y ago
  I agree with "batteries included", if node.js and co etc. had a good harmonious ecosystem to begin with we wouldn't need such an approach. Looking at the way Apple does things, they own and control the hardware and OS which allows them to deeply optimise their systems and also provide an ease of mind knowing all their devices will work seamlessly across the board. Having an all-in-one toolkit reduces overhead of running around finding the perfect solutions, when it is already right in front of them.
  - awestroke 3y ago
    On the other hand, the DX of Apple's development toolchain is among the worst in the world
rcarmo 3y ago
I don't suppose this can cope with Node-RED yet?
- Jarred 3y ago
  This might work now. It didn't in v0.5.x and earlier. We added proper CommonJS support and that means sloppy-mode features that Node-RED relies on should work just fine.
  - rcarmo 3y ago
    It does! At least the base setup works with "bun run node-red". I will have to test third-party modules, of course, but the 3.1.0 release seems to work OK in 15 minutes of testing. I'll have to see how it goes on slower machines, ARM, etc. Thanks!
    - rcarmo 3y ago
      Another datapoint - wisp, my favorite LISP-to-JS transpiler, also apparently works fine: https://github.com/wisp-lang/wisp/issues/174 https://github.com/wisp-lang/wisp/issues/174 This makes for a pretty awesome combination considering bun's system calls and sqlite support.
gkfasdfasdf 3y ago
Just curious about the degree of compatibility with node, can I alias/symlink node to bun and everything will continue to work but faster?
gwalkerux 3y ago
Wondering what (if any) telemetry data Bun collects? Ever since the telemetry in front-end tools website (https://telemetry.timseverien.com/ https://telemetry.timseverien.com/) was shared here a few months ago I've been wondering the same for other tools.
rmilejczz 3y ago
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 Either way still excited to check it out
losvedir 3y ago
Wow, that is a compelling landing page. It'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?
tlhunter 3y ago
What happens with circular require/import calls? Anything weird when requiring/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'm curious if anything funny happens.
ripperoni 3y ago
So it is intended as drop-in replacement and is tested against React. Will there be support for angular apps as well?
jlu 3y ago
@jarred will bun work with pm2 out of the box?
bulk88 3y ago
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.
ComputerGuru 3y ago
Just to double-check, Bun doesn’t support targeting the web, right?
tiffanyh 3y ago
Dumb question: since Bun is MIT licensed - why doesn’t Node just merge Buns code into Node? https://bun.sh/docs/project/licensing https://bun.sh/docs/project/licensing
- swyx 3y ago
  because the projects have different goals and are coded in different languages.
  - leeoniya 3y ago
    ...and based on different JavaScript engines.
- leeoniya 3y ago
  "just" :_D
j-rom 3y ago
Is there an example one step above "Hello world" that new users can take a look at? There are a bunch of guides for different API's / constructs but I'm wondering if there's a canonical example to get started. Guides: https://bun.sh/guides https://bun.sh/guides
petabytes 3y ago
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't believe people put up with this. Glad to see there is a solution.
khiner 3y ago
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!
auraham 3y ago
deno or bun for learning?
CoolCold 3y ago
superseded by https://news.ycombinator.com/item?id=37442646 https://news.ycombinator.com/item?id=37442646 ==== Doc's install section for Linux missing DEB/RPM
seymon 3y ago
Has anyone managed to run a non trivial Nest.js application with bun already? With non trivial I mean an application using a lot of Nest.js features and libraries like TypeORM, Swagger-UI.
- evnix 3y ago
  Not nestJS, but built around express typeorm and the rest and the code base is 5 years old so you can imagine. Bun has seriously been a god send. I am so happy that we can finally do top level awaits and it allowed us to delete a lot of hacky code that we had in place just to make node and all the build dependencies happy.
jbverschoor 3y ago
Hi Jarred, The docs say that Bun uses clonesfiles / hardlinks (yay). But it also states that clonefiles don't benefit space saving: > This benefit does not extend to macOS, which uses clonefile for performance reasons As far as I know, clonefiles are COW, which should not take any space except the extra inode.
nkmnz 3y ago
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: ERROR Cannot build module „nuxt“ {}
- danielroe 3y ago
  I'm not aware of any issues as long as you are on the latest Nuxt and nuxi versions, so it might be easier to help if you open an issue with a reproduction on https://github.com/nuxt/nuxt/issues https://github.com/nuxt/nuxt/issues.
  - nkmnz 3y ago
    Will do once I’ve investigated more. Tried bun yesterday evening and just saw this thread this morning while heading to the lake :) Thank you for your awesome work on nuxt 3, by the way!
    - danielroe 3y ago
      You're very welcome It's definitely a team effort. Feel free to DM me if I can be helpful.
christophilus 3y ago
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.
fabioono25 3y ago
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.
deleted 3y ago
[deleted]
hollowturtle 3y ago
It really seems impressive to me. I think I'll try it as a tool first, later as a runtime. Just wondering why has been built using Apple'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?
- jeroenhd 3y ago
  Both engines are really fast, both of them have places where they beat the other. For a while, JavaScriptCore was the fastest Javascript runtime, then V8 took over again, and now Spidermonkey is the fastest if you cherry pick the right tests. The places where WebKit lags behind aren't the places Bun really cares about. I'm honestly quite glad they add some diversity to Javascript land. I recall reading a comment that JavaScriptCore was chosen because of performance. I believe JSC is quicker to start up, and I wouldn't be surprised if it wasn't faster at executing the type of code Bun executes as well.
zx2c4 3y ago
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'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's true.) Any seasoned users with time spent on both?
- manojlds 3y ago
  Deno wanted a post-Node way but they have gone back on their original ambitions (which never resonated with me, to be frank) and now have a pretty limited compatbility whereas Bun has full compatibility with Node.
  - ignoramous 3y ago
    Per their own docs, Bun is not fully Node compatible [0]. In my experience, even for APIs its docs claim full-compatibility has some sharp edges. That said, Bun's node-compat story is better than Deno's. While Node's performance story keeps improving release over release [1]. [0] https://archive.is/NCzRQ https://archive.is/NCzRQ [1] https://twitter.com/lemire/status/1699459534190698999 https://twitter.com/lemire/status/1699459534190698999
- re-thc 3y ago
  Deno wanted to be different but never did enough to force its way. Maybe if they had 10x the funding to rewrite the ecosystem. Now it's in limbo. Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
  - ShadowBanThis01 3y ago
    There's plenty to consider if you don't care about Node compatibility. From what I've read (including in this thread and on the Bun PR page), Node seems pretty messy, with modules coming from different sources in different ways. In Deno you just import with a URL. I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!
jkubicek 3y ago
I thought we, as an industry, had all agreed that `curl https://bun.sh/install https://bun.sh/install | bash` was something we should never do and never encourage.
- fkyoureadthedoc 3y ago
  If you don't trust bun.sh don't do it. They would be torpedoing their project if they put something nefarious in there though, and it would probably more effective to put the nefarious stuff in bun directly. Yes a 3rd party could have gained access to their site and modified that script, but that's covered under "trust bun.sh".
  - williamstein 3y ago
    It's also a short, clean and easy to read shell script.
- mekster 3y ago
  If you can't trust that, then I suppose you're checking every node_modules dir for any malicious codes but I guess you're just being allergic to pipe bash.
- nonethewiser 3y ago
  Can you walk us through an alternative and why it would be safer?
- pxeger1 3y ago
  I don't like `curl|bash` not because it's insecure but because I don't know what it's doing to my system, and I don't believe that it understands my system properly. Ideally I'd download a single binary and put it in /usr/local/bin myself.
- Rapzid 3y ago
  You have it backwards. Even Microsoft posts install scripts such as this for DotNet.
Jarred 3y ago
I work on Bun. Happy to answer any questions Could the mods change the link to the blog post? It explains better than the github release page Blog post: https://bun.sh/blog/bun-v1.0 https://bun.sh/blog/bun-v1.0
- dang 3y ago
  Ok, changed from https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0 https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0.
  - Jarred 3y ago
    Thank you
OriPekelman 3y ago
Oh its a Friday. Deploying on Fridays is what we do. Here you go ... Bun 1.0 officially deployed on Platform.sh https://platform.sh/blog/bun-support-is-here/ https://platform.sh/blog/bun-support-is-here/ enjoy.
- OriPekelman 3y ago
  Also. As I am excited. Here you go for a one-click deploy .. https://github.com/OriPekelman/express-bun/ https://github.com/OriPekelman/express-bun/ Very unofficial. Very.
- Nezteb 3y ago
  Slightly hijacking this thread to ask: I've not heard of Platform.sh before. Do y'all have a free/hobby plan for someone wanting to become familiar with the it? If not, no worries.
  - OriPekelman 3y ago
    We are not big on free. We like money :) And people like that we will probably be around in a decade (and won't stop free as soon as we've locked enough people -in). We do have a no-strings-attached free trial ...
fithisux 3y ago
Congratulations for the release.
zengid 3y ago
Congrats!
jkrems 3y ago
Congrats on 1.0!
wdb 3y ago
Congratulations on the release! Looks really promising. I wish I was smart enough to solve some my own issues
arpowers 3y ago
As of today, what are the primary use cases for bun vs Node? what type of project can I use Bun on without regretting it (due to unforeseen bugs, incompatibilities, etc)?
zengid 3y ago
from that blog post: "Unlike Node.js and other runtimes that are built using Google's V8 engine, Bun is built using Apple's WebKit engine. WebKit is the engine that powers Safari and is used by billions of devices every day. It's fast, efficient, and has been battle-tested for decades." That's really interesting, does WebKit do less JITing or something to be faster for startup?
- billywhizz 3y ago
  bun startup is fast compared to other JS runtimes but imo this is little or nothing to do with JSC versus v8 as the javascript engine. i did some experiments a while back and wrote them up here if you want to take a look. https://just.billywhizz.io/blog/on-javascript-performance-03/ https://just.billywhizz.io/blog/on-javascript-performance-03...
  - leeoniya 3y ago
    awesome writeup, as always.
    - billywhizz 3y ago
      thanks! love your uPlot library btw!
      - leeoniya 3y ago
        <3
ryanrussell 3y ago
Amazing work Jarred. I am still absolutely amazed at how much more performant websockets throughput in bun vs node. Congrats on 1.0!
ggregoire 3y ago
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? I'm confused cause this guide on the official site showcases how to use Bun + Vite.js to build a TypeScript React app. [1] There is also this issue on their Github. [2] Can Vite.js be used to handle more complicated scenarios / advanced use cases that Bun doesn't handle? My use of Vite.js is pretty basic (start & build with the default TS+React config) so maybe I'm missing something here. -- [1] https://bun.sh/guides/ecosystem/vite https://bun.sh/guides/ecosystem/vite [2] https://github.com/oven-sh/bun/issues/250 https://github.com/oven-sh/bun/issues/250
- fyzix 3y ago
  My guess is that you can leverage the vite's plugin ecosystem...postcss,tailwind,terser etc. And most of the new meta frameworks(nuxt,sveltekit,astro,solidstart,qwik) runs on vite so that might pave a path for adoption.
- nsonha 3y ago
  that's like asking why need vite when you have tsc. I assume bun does not "run Typescript React app", it only does the jsx,tsx transpiling out of the box.
- brundolf 3y ago
  It's a big ask to get people to adopt an ecosystem wholesale. Compatibility with the existing ecosystem is a key goal of Bun, so that people can start using it immediately on their existing codebases and then adopt it gradually for more and more stuff
- jadbox 3y ago
  I'm new around here, I've only seen people use Vite with bun for HMR, but imho, it's not great to combine them just yet as there's config complexity.
  - ggregoire 3y ago
    I thought Bun had HRM out-of-the-box but it's not working? Not sure. https://github.com/oven-sh/bun/issues/833 https://github.com/oven-sh/bun/issues/833
creativeembassy 3y ago
Personal experience: Bun has been a flawless drop-in replacement for both NodeJS and npm/yarn since I started using it around v0.4. Not only have I had zero issues running it, but it's been WAY faster. No benchmarks, but very noticeable, from "let's start a new build and go grab a coffee while waiting for it" on NodeJS, to "hit run aaaaand it's done." I haven'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.
- revskill 3y ago
  So it means you'll drink less coffee, and it's not good for productivity reason.
- moralestapia 3y ago
  I've worked on several large node.js codebases and builds never took more than a few seconds, def. not "go grab coffee" time, so maybe something else was going on.
  - isuckatcoding 3y ago
    It’s not uncommon to have a nodejs library take like 10-15 mins to go through building and testing in GitHub actions CI
    - moralestapia 3y ago
      >and testing And Bun is going to improve that?
    - nonethewiser 3y ago
      But that’s probably more about tests and github resources than raw build times.
      - nbittich 3y ago
        Average angular apps take at least 4 min in release mode on machine.
oefrha 3y ago
> It reads your package.json and writes to node_modules, just like other package managers, so you can replace: > ... > pnpm pnpm's flagship feature is global deduplication of packages, so sadly bun's package manager doesn'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.) That said, I'm very impressed with the speed of `bun add` with already cached packages. Literally instant.
- Cu3PO42 3y ago
  Bun already supports that [0]. It is the default behavior on Linux, but can also be enabled on macOS. [0] https://bun.sh/docs/install/cache#saving-disk-space https://bun.sh/docs/install/cache#saving-disk-space
  - oefrha 3y ago
    Nice! I was looking at du(1) output on macOS which appears to indicate all files are duplicated. It probably just can’t tell the files are clonefile’d.
    - Jarred 3y ago
      There is a very obscure undocumented api in macOS for detecting if two files are equal block-by-block but yeah I don’t think most tools can tell when files are clonefile’d
      - Cu3PO42 3y ago
        Just a note on your documentation: it says "this benefit does not extend to macOS" about saving disk space. I find that to be slightly misleading. Since arguably the most common FS for macOS is now APFS, it does save significant disk space unless one were to modify the node_modules files.
  - thunderbong 3y ago
    Any chance of this coming to Windows? Most of our developers are on Windows systems.
jzelinskie 3y ago
Congrats on the launch! The NextJS guide[0] claims that bun doesn't support all the node APIs to run the dev server, is that still the case with 1.0? [0]: https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs
- Jarred 3y ago
  We landed Next.js pages directory support two days ago and forgot to update that guide
  - jzelinskie 3y ago
    Awesome! Reading through the install script now -- would you considering using installing to $XDG_DATA_HOME and falling back to `~/.bun`?
  - notsrg 3y ago
    Any docs for migrating an existing Nextjs project? No rush but would be great to have :)
eimthefea 3y ago
Congratulation to the project, it seems incredible. I don't know that much so I have some questions, sorry if they're already answered. (share link if any if its possible) 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 ? 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 ? I've seen Deno putting a lot of effort into the platform around their runtime, making deploying Deno app easy, is that your goal too ? I've seen that you use Zig instead of C++, what do you like the most about Zig while working on Bun ? In anyway, I hope the project will make the JSRuntime world better, its promising.
theredsix 3y ago
Congrats on the release!
tlarkworthy 3y ago
You write typescript and unit test without tsc, jest, webpack/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. I love it, it super simplifies project and for minimalists it's perfect.
- iainmerrick 3y ago
  How do you do type-checking? Do you just run TSC with “noEmit: true”, like you’d do with any other bundler? TSC is simultaneously the most valuable and the most flaky part of your typical JS project setup. That’s the main part I’d be interested in replacing with a different tool.
  - tlarkworthy 3y ago
    It reads the tsconfig file if present. You just write TS files and bun build outputs JS. Vscode highlights typecheck errors based on TS errors. Bun build fails if you can't typecheck. No tsc installation necessary, but also consistency with tsc if you use a tsconfig. For simple stuff tsconfig is not needed
    - iainmerrick 3y ago
      Bun build fails if you can't typecheck It has to run TSC (or expect somebody else to run it) in order to typecheck, though, right?
      - simon04 3y ago
        That's my understanding, too. > Bun can run .js, .ts, .cjs, .mjs, .jsx, and .tsx files, which can replace: > > tsc — (but you can keep it for typechecking!)
      - tlarkworthy 3y ago
        I am mistaken. Yeah bun does not typescheck like esbuild doesn't. It reads the tsconfig for build options. Either you add tsc or let your editor do it.
majestic5762 3y ago
Are there any edge cases when using bun with react-native?
deleted 3y ago
[deleted]
skybrian 3y ago
Any plans for Electron support (or similar)?
brundolf 3y ago
Bun ships features and improvements fast and often, which is great But from anecdotes, I have the impression people still run into bugs and missing functionality semi-commonly. I'm sure it works great for small/personal projects, but I've been hesitant to recommend it for production use at my workplace because of this impression So my question is: how feature-complete/stable/secure is it right now, what does the v1.0 label say about that, and what are the long-term plans/prioritization/guarantees around this area?
toastal 3y ago
When will Bun open up to libre and/or federated chat options instead of requiring users sign up for and agree to Discord’s ToS?
dudus 3y ago
There was some criticism yesterday about bun being stable using a language (zig) that isn't considered stable. Do you care to comment about it? Ref: https://news.ycombinator.com/item?id=37422894 https://news.ycombinator.com/item?id=37422894
- solatic 3y ago
  Zig isn't an interpreted language; once the code is compiled, the produced artifact doesn't change. Stability doesn't really play a factor there. Sure, the instability of Zig may increase the maintenance costs for Jarred, to use updated versions of Zig. But this has no effect on the features that Bun provides. The risk that a change to Zig would be so consequential that they would actually prevent Jarred from continuing to work on Bun, or would otherwise force Jarred to fork Zig, that risk is so low as to be inconsequential. (disclaimer: not associated with either bun or zig, the above are pure opinions)
  - zengid 3y ago
    Not OP but I think they meant Zig isn't 1.0 and therefore could be considered "not ready for prod". I'm not claiming anything about Zig; I can only hope that the Bun folks have done their due diligence and ran it through fuzzing/ASAN/etc before making the 1.0 stamp of approval.
    - albedoa 3y ago
      That's the point being addressed by the comment you are responding to.
  - swyx 3y ago
    also stability is more of a statement about api design than internals
  - kaba0 3y ago
    That in itself is no good argument -- it surely has some bug, and if, say, zig changes in the meanwhile and it can no longer compile the previous code then it can be problematic from a maintenance POV. With that said, it is probably fine to use for most ordinary apps, but I wouldn't yet build a bank infrastructure on top for example.
padjo 3y ago
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. Realistically how much of a problem is this likely to be?
- postalrat 3y ago
  Calm down Gramps. People have moved on. Rust is yesterday's technology.
- shawabawa3 3y ago
  I guarantee zig is 100x more production ready than 99% of the 4 million nested dependencies included in the average js project
  - petabytes 3y ago
    I tried to compile a hello world template for Zig a few months ago. Pulled it from GitHub, zig build and it gave an error. The problem? They recently redesigned a major part of the build system and deprecated old functions. No deprecated message, and no backwards compatibility. Just a plain old undefined function error. That's what I don't like about these modern languages. You have to be in the community and keep up with the latest releases in order to use the language. I just want something that's stable. I don't want to keep relearning everything.
  - nonethewiser 3y ago
    Node or Deno dependencies would be a fairer comparison.
  - vntx 3y ago
    Wow, that many guarantees should persuade me to base my tech stack on Bun and Zig. Seriously, I think this question is worth asking. Why was Zig chosen as the language when it’s not even stable, and what implications does this have for the long term viability of the project (besides the fact that its _fast_)? Zig’s head guy isn’t even sure when Zig will hit v.1.0, and Bun’s head guy hasn’t really responded either AFAIK.
simonw 3y ago
OK, I'm impressed. It took 0.01s to run 'bun install react': % cd /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
- Timon3 3y ago
  That's probably because it was cached! The first install is "a lot" slower than subsequent ones: $ cd /tmp/ $ mkdir app1 && cd app1 $ time bun install react bun add v1.0.0 (822a00c4) installed react@18.2.0 3 packages installed [431.00ms] real 0m0.436s user 0m0.031s sys 0m0.052s $ cd .. $ mkdir app2 && cd app2 $ time bun install react bun add v1.0.0 (822a00c4) installed react@18.2.0 3 packages installed [6.00ms] real 0m0.010s user 0m0.006s sys 0m0.005s Though even 431ms is obviously amazing!
  - billywhizz 3y ago
    on my currently crappy internet on ubuntu 22 i get ~2.65 seconds for bun and ~5.6 seconds for npm for a clean install without caching. so approx 2x as fast as npm.
toastercat 3y ago
Congrats! 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/privacy/proprietary lock-in concerns that don't seem to be in line with the spirit of open-source. Also see [1]. [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...
- spencerchubb 3y ago
  Are there any FOSS alternatives to Discord that are free (as in money)
  - toastercat 3y ago
    Zulip is free for open source projects. Creating a channel on Matrix.org is free.
  - toastal 3y ago
    Conversations & blabber.im offer free XMPP accounts. I self-host so I haven’t tested whether or not its users can create MUCs on those servers. Libera.Chat & OFTC offer free IRC for open source—& can depending on the community be a welcome bridged platform for any alternative as IRC requires the least resources to run (tho if you need rooms with encryption, that won’t be an option).
- Alifatisk 3y ago
  Could answeroverflow.com be a temporary solution to this?
- Liquix 3y ago
  Not likely even in light of how important it is to not use Discord. In the comments of the bun 0.6 announcement, a question similar to yours was downvoted almost enough to get flagged: https://news.ycombinator.com/item?id=35970869 https://news.ycombinator.com/item?id=35970869 And in the comments of the bun 0.8 announcement, the same question generates very little interest and some well every other project uses it, so...: https://news.ycombinator.com/item?id=37244294 https://news.ycombinator.com/item?id=37244294
dabernathy89 3y ago
I have been testing out Bun w/ Nest JS, and oddly it can run a dev server but can't run my E2E tests (using the Bun test runner). I think this has something to do with Nest's heavy reliance on old-school TS decorators.
- Jarred 3y ago
  We haven't added support for emitDecoratorMetadata yet but we have a branch that does most of the work. It just needs some more tests before we're comfortable merging it
  - AbuAssar 3y ago
    looking forward for a full (I mean good enough) nestjs compatibility!
  - dabernathy89 3y ago
    Woohoo!
norman784 3y ago
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.
Cu3PO42 3y ago
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. 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. 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'm afraid the effort would not be worth it right now.
coder543 3y ago
How compatible is Bun with Remix[0]? 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. [0]: http://remix.run/ http://remix.run/
- Jarred 3y ago
  Remix in Bun works on Linux. The built version also works on macOS, but the dev version is blocked on us upgrading WebKit. Intl.ListFormat which Remix uses depends on a newer version of ICU which the current version of WebKit uses but we didn’t want to upgrade WebKit immediately before 1.0 so we held off for this release.
cmbothwell 3y ago
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. 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. It has to be a similar feeling as going from CMake to Cargo.
TheAceOfHearts 3y ago
I love that you engage with the community on both HN and Twitter. It's always interesting to see your polls on how certain features should be implemented. Any plans for other interesting experimental features (like macros)? I don'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?
pmayrgundter 3y ago
Thanks sir! Been looking forward to this and spinning it up right now :)
lhnz 3y ago
> The transition from CommonJS to ES modules has been slow and full of terrors. > Bun supports both module systems, all the time. No need to worry about file > extensions, .js vs .cjs vs .mjs, or including "type": "module" in your > package.json. > > You can even use import and require(), in the same file. It just works. This is the highlight for me. The Node.js ecosystem is more-or-less completely broken otherwise. This might save it. (I think that the most impressive thing about Bun isn't its performance but the pragmatic, developer-friendly choices that have been consistently made by Jarred.)
- Rapzid 3y ago
  I've been creating module projects as default for nearly a year now. It's been largely fine for the past 6 months since Typescript 5.0 released with the "bundler" resolution strategy. Very rarely run into issues but have gotten around with pnpm patch and meta modifications in the past until projects have fixed issues.. My take is 2023 is the year of the module. The water is fine.
  - Rapzid 3y ago
    I don't usually comment on downvotes and I have just under 5k karma so it's uhh, just no thing to me typically.. It's also against the guidelines, but again 5k karma... That said, kinda curious now downvoted into negative for sharing my, extensive, experience creating module type projects.. Hrrmmm.
  - c-hendricks 3y ago
    So almost 10 years after modules were added to the spec, a few years after they've been available in most browsers, the past 6 months have been largely fine to use them for _new_ projects. That doesn't paint a great picture.
    - Rapzid 3y ago
      When I say fine I mean I've had no complaints with any aspect of my workflow since TypeScript released the bundler resolution strategy, which mostly just means you no longer need to specify extensions when importing.. I don't know about the past 10 years as I haven't tried to use modules for the past 10 years. I've been using them for the past year on new AND existing projects with Vite+React, Vite+Storybook, SWC+Fastify, Rollup and library projects, and etc. Unless somebody has to work in the past I'm sure what relevance that has on using modules in 2023.
pcmaffey 3y ago
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.
JeremyJaydan 3y ago
Love bun, but I disagree that blog post explains better what v1 is, but rather explaining what bun is in general. It hardly mentions anything until the very bottom on what's changed to reach v1, the github release page on the other hand clearly outlines it. Personally found the blog post to read like documentation rather than a release announcement.
JeremyJaydan 3y ago
I'm curious about the Bun Framework API, is there a release date set for that?
hudsonwillis 3y ago
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 'post something you built with bun along with resume' which really confused me as I don't typically build things ON Bun.
sprkv5 3y ago
Congratulations on reaching 1.0 ! Performance comparisons to Go/Java on the backend would be insightful. Would be interesting to see how close the gap is.
ChrisArchitect 3y ago
[dupe]
- ChrisArchitect 3y ago
  Yesterday's news, more discussion over here https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724
ChrisArchitect 3y ago
https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724
- dang 3y ago
  Yesterday was a mess, with first an announcement video and then a blog post released before they were supposed to. Normally we'd merge the threads but I don't think it makes much sense in this case - there's obviously community appetite to discuss this, so I think we probably just need to eat the duplication, even though we try hard not to. There's a slightly similar case high on the frontpage right now: https://news.ycombinator.com/item?id=37434918 https://news.ycombinator.com/item?id=37434918. The thing isn't released yet but the appetite to discuss it is strong.
rglover 3y ago
Congrats, Jarred. Have really enjoyed following along with your progress on Twitter. Excited to give Bun a deep dive :)
jedahan 3y ago
Is there a better phrasing you could use than "drop-in replacement" for a 1.0 release that has decided to not implement all of "node:"? The let-down from the first two projects not being a drop-in replacement is jarring, now I have to be skeptical of all communications coming from bun. 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 'dgram' in this announcement page doesn't show anything. 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? edit: found the docs on node support - https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis . Would be nice to link in the release notes. Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented
- vasergen 3y ago
  I think the version is actually closer to `1.0.0-beta` than to `1.0.0`. I just installed v 1.0.0 and run `bun repl` and it failed with exit status code 1, it turns out the repl wants to use port 3000, which was used in my case already. There are probably a lot of other small things like that, look on reported bugs in github. So, I also should be 'skeptical' about all claims they did. Nevertheless I am super impressed with their speed and exited with the result. Didn't expect this project to grow so quickly to this state, I though it will take them much more time. For comparison, deno was started way earlier and now they are miles behind (personal feeling). I am considering to use it for my pet projects
  - Jarred 3y ago
    bun repl was a last-minute hack we added. All it does is "bun x bun-repl" which is currently not an official thing. The repl is about to be added and rewritten completely
  - MatthiasPortzel 3y ago
    I’m a little surprised they announced 1.0 already. When I tried bun a little while ago, I noticed many bugs reported on GitHub around reading from standard-in and readline. I attributed it to being a pre-1.0 thing, but those bugs have not been resolved as far as I can tell.
helsontaveras18 3y ago
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).
Guillaume86 3y ago
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.
- drschwabe 3y ago
  Consider switching to Linux, I think you will see this trend a lot more.
  - metaltyphoon 3y ago
    What trend? The ignorant trend where a niche group of dev thinks Windows support should be second class, even though it ranks highest used by personal and professional developers year after year? I use all 3 OSes and this superiority complex is tiresome
    - nsonha 3y ago
      > superiority complex what do you base this ad hominem on? If you try to convince your company to deploy servers on a windows environment instead of linux, you better have a really extraodinary reason, that's just a fact. If Windows is any good it's because of the software ran on it (games and related drivers?), despite the OS
      - metaltyphoon 3y ago
        >what do you base this ad hominem on? Look at OP's original post. Why would one consider a change at all when everything that one needs is already in the OS? I mean... it could perhaps be a preference. Shocking right? Anyhow, I wouldn't convince any company to use windows environment unless necessary as you mentioned. However not all software are web servers and there are plenty of reason, not extraordinaryly, requiring a windows environment.
        morbicer 3y ago
bovermyer 3y ago
Oh that's awesome! Now to find out if this works for SvelteKit projects...
- mkl 3y ago
  I haven't tried it, but https://bun.sh/guides/ecosystem/sveltekit https://bun.sh/guides/ecosystem/sveltekit suggests it works fine.
- tacone 3y ago
  They have a tutorial for that, looks like it just works. The devil is the details by the way, I would just try everything from dev environment to building production bundles before switching tough.
makingstuffs 3y ago
Just wanted to say thanks. I’ve not been as excited to tryout some new tech in a *long* time.
dfabulich 3y ago
How does Bun support CJS and ESM in the same file? Is it transpiling CJS to ESM? Or is it transpiling ESM to CJS? ESM can use top-level await and CJS can't. So this can't possibly work, right? // x.mjs export const x = await 'x'; // y.cjs console.log(require('./x.mjs').x); And, indeed, it doesn't work in Bun. When I `bun y.cjs` it gives me this error message: TypeError: require() async module "/tmp/x.mjs" is unsupported. use "await import()" instead. … but using "await import()" instead is exactly what I was trying to avoid! I can use "await import()" in Node, too. 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? EDIT: I see the documentation page https://bun.sh/docs/runtime/modules https://bun.sh/docs/runtime/modules has a "low-level details" section, explaining how import(CJS) works (by transpiling CJS to ESM), but it doesn't say anything there about how require(ESM) works, which is unfortunate, because that's by far the most interesting part! I've filed a doc bug on this. https://github.com/oven-sh/bun/issues/4601 https://github.com/oven-sh/bun/issues/4601
- deleted 3y ago
  [deleted]
- ayewo 3y ago
  I believe Jarred has answered this upthread: https://news.ycombinator.com/item?id=37437848 https://news.ycombinator.com/item?id=37437848
Fervicus 3y ago
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's homepage. [0] - https://oven.sh/ https://oven.sh/
- leejoramo 3y ago
  I am skeptical of the long term viability of such projects that rely on VC funding. However, if I recall correctly, the early days of node.js was mostly funded by Joyent. It took time and some major conflicts for Node to be controlled by a foundation.
  - omginternets 3y ago
    Joylent isn't a VC fund, though, is it?
Jarred 3y ago
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't hide drafts 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) Thread from yesterday: https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724
- CoolCold 3y ago
  Doc's install section for Linux missing DEB/RPM, please update docs. Extra hint - you may provide text snippet for Ansible playbook/taskset with proper sha256/similar checksumming for installing via "Download from Internet, not from your distro repos", the same for Puppet (which gonna be bit more complicated). Will ease up a bit system's administrators work - SAX - system administrator experience, if you wanna name it that way :)
psanchez 3y ago
Jarred congrats for the release! I've been following the progress of bun since your initial announcement and today I decided to give it a try, just to play around. Haven't done much with it, but even for the 5 min I played with it I'm kind of impressed so far. - Superquick install PLUS did not require root (like many other installs) - It identified I was using fish shell and added to path (nice!) - I ran a very quick bench on "npm install" vs "bun install" on one of the projects I have, and the performance is amazing. 50seconds vs 4.5 seconds on the first install. Moreover re-executing "bun install" 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. I'll probably continue exploring tomorrow and see whether it is able to run the rest of the backend/frontend or whether it gives me a hard time. I've seen there are certain things that are not 100% compatible with node yet, but since the initial impressions are great I'll explore further. BTW A code formatter and a linter would be a great addition to bun. I know there is this ticket: https://github.com/oven-sh/bun/discussions/712 https://github.com/oven-sh/bun/discussions/712 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 ;) 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. Once again, thanks a lot for the effort to you and the rest of the people contributing to the project! (edit: re-formatted my comment :p)
attractivechaos 3y ago
On your github release page [1], there are both "bun-darwin-x64.zip" and "bun-darwin-x64-baseline.zip". What is the difference between them? Why the "aarch64" binaries don't have the baseline versions? In addition, your "bun-linux-x64.zip" doesn't work on CentOS7 due to glibc compatibility. Would be good to provide a more portable binary. [1] https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0 https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0
- IshKebab 3y ago
  Honestly if you run CentOS 7 you have to expect that most binaries won't work due to glibc compatibility issues. It's like 95% of the reason musl exists. I am amazed and not at all amazed that GCC has never got a --compatible-with-old-linux flag. To be fair MacOS doesn't really either, but people tend not to run 9 year old versions of MacOS.
mrinterweb 3y ago
Since Bun is VC backed, what is the monetization plan? One of the things I consider with new tech is "how likely will this tech still be actively developed in N years." Bun will need to make money somehow or funding will be pulled. I see bun's licensing is MIT, and that is fantastic. So that does give me some hope it won't die should the business go under. I hope the business succeeds, but I'm curious should I adopt bun, what might the upsell be down the road.
- bsimpson 3y ago
  There was a rad HMR devserver called Pundle. It was instant-fast, but it was also maintained by one guy in a poor country. Trying to keep up with one guy's side project caused me so much pain that I moved everything to Rollup and never looked back. VC funded and random side project clearly have different concerns, but the ultimate risk with either is "if the creator can't support me, then what"
  - deleted 3y ago
    [deleted]
- rnmkr 3y ago
  I guess they'll follow NextJS/Vercel or Deno/Deploy book or even License change shouldn't be out of question. Advertise everything as "open source", get free bug reports, contribution, marketing and adoption. Push everything into their commercial offering.
- fschuett 3y ago
  Since it's a bundler, I guess something like "bun deploy" to make money from hosting JS apps. It's a common strategy, getting mass developer adoption first, then soft-pushing for their private hosting of applications.
- crishoj 3y ago
  Business plan is outlined on https://oven.sh/ https://oven.sh/: Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun. It will support popular frontend frameworks like Next.js, Vite, SvelteKit, SolidStart and many more — along with backend frameworks like Express, Fastify, NestJS and more. The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible.
nfriedly 3y ago
Why would I want to choose Bun instead of Deno? 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?)
M4v3R 3y ago
Hey Jarred, congrats on the 1.0 release! I've tried this release on one of my projects and encountered some errors, where is the best place to send reports about compatibility issues?
- Jarred 3y ago
  Please file an isusue in https://github.com/oven-sh/bun https://github.com/oven-sh/bun and include the code to reproduce it
javajosh 3y ago
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't bode well for its longevity (I realize this concern is a bit circular, since it's longevity would be improved with adoption). (It's just that I'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.)

1089 points by tuananh 3y ago

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

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.

vichle 3y ago
This is what I thought. After some fiddling it became clear that compatibility will be an issue for more applications than they claim. It's probably fine for new projects though.
jrvarela56 3y ago
I’ve been thinking about this anf trying it out. The only obviously bad thing is that the ‘drop-in replacement’ is bs: they’re aiming for it but there are a bunch of node std lib modules missing. Despite that it seems to work just fine for my Expo app and RNW project.
- jrvarela56 3y ago
  Check compat status here: https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis
rwalle 3y ago
limited Windows support -- I am surprised that this is hardly mentioned. People here may not admit this, but Windows-based developers are a huge group, and probably more than Linux or Mac (e.g. look at stackoverflow survey). If you tell people "You can't really use Bun as intended unless you use Mac or Linux or spend half an hour setting up WSL first", people are going to be turned away, especially for new developers. It may not matter to you personally, but if it is used in a project with developers working on different platforms, it is going to present some hurdles.

xavdid 3y ago

Congrats! Your blog post paints a very compelling value proposition for simpler, all-in-one (yet extensible) software. I find I'm more compelled these days by "batteries included" software than "bring your own everything", so I'm excited to try this out. 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](https://biomejs.dev/blog/annoucing-biome https://biomejs.dev/blog/annoucing-biome). I hope you find more success than they did! It's certainly a hard problem to solve.

kaizoku111 3y ago
I agree with "batteries included", if node.js and co etc. had a good harmonious ecosystem to begin with we wouldn't need such an approach. Looking at the way Apple does things, they own and control the hardware and OS which allows them to deeply optimise their systems and also provide an ease of mind knowing all their devices will work seamlessly across the board. Having an all-in-one toolkit reduces overhead of running around finding the perfect solutions, when it is already right in front of them.
- awestroke 3y ago
  On the other hand, the DX of Apple's development toolchain is among the worst in the world

rcarmo 3y ago

I don't suppose this can cope with Node-RED yet?

Jarred 3y ago
This might work now. It didn't in v0.5.x and earlier. We added proper CommonJS support and that means sloppy-mode features that Node-RED relies on should work just fine.
- rcarmo 3y ago
  It does! At least the base setup works with "bun run node-red". I will have to test third-party modules, of course, but the 3.1.0 release seems to work OK in 15 minutes of testing. I'll have to see how it goes on slower machines, ARM, etc. Thanks!
  - rcarmo 3y ago
    Another datapoint - wisp, my favorite LISP-to-JS transpiler, also apparently works fine: https://github.com/wisp-lang/wisp/issues/174 https://github.com/wisp-lang/wisp/issues/174 This makes for a pretty awesome combination considering bun's system calls and sqlite support.

gkfasdfasdf 3y ago

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

gwalkerux 3y ago

Wondering what (if any) telemetry data Bun collects? Ever since the telemetry in front-end tools website (https://telemetry.timseverien.com/ https://telemetry.timseverien.com/) was shared here a few months ago I've been wondering the same for other tools.

rmilejczz 3y ago

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 Either way still excited to check it out

losvedir 3y ago

Wow, that is a compelling landing page. It'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?

tlhunter 3y ago

What happens with circular require/import calls? Anything weird when requiring/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'm curious if anything funny happens.

ripperoni 3y ago

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

jlu 3y ago

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

bulk88 3y ago

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.

ComputerGuru 3y ago

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

tiffanyh 3y ago

Dumb question: since Bun is MIT licensed - why doesn’t Node just merge Buns code into Node? https://bun.sh/docs/project/licensing https://bun.sh/docs/project/licensing

swyx 3y ago
because the projects have different goals and are coded in different languages.
- leeoniya 3y ago
  ...and based on different JavaScript engines.
leeoniya 3y ago
"just" :_D

j-rom 3y ago

Is there an example one step above "Hello world" that new users can take a look at? There are a bunch of guides for different API's / constructs but I'm wondering if there's a canonical example to get started. Guides: https://bun.sh/guides https://bun.sh/guides

petabytes 3y ago

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't believe people put up with this. Glad to see there is a solution.

khiner 3y ago

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!

auraham 3y ago

deno or bun for learning?

CoolCold 3y ago

superseded by https://news.ycombinator.com/item?id=37442646 https://news.ycombinator.com/item?id=37442646 ==== Doc's install section for Linux missing DEB/RPM

seymon 3y ago

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

evnix 3y ago
Not nestJS, but built around express typeorm and the rest and the code base is 5 years old so you can imagine. Bun has seriously been a god send. I am so happy that we can finally do top level awaits and it allowed us to delete a lot of hacky code that we had in place just to make node and all the build dependencies happy.

jbverschoor 3y ago

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

nkmnz 3y ago

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: ERROR Cannot build module „nuxt“ {}

danielroe 3y ago
I'm not aware of any issues as long as you are on the latest Nuxt and nuxi versions, so it might be easier to help if you open an issue with a reproduction on https://github.com/nuxt/nuxt/issues https://github.com/nuxt/nuxt/issues.
- nkmnz 3y ago
  Will do once I’ve investigated more. Tried bun yesterday evening and just saw this thread this morning while heading to the lake :) Thank you for your awesome work on nuxt 3, by the way!
  - danielroe 3y ago
    You're very welcome It's definitely a team effort. Feel free to DM me if I can be helpful.

christophilus 3y ago

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.

fabioono25 3y ago

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.

deleted 3y ago

[deleted]

hollowturtle 3y ago

It really seems impressive to me. I think I'll try it as a tool first, later as a runtime. Just wondering why has been built using Apple'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?

jeroenhd 3y ago
Both engines are really fast, both of them have places where they beat the other. For a while, JavaScriptCore was the fastest Javascript runtime, then V8 took over again, and now Spidermonkey is the fastest if you cherry pick the right tests. The places where WebKit lags behind aren't the places Bun really cares about. I'm honestly quite glad they add some diversity to Javascript land. I recall reading a comment that JavaScriptCore was chosen because of performance. I believe JSC is quicker to start up, and I wouldn't be surprised if it wasn't faster at executing the type of code Bun executes as well.

zx2c4 3y ago

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'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's true.) Any seasoned users with time spent on both?

manojlds 3y ago
Deno wanted a post-Node way but they have gone back on their original ambitions (which never resonated with me, to be frank) and now have a pretty limited compatbility whereas Bun has full compatibility with Node.
- ignoramous 3y ago
  Per their own docs, Bun is not fully Node compatible [0]. In my experience, even for APIs its docs claim full-compatibility has some sharp edges. That said, Bun's node-compat story is better than Deno's. While Node's performance story keeps improving release over release [1]. [0] https://archive.is/NCzRQ https://archive.is/NCzRQ [1] https://twitter.com/lemire/status/1699459534190698999 https://twitter.com/lemire/status/1699459534190698999
re-thc 3y ago
Deno wanted to be different but never did enough to force its way. Maybe if they had 10x the funding to rewrite the ecosystem. Now it's in limbo. Bun aims to be a better replacement to Node. There's less to consider so it's just a matter of if it's compatible enough and faster / better to warrant the switch. A lot easier to swallow.
- ShadowBanThis01 3y ago
  There's plenty to consider if you don't care about Node compatibility. From what I've read (including in this thread and on the Bun PR page), Node seems pretty messy, with modules coming from different sources in different ways. In Deno you just import with a URL. I know very little about JS and TS and "modules," but from a newcomer that's how it all looks. I'm happy to have any further insight!

jkubicek 3y ago

I thought we, as an industry, had all agreed that `curl https://bun.sh/install https://bun.sh/install | bash` was something we should never do and never encourage.

fkyoureadthedoc 3y ago
If you don't trust bun.sh don't do it. They would be torpedoing their project if they put something nefarious in there though, and it would probably more effective to put the nefarious stuff in bun directly. Yes a 3rd party could have gained access to their site and modified that script, but that's covered under "trust bun.sh".
- williamstein 3y ago
  It's also a short, clean and easy to read shell script.
mekster 3y ago
If you can't trust that, then I suppose you're checking every node_modules dir for any malicious codes but I guess you're just being allergic to pipe bash.
nonethewiser 3y ago
Can you walk us through an alternative and why it would be safer?
pxeger1 3y ago
I don't like `curl|bash` not because it's insecure but because I don't know what it's doing to my system, and I don't believe that it understands my system properly. Ideally I'd download a single binary and put it in /usr/local/bin myself.
Rapzid 3y ago
You have it backwards. Even Microsoft posts install scripts such as this for DotNet.

Jarred 3y ago

I work on Bun. Happy to answer any questions Could the mods change the link to the blog post? It explains better than the github release page Blog post: https://bun.sh/blog/bun-v1.0 https://bun.sh/blog/bun-v1.0

dang 3y ago
Ok, changed from https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0 https://github.com/oven-sh/bun/releases/tag/bun-v1.0.0.
- Jarred 3y ago
  Thank you

OriPekelman 3y ago

Oh its a Friday. Deploying on Fridays is what we do. Here you go ... Bun 1.0 officially deployed on Platform.sh https://platform.sh/blog/bun-support-is-here/ https://platform.sh/blog/bun-support-is-here/ enjoy.

OriPekelman 3y ago
Also. As I am excited. Here you go for a one-click deploy .. https://github.com/OriPekelman/express-bun/ https://github.com/OriPekelman/express-bun/ Very unofficial. Very.
Nezteb 3y ago
Slightly hijacking this thread to ask: I've not heard of Platform.sh before. Do y'all have a free/hobby plan for someone wanting to become familiar with the it? If not, no worries.
- OriPekelman 3y ago
  We are not big on free. We like money :) And people like that we will probably be around in a decade (and won't stop free as soon as we've locked enough people -in). We do have a no-strings-attached free trial ...

fithisux 3y ago

Congratulations for the release.

zengid 3y ago

Congrats!

jkrems 3y ago

Congrats on 1.0!

wdb 3y ago

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

arpowers 3y ago

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

zengid 3y ago

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

billywhizz 3y ago
bun startup is fast compared to other JS runtimes but imo this is little or nothing to do with JSC versus v8 as the javascript engine. i did some experiments a while back and wrote them up here if you want to take a look. https://just.billywhizz.io/blog/on-javascript-performance-03/ https://just.billywhizz.io/blog/on-javascript-performance-03...
- leeoniya 3y ago
  awesome writeup, as always.
  - billywhizz 3y ago
    thanks! love your uPlot library btw!
    - leeoniya 3y ago
      <3

ryanrussell 3y ago

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

ggregoire 3y ago

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? I'm confused cause this guide on the official site showcases how to use Bun + Vite.js to build a TypeScript React app. [1] There is also this issue on their Github. [2] Can Vite.js be used to handle more complicated scenarios / advanced use cases that Bun doesn't handle? My use of Vite.js is pretty basic (start & build with the default TS+React config) so maybe I'm missing something here. -- [1] https://bun.sh/guides/ecosystem/vite https://bun.sh/guides/ecosystem/vite [2] https://github.com/oven-sh/bun/issues/250 https://github.com/oven-sh/bun/issues/250

fyzix 3y ago
My guess is that you can leverage the vite's plugin ecosystem...postcss,tailwind,terser etc. And most of the new meta frameworks(nuxt,sveltekit,astro,solidstart,qwik) runs on vite so that might pave a path for adoption.
nsonha 3y ago
that's like asking why need vite when you have tsc. I assume bun does not "run Typescript React app", it only does the jsx,tsx transpiling out of the box.
brundolf 3y ago
It's a big ask to get people to adopt an ecosystem wholesale. Compatibility with the existing ecosystem is a key goal of Bun, so that people can start using it immediately on their existing codebases and then adopt it gradually for more and more stuff
jadbox 3y ago
I'm new around here, I've only seen people use Vite with bun for HMR, but imho, it's not great to combine them just yet as there's config complexity.
- ggregoire 3y ago
  I thought Bun had HRM out-of-the-box but it's not working? Not sure. https://github.com/oven-sh/bun/issues/833 https://github.com/oven-sh/bun/issues/833

creativeembassy 3y ago

Personal experience: Bun has been a flawless drop-in replacement for both NodeJS and npm/yarn since I started using it around v0.4. Not only have I had zero issues running it, but it's been WAY faster. No benchmarks, but very noticeable, from "let's start a new build and go grab a coffee while waiting for it" on NodeJS, to "hit run aaaaand it's done." I haven'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.

revskill 3y ago
So it means you'll drink less coffee, and it's not good for productivity reason.
moralestapia 3y ago
I've worked on several large node.js codebases and builds never took more than a few seconds, def. not "go grab coffee" time, so maybe something else was going on.
- isuckatcoding 3y ago
  It’s not uncommon to have a nodejs library take like 10-15 mins to go through building and testing in GitHub actions CI
  - moralestapia 3y ago
    >and testing And Bun is going to improve that?
  - nonethewiser 3y ago
    But that’s probably more about tests and github resources than raw build times.
    - nbittich 3y ago
      Average angular apps take at least 4 min in release mode on machine.

oefrha 3y ago

> It reads your package.json and writes to node_modules, just like other package managers, so you can replace: > ... > pnpm pnpm's flagship feature is global deduplication of packages, so sadly bun's package manager doesn'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.) That said, I'm very impressed with the speed of `bun add` with already cached packages. Literally instant.

Cu3PO42 3y ago
Bun already supports that [0]. It is the default behavior on Linux, but can also be enabled on macOS. [0] https://bun.sh/docs/install/cache#saving-disk-space https://bun.sh/docs/install/cache#saving-disk-space
- oefrha 3y ago
  Nice! I was looking at du(1) output on macOS which appears to indicate all files are duplicated. It probably just can’t tell the files are clonefile’d.
  - Jarred 3y ago
    There is a very obscure undocumented api in macOS for detecting if two files are equal block-by-block but yeah I don’t think most tools can tell when files are clonefile’d
    - Cu3PO42 3y ago
      Just a note on your documentation: it says "this benefit does not extend to macOS" about saving disk space. I find that to be slightly misleading. Since arguably the most common FS for macOS is now APFS, it does save significant disk space unless one were to modify the node_modules files.
- thunderbong 3y ago
  Any chance of this coming to Windows? Most of our developers are on Windows systems.

jzelinskie 3y ago

Congrats on the launch! The NextJS guide[0] claims that bun doesn't support all the node APIs to run the dev server, is that still the case with 1.0? [0]: https://bun.sh/guides/ecosystem/nextjs https://bun.sh/guides/ecosystem/nextjs

Jarred 3y ago
We landed Next.js pages directory support two days ago and forgot to update that guide
- jzelinskie 3y ago
  Awesome! Reading through the install script now -- would you considering using installing to $XDG_DATA_HOME and falling back to `~/.bun`?
- notsrg 3y ago
  Any docs for migrating an existing Nextjs project? No rush but would be great to have :)

eimthefea 3y ago

Congratulation to the project, it seems incredible. I don't know that much so I have some questions, sorry if they're already answered. (share link if any if its possible) 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 ? 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 ? I've seen Deno putting a lot of effort into the platform around their runtime, making deploying Deno app easy, is that your goal too ? I've seen that you use Zig instead of C++, what do you like the most about Zig while working on Bun ? In anyway, I hope the project will make the JSRuntime world better, its promising.

theredsix 3y ago

Congrats on the release!

tlarkworthy 3y ago

You write typescript and unit test without tsc, jest, webpack/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. I love it, it super simplifies project and for minimalists it's perfect.

iainmerrick 3y ago
How do you do type-checking? Do you just run TSC with “noEmit: true”, like you’d do with any other bundler? TSC is simultaneously the most valuable and the most flaky part of your typical JS project setup. That’s the main part I’d be interested in replacing with a different tool.
- tlarkworthy 3y ago
  It reads the tsconfig file if present. You just write TS files and bun build outputs JS. Vscode highlights typecheck errors based on TS errors. Bun build fails if you can't typecheck. No tsc installation necessary, but also consistency with tsc if you use a tsconfig. For simple stuff tsconfig is not needed
  - iainmerrick 3y ago
    Bun build fails if you can't typecheck It has to run TSC (or expect somebody else to run it) in order to typecheck, though, right?
    - simon04 3y ago
      That's my understanding, too. > Bun can run .js, .ts, .cjs, .mjs, .jsx, and .tsx files, which can replace: > > tsc — (but you can keep it for typechecking!)
    - tlarkworthy 3y ago
      I am mistaken. Yeah bun does not typescheck like esbuild doesn't. It reads the tsconfig for build options. Either you add tsc or let your editor do it.

majestic5762 3y ago

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

deleted 3y ago

[deleted]

skybrian 3y ago

Any plans for Electron support (or similar)?

brundolf 3y ago

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

toastal 3y ago

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

dudus 3y ago

There was some criticism yesterday about bun being stable using a language (zig) that isn't considered stable. Do you care to comment about it? Ref: https://news.ycombinator.com/item?id=37422894 https://news.ycombinator.com/item?id=37422894

solatic 3y ago
Zig isn't an interpreted language; once the code is compiled, the produced artifact doesn't change. Stability doesn't really play a factor there. Sure, the instability of Zig may increase the maintenance costs for Jarred, to use updated versions of Zig. But this has no effect on the features that Bun provides. The risk that a change to Zig would be so consequential that they would actually prevent Jarred from continuing to work on Bun, or would otherwise force Jarred to fork Zig, that risk is so low as to be inconsequential. (disclaimer: not associated with either bun or zig, the above are pure opinions)
- zengid 3y ago
  Not OP but I think they meant Zig isn't 1.0 and therefore could be considered "not ready for prod". I'm not claiming anything about Zig; I can only hope that the Bun folks have done their due diligence and ran it through fuzzing/ASAN/etc before making the 1.0 stamp of approval.
  - albedoa 3y ago
    That's the point being addressed by the comment you are responding to.
- swyx 3y ago
  also stability is more of a statement about api design than internals
- kaba0 3y ago
  That in itself is no good argument -- it surely has some bug, and if, say, zig changes in the meanwhile and it can no longer compile the previous code then it can be problematic from a maintenance POV. With that said, it is probably fine to use for most ordinary apps, but I wouldn't yet build a bank infrastructure on top for example.

padjo 3y ago

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. Realistically how much of a problem is this likely to be?

postalrat 3y ago
Calm down Gramps. People have moved on. Rust is yesterday's technology.
shawabawa3 3y ago
I guarantee zig is 100x more production ready than 99% of the 4 million nested dependencies included in the average js project
- petabytes 3y ago
  I tried to compile a hello world template for Zig a few months ago. Pulled it from GitHub, zig build and it gave an error. The problem? They recently redesigned a major part of the build system and deprecated old functions. No deprecated message, and no backwards compatibility. Just a plain old undefined function error. That's what I don't like about these modern languages. You have to be in the community and keep up with the latest releases in order to use the language. I just want something that's stable. I don't want to keep relearning everything.
- nonethewiser 3y ago
  Node or Deno dependencies would be a fairer comparison.
- vntx 3y ago
  Wow, that many guarantees should persuade me to base my tech stack on Bun and Zig. Seriously, I think this question is worth asking. Why was Zig chosen as the language when it’s not even stable, and what implications does this have for the long term viability of the project (besides the fact that its _fast_)? Zig’s head guy isn’t even sure when Zig will hit v.1.0, and Bun’s head guy hasn’t really responded either AFAIK.

simonw 3y ago

OK, I'm impressed. It took 0.01s to run 'bun install react': % cd /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

Timon3 3y ago
That's probably because it was cached! The first install is "a lot" slower than subsequent ones: $ cd /tmp/ $ mkdir app1 && cd app1 $ time bun install react bun add v1.0.0 (822a00c4) installed react@18.2.0 3 packages installed [431.00ms] real 0m0.436s user 0m0.031s sys 0m0.052s $ cd .. $ mkdir app2 && cd app2 $ time bun install react bun add v1.0.0 (822a00c4) installed react@18.2.0 3 packages installed [6.00ms] real 0m0.010s user 0m0.006s sys 0m0.005s Though even 431ms is obviously amazing!
- billywhizz 3y ago
  on my currently crappy internet on ubuntu 22 i get ~2.65 seconds for bun and ~5.6 seconds for npm for a clean install without caching. so approx 2x as fast as npm.

toastercat 3y ago

Congrats! 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/privacy/proprietary lock-in concerns that don't seem to be in line with the spirit of open-source. Also see [1]. [1] https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS.html https://drewdevault.com/2021/12/28/Dont-use-Discord-for-FOSS...

spencerchubb 3y ago
Are there any FOSS alternatives to Discord that are free (as in money)
- toastercat 3y ago
  Zulip is free for open source projects. Creating a channel on Matrix.org is free.
- toastal 3y ago
  Conversations & blabber.im offer free XMPP accounts. I self-host so I haven’t tested whether or not its users can create MUCs on those servers. Libera.Chat & OFTC offer free IRC for open source—& can depending on the community be a welcome bridged platform for any alternative as IRC requires the least resources to run (tho if you need rooms with encryption, that won’t be an option).
Alifatisk 3y ago
Could answeroverflow.com be a temporary solution to this?
Liquix 3y ago
Not likely even in light of how important it is to not use Discord. In the comments of the bun 0.6 announcement, a question similar to yours was downvoted almost enough to get flagged: https://news.ycombinator.com/item?id=35970869 https://news.ycombinator.com/item?id=35970869 And in the comments of the bun 0.8 announcement, the same question generates very little interest and some well every other project uses it, so...: https://news.ycombinator.com/item?id=37244294 https://news.ycombinator.com/item?id=37244294

dabernathy89 3y ago

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

Jarred 3y ago
We haven't added support for emitDecoratorMetadata yet but we have a branch that does most of the work. It just needs some more tests before we're comfortable merging it
- AbuAssar 3y ago
  looking forward for a full (I mean good enough) nestjs compatibility!
- dabernathy89 3y ago
  Woohoo!

norman784 3y ago

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.

Cu3PO42 3y ago

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. 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. 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'm afraid the effort would not be worth it right now.

coder543 3y ago

How compatible is Bun with Remix[0]? 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. [0]: http://remix.run/ http://remix.run/

Jarred 3y ago
Remix in Bun works on Linux. The built version also works on macOS, but the dev version is blocked on us upgrading WebKit. Intl.ListFormat which Remix uses depends on a newer version of ICU which the current version of WebKit uses but we didn’t want to upgrade WebKit immediately before 1.0 so we held off for this release.

cmbothwell 3y ago

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. 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. It has to be a similar feeling as going from CMake to Cargo.

TheAceOfHearts 3y ago

I love that you engage with the community on both HN and Twitter. It's always interesting to see your polls on how certain features should be implemented. Any plans for other interesting experimental features (like macros)? I don'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?

pmayrgundter 3y ago

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

lhnz 3y ago

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

Rapzid 3y ago
I've been creating module projects as default for nearly a year now. It's been largely fine for the past 6 months since Typescript 5.0 released with the "bundler" resolution strategy. Very rarely run into issues but have gotten around with pnpm patch and meta modifications in the past until projects have fixed issues.. My take is 2023 is the year of the module. The water is fine.
- Rapzid 3y ago
  I don't usually comment on downvotes and I have just under 5k karma so it's uhh, just no thing to me typically.. It's also against the guidelines, but again 5k karma... That said, kinda curious now downvoted into negative for sharing my, extensive, experience creating module type projects.. Hrrmmm.
- c-hendricks 3y ago
  So almost 10 years after modules were added to the spec, a few years after they've been available in most browsers, the past 6 months have been largely fine to use them for _new_ projects. That doesn't paint a great picture.
  - Rapzid 3y ago
    When I say fine I mean I've had no complaints with any aspect of my workflow since TypeScript released the bundler resolution strategy, which mostly just means you no longer need to specify extensions when importing.. I don't know about the past 10 years as I haven't tried to use modules for the past 10 years. I've been using them for the past year on new AND existing projects with Vite+React, Vite+Storybook, SWC+Fastify, Rollup and library projects, and etc. Unless somebody has to work in the past I'm sure what relevance that has on using modules in 2023.

pcmaffey 3y ago

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.

JeremyJaydan 3y ago

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

JeremyJaydan 3y ago

I'm curious about the Bun Framework API, is there a release date set for that?

hudsonwillis 3y ago

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 'post something you built with bun along with resume' which really confused me as I don't typically build things ON Bun.

sprkv5 3y ago

Congratulations on reaching 1.0 ! Performance comparisons to Go/Java on the backend would be insightful. Would be interesting to see how close the gap is.

ChrisArchitect 3y ago

[dupe]

ChrisArchitect 3y ago
Yesterday's news, more discussion over here https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724

ChrisArchitect 3y ago

https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724

dang 3y ago
Yesterday was a mess, with first an announcement video and then a blog post released before they were supposed to. Normally we'd merge the threads but I don't think it makes much sense in this case - there's obviously community appetite to discuss this, so I think we probably just need to eat the duplication, even though we try hard not to. There's a slightly similar case high on the frontpage right now: https://news.ycombinator.com/item?id=37434918 https://news.ycombinator.com/item?id=37434918. The thing isn't released yet but the appetite to discuss it is strong.

rglover 3y ago

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

jedahan 3y ago

Is there a better phrasing you could use than "drop-in replacement" for a 1.0 release that has decided to not implement all of "node:"? The let-down from the first two projects not being a drop-in replacement is jarring, now I have to be skeptical of all communications coming from bun. 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 'dgram' in this announcement page doesn't show anything. 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? edit: found the docs on node support - https://bun.sh/docs/runtime/nodejs-apis https://bun.sh/docs/runtime/nodejs-apis . Would be nice to link in the release notes. Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented

vasergen 3y ago
I think the version is actually closer to `1.0.0-beta` than to `1.0.0`. I just installed v 1.0.0 and run `bun repl` and it failed with exit status code 1, it turns out the repl wants to use port 3000, which was used in my case already. There are probably a lot of other small things like that, look on reported bugs in github. So, I also should be 'skeptical' about all claims they did. Nevertheless I am super impressed with their speed and exited with the result. Didn't expect this project to grow so quickly to this state, I though it will take them much more time. For comparison, deno was started way earlier and now they are miles behind (personal feeling). I am considering to use it for my pet projects
- Jarred 3y ago
  bun repl was a last-minute hack we added. All it does is "bun x bun-repl" which is currently not an official thing. The repl is about to be added and rewritten completely
- MatthiasPortzel 3y ago
  I’m a little surprised they announced 1.0 already. When I tried bun a little while ago, I noticed many bugs reported on GitHub around reading from standard-in and readline. I attributed it to being a pre-1.0 thing, but those bugs have not been resolved as far as I can tell.

helsontaveras18 3y ago

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).

Guillaume86 3y ago

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.

drschwabe 3y ago
Consider switching to Linux, I think you will see this trend a lot more.
- metaltyphoon 3y ago
  What trend? The ignorant trend where a niche group of dev thinks Windows support should be second class, even though it ranks highest used by personal and professional developers year after year? I use all 3 OSes and this superiority complex is tiresome
  - nsonha 3y ago
    > superiority complex what do you base this ad hominem on? If you try to convince your company to deploy servers on a windows environment instead of linux, you better have a really extraodinary reason, that's just a fact. If Windows is any good it's because of the software ran on it (games and related drivers?), despite the OS
    - metaltyphoon 3y ago
      >what do you base this ad hominem on? Look at OP's original post. Why would one consider a change at all when everything that one needs is already in the OS? I mean... it could perhaps be a preference. Shocking right? Anyhow, I wouldn't convince any company to use windows environment unless necessary as you mentioned. However not all software are web servers and there are plenty of reason, not extraordinaryly, requiring a windows environment.
      - morbicer 3y ago

bovermyer 3y ago

Oh that's awesome! Now to find out if this works for SvelteKit projects...

mkl 3y ago
I haven't tried it, but https://bun.sh/guides/ecosystem/sveltekit https://bun.sh/guides/ecosystem/sveltekit suggests it works fine.
tacone 3y ago
They have a tutorial for that, looks like it just works. The devil is the details by the way, I would just try everything from dev environment to building production bundles before switching tough.

makingstuffs 3y ago

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

dfabulich 3y ago

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

deleted 3y ago
[deleted]
ayewo 3y ago
I believe Jarred has answered this upthread: https://news.ycombinator.com/item?id=37437848 https://news.ycombinator.com/item?id=37437848

Fervicus 3y ago

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's homepage. [0] - https://oven.sh/ https://oven.sh/

leejoramo 3y ago
I am skeptical of the long term viability of such projects that rely on VC funding. However, if I recall correctly, the early days of node.js was mostly funded by Joyent. It took time and some major conflicts for Node to be controlled by a foundation.
- omginternets 3y ago
  Joylent isn't a VC fund, though, is it?

Jarred 3y ago

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't hide drafts 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) Thread from yesterday: https://news.ycombinator.com/item?id=37424724 https://news.ycombinator.com/item?id=37424724

CoolCold 3y ago
Doc's install section for Linux missing DEB/RPM, please update docs. Extra hint - you may provide text snippet for Ansible playbook/taskset with proper sha256/similar checksumming for installing via "Download from Internet, not from your distro repos", the same for Puppet (which gonna be bit more complicated). Will ease up a bit system's administrators work - SAX - system administrator experience, if you wanna name it that way :)

psanchez 3y ago

Jarred congrats for the release! I've been following the progress of bun since your initial announcement and today I decided to give it a try, just to play around. Haven't done much with it, but even for the 5 min I played with it I'm kind of impressed so far. - Superquick install PLUS did not require root (like many other installs) - It identified I was using fish shell and added to path (nice!) - I ran a very quick bench on "npm install" vs "bun install" on one of the projects I have, and the performance is amazing. 50seconds vs 4.5 seconds on the first install. Moreover re-executing "bun install" 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. I'll probably continue exploring tomorrow and see whether it is able to run the rest of the backend/frontend or whether it gives me a hard time. I've seen there are certain things that are not 100% compatible with node yet, but since the initial impressions are great I'll explore further. BTW A code formatter and a linter would be a great addition to bun. I know there is this ticket: https://github.com/oven-sh/bun/discussions/712 https://github.com/oven-sh/bun/discussions/712 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 ;) 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. Once again, thanks a lot for the effort to you and the rest of the people contributing to the project! (edit: re-formatted my comment :p)

attractivechaos 3y ago

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

IshKebab 3y ago
Honestly if you run CentOS 7 you have to expect that most binaries won't work due to glibc compatibility issues. It's like 95% of the reason musl exists. I am amazed and not at all amazed that GCC has never got a --compatible-with-old-linux flag. To be fair MacOS doesn't really either, but people tend not to run 9 year old versions of MacOS.

mrinterweb 3y ago

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

bsimpson 3y ago
There was a rad HMR devserver called Pundle. It was instant-fast, but it was also maintained by one guy in a poor country. Trying to keep up with one guy's side project caused me so much pain that I moved everything to Rollup and never looked back. VC funded and random side project clearly have different concerns, but the ultimate risk with either is "if the creator can't support me, then what"
- deleted 3y ago
  [deleted]
rnmkr 3y ago
I guess they'll follow NextJS/Vercel or Deno/Deploy book or even License change shouldn't be out of question. Advertise everything as "open source", get free bug reports, contribution, marketing and adoption. Push everything into their commercial offering.
fschuett 3y ago
Since it's a bundler, I guess something like "bun deploy" to make money from hosting JS apps. It's a common strategy, getting mass developer adoption first, then soft-pushing for their private hosting of applications.
crishoj 3y ago
Business plan is outlined on https://oven.sh/ https://oven.sh/: Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun. It will support popular frontend frameworks like Next.js, Vite, SvelteKit, SolidStart and many more — along with backend frameworks like Express, Fastify, NestJS and more. The plan is to run our own servers on the edge in datacenters around the world. Oven will leverage end-to-end integration of the entire JavaScript stack (down to the hardware) to make new things possible.

nfriedly 3y ago

Why would I want to choose Bun instead of Deno? 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?)

M4v3R 3y ago

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

Jarred 3y ago
Please file an isusue in https://github.com/oven-sh/bun https://github.com/oven-sh/bun and include the code to reproduce it

javajosh 3y ago

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't bode well for its longevity (I realize this concern is a bit circular, since it's longevity would be improved with adoption). (It's just that I'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.)