> 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.)
This problem is very old at this point. I'm doubtful that Bun has "solved it" any more than other tools. They've just selected a different set of trade-offs that will result in a different set of packages not working. Is there a reason to think they've cracked some code that other tools were unable to?
In Bun, you can use import and require in the same file. There's three steps for what makes this work:
1) We patched JavaScriptCore to load ES Modules synchronously when they don't use top-level await. The main tradeoff here is that requiring an ES Module which uses top-level await is unsupported (Bun throws an exception when you try to do this)
2) To support require() inside ES Modules, we add `import.meta.require` and have a transpiler integration to convert calls to module.require() or require() into import.meta.require(). This either loads the file as an ES Module or as a CommonJS module, depending on what the transpiler says it is
3) We rely on certain heuristics to decide whether a script is an ES Module or a CommonJS module. If they use certain sloppy mode or CommonJS-only features, it becomes CommonJS. If they use ESM features or it's somewhat ambiguous, it becomes an ES Module.
Yeah, definitely recommend you try it before discounting... I too have been super jaded with the current Node import ecosystem (esp. as an author), but Bun has basically become something of a silver bullet, with some small exceptions.
If I want, I can literally run a TS file directly with mixed import/require (not that you would ever) directly, without a package.json, tsconfig, dependencies, etc.
In my experience, it's basically Node, minus all the setup/config/build headaches.
This is what I pushed Node to support when they proposed their split syntax and I'm very happy to see Bun adopt this. It is the "correct" way as far as I'm concerned.
Node's split ecosystem has really hurt the entire language and runtime.
Every few years I end up having to write a bunch of JavaScript-- and recently it was time again for me to dig in. The `import` vs `require` thing caused me HOURS of pain. The modern JS ecosystem is truly painful if you're not using a react app or some off-the-shelf solution-- and I am not, I'm writing a small library. I honestly can't even fathom how difficult and maddening it has to be for folks just getting started.
The fact Bun solves that problem is more than enough of a reason for me to give it a try, I'm honestly fucking stoked to try it out, and I never thought I'd have those feelings for yet another JS runtime or build tool. Big thanks to the Bun folks, I'm looking forward to gaining some sanity in my day.
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.
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.
agree. i ought to be a javascript expert by now but nothing makes me feel dumber than navigating all the type:module and .js/cjs/mjs/ts stuff. for a production app of course you should be clear about what you are writing. but for prototyping Bun's permissiveness lets me write code first and worry about the rest later.
> for a production app of course you should be clear about what you are writing
Agree in sentiment, but I don't think this even applies to the module/import mess. My experience has been that the difficulty is in using different packages that made different choices, and making them interop with your own code. I have still yet to make top-level await work in a Typescript codebase where I need to import nontrivial packages. I don't think you should ever need to worry about the specific way your modules are imported, not in prototyping or in production.
yes, definitely and completely broken. require and import differentiation the most retarded changes, broke my build. spent sometime to understand the substantial difference, turned out it's nothing too substantial.
You may not be aware that node created a situation where ESM maximizes compatibility when consuming libraries and CJS maximizes compatibility when producing libraries. Its a circular incentive paradigm. I suspect you are consuming libraries using "import" and everything "just works". Well, under the hood you are likely importing many libraries that use CJS "module.exports" because that is what libraries use to ensure their library can be used with both import/ESM AND require/CJS.
The only solution to this problem is to upgrade require work for importing ESM. Once that is implemented ESM will become the natural choice for those publishing libraries. Until that happens library authors are going to continue to use CJS so their libraries are available to everyone.
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?
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
I just started a new project, writing the back end. I'm new to JS and TS, and I don't want to deal with NPM and a morass of modules at all. Deno, Oak, and MariaDB seem like a pretty tidy combo. I have routes and queries up and working with no experience in writing server-side code since PHP 5.
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.
> Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented
The question isn't just how many? but also which ones?. Anecdotally, I've been test driving bun for a large application with millions of existing customers. So far, the only issue I've had isn't with bun per se, it's with patch-package not yet supporting the lock file (bun.lockb).
Bun is without question faster than yarn by a wide margin. And I say this as someone who really loves yarn.
All good questions - and every person has different needs.
The fact is each potential adopter either needs to go through and comb over the compatibility page (not what I would expect with a drop-in replacement); or just try and see if it works, and be surprised later if they run into an unimplemented module because they were operating under an incorrect assumption.
Either I missed this on first read-through, or they just added it.
It seems the note mentioning this feels buried for me under a large banner image, instead of near all the other text about compatibility.
Anyway, glad it is there, hope that their communications design improves in the future as at least a few others got caught with mismanaged expectations.
I second this notion. I was really excited to try it out, only to have it fail to run most of our projects:
* can't use AWS SDK v3 because throws an error when parsing a response;
* can't use octokit (or anything that depends on jsonwebtoken, for that matter) because node:crypto is not fully implemented;
* can’t run our tests, because jest.resetAllMocks() is missing
* in another project, bun test failed to even run, complaining about invalid call to shared library
So for me the local workflow is “run it with bun, see if it fails, re-run with node if it does”. At least I can always replace npm with it, I guess? Can’t imagine running our services with it just yet. Really excited for the future of the project, because when it works - it really is amazing. But I wouldn’t call it 1.0 if the selling feature is Node compatibility.
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].
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:
Yet we should still continue to press against proprietary chat. Developers are the kind of folks wise enough about technology to know better than to support this. There are very good reasons to at a minimum support a bridge. If we have to teach new developers raised on Discord, then that’s a great opportunity for them.
> Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
Discord's accessibility has improved quite a bit. Even a screenreader user in the article's source section agrees:
> What I can tell you is that, to my surprise, Discord’s accessibility has apparently improved in recent years, and more blind people are using it now. One of my blind friends told me that most Discord functionality is very accessible and several blind communities are using it. He also told me about a group of young blind programmers who are using Discord to discuss the development of a new open-source screen reader to replace the current Orca screen reader for GNOME
Discord is honestly a great place for FOSS to house their communications. I find all of the articles claims very haphazard:
> When you choose Discord, you are legitimizing their platform and divesting from FOSS platforms
It is legit? It's free? It has loads of compelling features, is very accessible, and - most importantly... Also, choosing Discord does not take value away from FOSS communication platforms.
> Use IRC
It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
> Discord's accessibility has improved quite a bit. Even a screenreader user in the article's source section agrees:
Yes, but this ignores the others issues the post brings up: Users who cannot afford new enough hardware to make the resource-intensive client pleasant to use are also left by the wayside.
Or: Discord also declines service to users in countries under US sanctions, such as Iran.
> Discord is honestly a great place for FOSS to house their communications ... Discord does not take value away from FOSS communication platforms.
The blog's author, and others such as myself disagree. Discord chats are not indexible by search engines, so solutions are harder to find. You need a Discord account, and you need to join the channel to even see chat and use the search feature. Discord is proprietary and non-extensible because of it. Lastly, Discord is also profit-motivated, so they can shut things down or add limitations because they need to maintain a profit, and there would be nothing we can do about it. "Enshittification" as HN users love to say, is practically inevitable.
> It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
Which client are you speaking of? :) The beauty of IRC, Matrix, XMPP, etc is that you have the choice and freedom (without being legally threatened by Discord Inc.) to build your own client.
> choosing Discord does not take value away from FOSS communication platforms.
it does though. it's the same vicious cycle that allowed microsoft to gain control of the OS market: developers write programs for windows (because that's where the users are) and users run windows (because that's where the programs run). the more people agree to use discord, the more it becomes "the place where the <x> community is", the harder it becomes for any community to not use it.
9/10 discord users don't understand or care about this at all. which is why it's of utmost importance that developers - especially open source developers, presumably developing open source software for a reason - encourage discussion on other platforms.
Requiring stakeholders (users, contributors, whatever) in a free software project to use non-free software to fully participate in the community is a disservice to the movement, the users, and software freedom generally.
There's some room for debate about offering Discord as a bridged option. But having the official community chat only on Discord? How is there even a question?
Accessibility also refers to the hardware & network speeds of the users machine. Discord is a heavy web app (that also pings back a lot of analytics) with users actively using ‘heavy’ features like sending videos. It’s also subject to US sanctions or internal bans where entire countries can be blocked or do the blocking. Speaking of blocking, Discord could block a community member for a non-community-related reason (or by mistake) & there will be no way to resolve it since the community is not in control of the server.
Free as in gratis, sure. But as in libre? No, it’s definitely proprietary & it’s free because users are the product (data collected and upselling Nitro); not every user wants to give up their privacy freedoms to participate. Discord’s not federated so users will be required to create an account & agree to the ToS & CoC of Discord, not the community running it. Discord has also been hostile towards folks trying to make alternative clients to meet usability needs & certain kind of bots.
Without IRCV3 & bouncer it would be a difficult/unexpected experience for a new user. Luckily IRC isn’t the only libre option. If you want to keep the system requirements low XMPP MUCs are good & allow federation. If you want newer bells & whistles at the cost of system requirements federated Matrix can be considered (tho centralization concerns around Matrix.org having the most users, most used server, most used client, & controls the spec). There are bridges between all of these that you can choose as many or as few as meets the community needs such as a community-hosted XMPP main server in a neutral country with bridges to IRC & Discord.
> He also told me about a group of young blind programmers who are using Discord to discuss the development of a new open-source screen reader to replace the current Orca screen reader for GNOME
Could you link to the program they are working on? Nothing appears when searching for "orca screen reader for gnome replacement."
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).
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.
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.
Considering there are dozens of mainstream serverless hosting providers out there already, with more popping up every day and pricing going down to ~free, I can't really see this being a viable business model anymore.
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.
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.
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.
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). I hope you find more success than they did! It's certainly a hard problem to solve.
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.
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.)
I’m not over the moon with it but I’m kind of interested to know why I need a Node successor at all. Both Bun and Deno are VC funded tools so I have base level suspicion around monetization and longevity.
It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues.
Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility.
Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
These tools are way too young for anyone to have actually spent a lot of time using them.
Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem.
Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support.
So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
Not a seasoned users, mostly played with Deno. To me Deno seems more oriented to be an alternative Node runtime with security as first principle and built-in support for Typescript, JSX with some tooling like linter. It's also based on V8. My best guess it's what Ryan Dahl wanted Node to be as an afterthought. Bun, technically speaking is based on Webkit, but can't really say why, seems a better all-in-on tool(also remember rome?) and not only a runtime. Also with compatibility with current frameworks out of box, Deno wasn't npm compatible some time ago and I wonder if it ever meant to be and not a pivotal change on the run
> technically speaking is based on Webkit, but can't really say why
Why Bun uses WebKit/JSC was described here:
> One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that.
For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all.
The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
We're a full-stack TypeScript shop, and I manage ~50 internal libs and ~500K LOC of TS. Last month I tested out both Deno and Bun as alternative runtimes for us. TLDR: for any semi-complex codebase we have, Bun almost always works, Deno almost never works. We now run all our tests in both Node.js and Bun, and gave up on trying to make Deno happen.
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.
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!
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.
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].
Readit News
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
(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.)
1) We patched JavaScriptCore to load ES Modules synchronously when they don't use top-level await. The main tradeoff here is that requiring an ES Module which uses top-level await is unsupported (Bun throws an exception when you try to do this)
2) To support require() inside ES Modules, we add `import.meta.require` and have a transpiler integration to convert calls to module.require() or require() into import.meta.require(). This either loads the file as an ES Module or as a CommonJS module, depending on what the transpiler says it is
3) We rely on certain heuristics to decide whether a script is an ES Module or a CommonJS module. If they use certain sloppy mode or CommonJS-only features, it becomes CommonJS. If they use ESM features or it's somewhat ambiguous, it becomes an ES Module.
https://twitter.com/threepointone/status/1698271991927648643
If I want, I can literally run a TS file directly with mixed import/require (not that you would ever) directly, without a package.json, tsconfig, dependencies, etc.
In my experience, it's basically Node, minus all the setup/config/build headaches.
Node's split ecosystem has really hurt the entire language and runtime.
The fact Bun solves that problem is more than enough of a reason for me to give it a try, I'm honestly fucking stoked to try it out, and I never thought I'd have those feelings for yet another JS runtime or build tool. Big thanks to the Bun folks, I'm looking forward to gaining some sanity in my day.
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.
That doesn't paint a great picture.
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.
Agree in sentiment, but I don't think this even applies to the module/import mess. My experience has been that the difficulty is in using different packages that made different choices, and making them interop with your own code. I have still yet to make top-level await work in a Typescript codebase where I need to import nontrivial packages. I don't think you should ever need to worry about the specific way your modules are imported, not in prototyping or in production.
I only know that I perfer writing import over require as those semantics and syntax make more sense to me.
I remember hearing that once from the Python devs...
My stack is usually Fastify with official plugins and a PG client.
Maybe at most, hide the capability behind an execution flag.
The only solution to this problem is to upgrade require work for importing ESM. Once that is implemented ESM will become the natural choice for those publishing libraries. Until that happens library authors are going to continue to use CJS so their libraries are available to everyone.
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 . Would be nice to link in the release notes.
Cursory glance looks like for modules - 17 implemented - 17 partially implemented - 7 unimplemented
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
I just started a new project, writing the back end. I'm new to JS and TS, and I don't want to deal with NPM and a morass of modules at all. Deno, Oak, and MariaDB seem like a pretty tidy combo. I have routes and queries up and working with no experience in writing server-side code since PHP 5.
What makes Bun better?
The repl is about to be added and rewritten completely
The question isn't just how many? but also which ones?. Anecdotally, I've been test driving bun for a large application with millions of existing customers. So far, the only issue I've had isn't with bun per se, it's with patch-package not yet supporting the lock file (bun.lockb).
Bun is without question faster than yarn by a wide margin. And I say this as someone who really loves yarn.
The fact is each potential adopter either needs to go through and comb over the compatibility page (not what I would expect with a drop-in replacement); or just try and see if it works, and be surprised later if they run into an unimplemented module because they were operating under an incorrect assumption.
> Note — For a detailed breakdown of Node.js compatibility, check out: bun.sh/nodejs.
The detailed breakdown explicitly states which modules are not supported.
---
[1] Not a drop-in replacement
It seems the note mentioning this feels buried for me under a large banner image, instead of near all the other text about compatibility.
Anyway, glad it is there, hope that their communications design improves in the future as at least a few others got caught with mismanaged expectations.
* can't use AWS SDK v3 because throws an error when parsing a response;
* can't use octokit (or anything that depends on jsonwebtoken, for that matter) because node:crypto is not fully implemented;
* can’t run our tests, because jest.resetAllMocks() is missing
* in another project, bun test failed to even run, complaining about invalid call to shared library So for me the local workflow is “run it with bun, see if it fails, re-run with node if it does”. At least I can always replace npm with it, I guess? Can’t imagine running our services with it just yet. Really excited for the future of the project, because when it works - it really is amazing. But I wouldn’t call it 1.0 if the selling feature is Node compatibility.
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...
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
> Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
— Matt Lee
> What I can tell you is that, to my surprise, Discord’s accessibility has apparently improved in recent years, and more blind people are using it now. One of my blind friends told me that most Discord functionality is very accessible and several blind communities are using it. He also told me about a group of young blind programmers who are using Discord to discuss the development of a new open-source screen reader to replace the current Orca screen reader for GNOME
Discord is honestly a great place for FOSS to house their communications. I find all of the articles claims very haphazard:
> When you choose Discord, you are legitimizing their platform and divesting from FOSS platforms
It is legit? It's free? It has loads of compelling features, is very accessible, and - most importantly... Also, choosing Discord does not take value away from FOSS communication platforms.
> Use IRC
It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
Yes, but this ignores the others issues the post brings up: Users who cannot afford new enough hardware to make the resource-intensive client pleasant to use are also left by the wayside.
Or: Discord also declines service to users in countries under US sanctions, such as Iran.
> Discord is honestly a great place for FOSS to house their communications ... Discord does not take value away from FOSS communication platforms.
The blog's author, and others such as myself disagree. Discord chats are not indexible by search engines, so solutions are harder to find. You need a Discord account, and you need to join the channel to even see chat and use the search feature. Discord is proprietary and non-extensible because of it. Lastly, Discord is also profit-motivated, so they can shut things down or add limitations because they need to maintain a profit, and there would be nothing we can do about it. "Enshittification" as HN users love to say, is practically inevitable.
> It isn't IRC which is very inaccessible to lots of people new to computers and software in general.
Which client are you speaking of? :) The beauty of IRC, Matrix, XMPP, etc is that you have the choice and freedom (without being legally threatened by Discord Inc.) to build your own client.
it does though. it's the same vicious cycle that allowed microsoft to gain control of the OS market: developers write programs for windows (because that's where the users are) and users run windows (because that's where the programs run). the more people agree to use discord, the more it becomes "the place where the <x> community is", the harder it becomes for any community to not use it.
9/10 discord users don't understand or care about this at all. which is why it's of utmost importance that developers - especially open source developers, presumably developing open source software for a reason - encourage discussion on other platforms.
There's some room for debate about offering Discord as a bridged option. But having the official community chat only on Discord? How is there even a question?
Free as in gratis, sure. But as in libre? No, it’s definitely proprietary & it’s free because users are the product (data collected and upselling Nitro); not every user wants to give up their privacy freedoms to participate. Discord’s not federated so users will be required to create an account & agree to the ToS & CoC of Discord, not the community running it. Discord has also been hostile towards folks trying to make alternative clients to meet usability needs & certain kind of bots.
Without IRCV3 & bouncer it would be a difficult/unexpected experience for a new user. Luckily IRC isn’t the only libre option. If you want to keep the system requirements low XMPP MUCs are good & allow federation. If you want newer bells & whistles at the cost of system requirements federated Matrix can be considered (tho centralization concerns around Matrix.org having the most users, most used server, most used client, & controls the spec). There are bridges between all of these that you can choose as many or as few as meets the community needs such as a community-hosted XMPP main server in a neutral country with bridges to IRC & Discord.
Could you link to the program they are working on? Nothing appears when searching for "orca screen reader for gnome replacement."
Creating a channel on Matrix.org is free.
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).
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.
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.
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 Comment
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.
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). I hope you find more success than they did! It's certainly a hard problem to solve.
Any seasoned users with time spent on both?
It seems Bun’s major selling point is performance. I can’t say I’ve really run into massive performance concerns with Node. It isn’t earth shatteringly fast but I’m way more likely to run into IO constraints than Node speed issues.
Deno’s major selling point was that it was Node Done Right in many ways: better packaging, ES6 all the way, etc. (a pitch I was sold on!) but it seems they gave up trying to create a new ecosystem and instead are adding Node compatibility.
Alongside all of this I'm encouraged by a number of recent Node improvements like having its own test runner and built in .env support. So I’m struggling to see good reason to use either Bun or Deno. Even if I were to switch I'd need to make sure I have a concrete path back to Node should the new generation tool become unviable.
This is extremely compelling for frontend DX.
Not sure how they plan on monetizing.
Bun is bundling everything and making it really fast, while also striving to maintain as much compatibility as possible with Node. It doesn't throw away the existing ecosystem.
Deno took on too much of an adversarial perspective towards the Node ecosystem and now they're working towards re-adding support.
So in terms of a successor, I'd say the only option is Bun because it's still trying to maintain compatibility with Node while innovating with new features.
Why Bun uses WebKit/JSC was described here:
> One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that.
via https://bun.sh/blog/bun-v0.7.1#messageport-messagechannel-ar...
For new, from-scratch projects done by someone who doesn't know Node anyway, why not use Deno? I just started writing the server side of a mobile app with it, and I didn't even know JS, TS, or have any experience with routing frameworks. I had server-side queries working in a matter of days, and I don't claim to be fast at all.
The issues cited in the Bun PR, like the morass of modules and related performance problems, don't seem to exist in plain Deno. Or am I missing something? I don't anticipate ever integrating anything from NPM, so I'm actually disappointed (but understanding of the motivation) to see Deno hedge on the "fresh start" idea.
I have never used Node and am creating a new project from scratch, so I don't know how worried to be about your commentary.
Edit: sounds like this is changing. Thanks for the correction!
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.
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!
But, the command `bun install` supports NPM and custom registries, as well as Git and .tgz URLs.
https://bun.sh/docs/cli/install#git-dependencies
While Node's performance story keeps improving release over release [1].
[0] https://archive.is/NCzRQ
[1] https://twitter.com/lemire/status/1699459534190698999