The inevitable question: what does Bun do that Deno doesn’t and vice versa? Competition is always good and I applaud it heavily. What is Bun’s killer feature over Deno and why would I pick Bun over Deno for a new project?
Personally, I like that Bun aims to be "Node, but better". That's all I ever wanted.
Deno's desire to rethink server-side JS adds friction in service of goals I don't value. They're gradually giving ground their aspirations (e.g., in my memory it was previously a point of pride to not interoperate with NPM), but it's still not a drop-in replacement and I don't think they want it to be.
Bun's goals align with mine, so it's the one I prefer using.
In a word: pragmatism. Bun is pragmatic where Deno is “by the book”. Node.js globals like process are Bun globals. You can use require() and import in the same file. Bun is faster, easier to use, and more compatible with the JavaScript ecosystem. There’s less new stuff to learn. And that also makes Bun easier to try in new and existing projects.
When will communications beyond the proprietary Discord be opened up to something FOSS & trustworthy for folks concerned about privacy or under sanctions?
IRC is very low bandwidth & offers the minimal requirements for communication which can be accessible/acceptable for many projects. If something heavier is needed or wanted, XMPP MUCs & Matrix Spaces may be a good option since they are federated & decentralized (although Matrix has unfortunate defacto centralization around Matrix.org, because it requires quite a lot of resources to self-host in both the Python server as well as mirroring all content for all users for its take on federation). Mattermost & Zulip are fine, but require an account (I believe) to the central server but are FOSS & used enough places to be considered stable/trustworthy.
All options can by bridged to all other options (even the proprietary ones) in some manner, but if possible, the defacto server would be FOSS & owned/operated by the community so that that community can define their ToS and/or CoC. This way they are in control of the community rather than requiring users agree to someone else’s—especially a for-profit US corporation’s—terms in order to participate. Some users will want privacy, anonymity, control of personal data, or to get around a firewall/sanctions …and these desires should be considered acceptable. If not self-hosted (requires time/money), it’s still better to choose something using open protocols, like a space on Matrix.org, a big chatroom on XMPP’s Blabber/Conversations, Libera.Chat/OFTC, etc.
I'd second the recommendation for Zulip. It's pretty similar to Slack/Discord, but unlike those it has good support for making the archives public. It also has much better threading support, which is a nice bonus.
It’s expensive to self-host, and centralized if using Matrix.org. It has its uses, but XMPP MUCs have a lot of overlapping features & Prosody/ejabbard can run on a potato by comparison.
It might be expensive for an organization to host, but for individual / small groups it can be as low as $6/mo. I've been running a small Matrix server on a DigitalOcean droplet for years now, and the $6/mo plan has been working fine for 5 users, and three bridges running on that server.
I believe all messages/multimedia from all users & the history all the rooms & private messages need to be mirrored which can end up being a lot even with a few users depending on what they’ve joined. If my understand is wrong tho, I’d like to know so I’m not running around with this notion.
I really like this project and will have to try it at work.
I'm a bit curious how the oven-sh will make money in the long term. It looks like you are getting funding at the minute, but at some point will users need to pay for this tooling?
> Oven will provide incredibly fast serverless hosting & continuous integration for backend & frontend JavaScript apps — and it will be powered by Bun.
Does Bun have a built-in DOM Parser? In Nodejs it's horrendously slow using JSDOM and Linkedom is a great effort but still about 20x slower than a browser. Keep up the good work Jarred.
The closest thing we have builtin is HTMLRewriter, which is more of a tool for transforming HTML than for traversing.
I have looked a bunch of times at how hard it’d be to import the DOM APIs from WebKit/Safari and would really love to if it didn’t also mean pulling in most of a web browser
I think happy-dom is good for DOM-like testing though.
Thanks HTMLRewriter actually fits my use case perfectly. I don't need canvas and complicated stuff like that. Just the ability to parse some html and strip out certain things.
Tried the latest version. Axios is broken. But that's an improvement from the last time I tried to run one of my backends. I'll keep an eye on your progress.
Expecting SvelteKit & SolidStart end of next week. Maybe Next 13 in two weeks. A lot of frameworks work today in the release builds, it’s the dev servers which are harder for us right now.
