choosing and maintaining a "best of breed stack" is what wastes a lot of time devs would rather spend developing software. so bun is a huge win in that area.

In university we were largely taught C/C++ to begin with, and when I first started web development I was very excited with how much easier Node was compared to copy-pasting random header files and constantly updating my Makefile. Any inconvenience or stupid thing that Node did was excusable because my lazy ass still thought it was better than Make, and I thought that all things wrong with it were just normal things of package managers. When I first transitioned into Go and Rust from there I was amazed at how much easier it was to manage dependencies and build projects. Want to run your code? "go run ." In a matter of minutes I completely became uninterested with the JS ecosystem and having to navigate a spiderverse of dependencies that all do the same thing except give me different 200 line compiler errors that don't fit in the browser.

About why people are excited about bun, I think even with that big performance dunk, that's not the reason people will jump ship. The reason imho you cannot win against what bun does is that they make the ecosystem simpler. If it doesn't work 100% of the time, but it works for your cases, that's a win. Any time you can significantly simplify your toolchain, that's not a small thing. Any time you can do more work in less time and with less thinking, that's a huge win.

Jared really busted his ass, i remember last year hearing about Bun and in like a year or year and a half here we are 1.0 full blown ecosystem

1:13 "Making things faster does not make anyone more money" Oh yeah, because if my monetization is based on ammount of requests (like chatGPT and a lot of APIs), being capable of handling 10 request per second vs 100 per second will not change anything. Yes, some business need more security, but some business need more speed.

7:42 Ah yes, the "Unfortunately I am unable to do this at the moment, but I'll put it in the backlog and will circle back when I get to it." in lieu of what we actually mean which is "I won't do this. Go away."

I let my fellow mobile devs know about the whole bun vs node thing and the general response was "web heads fighting over yet another framework is not news" lol

Old man gets mad at young man who does it differently but better

The most funny thing is node claims about backwards compatibility, you update to the most minor version possible and all your app and their grandmother breaks lol

tbh even if Bun crash and burns having something that lets me code right away instead of messing with unrelated tools and config files will help A LOT with prototyping and testing

Best point: why npm doesn't fix the performance issues. This goes to show that npm (which fired a bunch of employees for trying to unionize a while back) is completely inoperative as a company. Bun is simply filling a gap that never would arise otherwise. So all the arguments about not using Bun because what if it fails are out of it, because it is npm that has failed, and Bun is filling that space. Who is the most stable now, then?

I appreciate Yagiz's honesty and bluntness about being not paid lol

how fast will bun turn my react into svelte? asking for a friend

Bun is a runtime my dude, it can still run your webpacks, babels, and all your favorite bloat

If your project doesn’t crash and has better benchmarks on Bun as is my experience, then it’s great. Im sure it will take time to work out all the corner cases.

Bun was definitely not a drop in replacement for the project I tried using it with. Issues with lifecycles and I couldn't run build script successfully with it (runtime errors).

"Making things faster does not make anyone more money" ... High frequency market makers have left the chat.

I’ve come to understand that if people don’t want to prove their point in some way and just want to argue and refute without evidence, it’s because they know they’re wrong or have very little belief in their own stance, and don’t want to face having to admit it.

22:18 One thing I know of is Bun's "prop punning" of JSX. Which is incompatible with the JSX spec afaik.

In regards to "bun not catching up to bundlers innovation": Bun's bundler is compatible with esbuild and supports its plugins.

I like the flak catching part of hype, that's how real tech is made, by testing it in the fire 🔥

27:56 man I'm so excited to run my PHP on HHVM. It's way faster than the PHP Interpreter, it's backed by a company with infinity dollars. It's production ready and used by a large project. What could go wrong with my decision to spend time and money switching all my tooling to it right? It's going to be here for years to come! Oh wait, I'm excited to run my JS on Bun instead of Node. That's the risk, it could pay off, it could replace it, or it could just be the fire that lights under their ass and gets them to shape up and then everyone is like great, no need to switch now. also see: yarn (which explicitly stated they were just a fire IIRC)

I am learning about programming, life, and comedy from this man. I love this man. I don't understand so much tech stuff but I love this man and trying to have a grasp on those.

Funny that you ask if Corey House uses any MS tools. He's the author of "Setup your whole dev environment in VSCode" course. The Course, in a way :))

About Zig vs C++ speed, I think it's the same issue you mentioned with Rust vs Go: Zig makes it easier to write the faster code, with C++ you need a lot more effort to get there.

Where do you all position deno in this? Similar solutions (unified build tools, etc.), perf. seems practically similar (bun wins but not exactly night-and-day territory)?

The idea of innovating basic language features is the worst aspect of JS and node. I really hope the community will not develop extension on bun, because that would add the endless collection of single-fail failurepoints back into it. If you had to secure something with a single chain link, or ten chain links that are equal in diameter, which approach would be safer? Even if nine of those chain links were superior to the one, they would still only degrade reliability. One actually funded team can achieve good reliability much easier than a collection of independent volunteers. Even if their product didn’t do Z or Y as well as a new, small project does, that difference is usually outweighed by the risk of adding one more small team to the list of developers your development depends on.

Bun is incompatible with any node projects that use decorator based dependency injection (e.g. NestJS). This is due to lack of support for emitDecoratorMetadata. The author of esbuild, which is the code where Bun's compiler port originates doesn't intend to support that feature. Not sure if Bun will do that.

Love these videos, big ups Todd 🍻

@23:30 I haven't looked into them much, but the macros appear to just be compile-time functions. The closest analog I can think of to what they do, as I understand, is Rust const functions, except that they are limited to being evaluated at bundle-time (and fail if you try to give them arguments not known at bundle-time), unlike Rust const functions which are invoked at compile time if possible and as normal functions otherwise. They just... run a function whose arguments are known at bundle time, serialize the output, and insert it into the AST. It doesn't seem like this has any foot guns, it just provides a nice mechanism for optimizing out code known to be runnable at bundle-time.

thanks prime for shoving some light into this tunnel, coz bun is new to all of us and discovering all of our thoughts and discussing about it is the way to go

I'm stuck with Gulp and the rest, slow compilation times, a dozen different tools, pure pain. Switching to Bun would mean removing a gazillion tools with 7 ultrazillion dependencies that don't even get fully used to compile/transpile, and replace it with ONE tool that does everything, is faster than the competition, and supports hot reloading when I'm troubleshooting, designing, or debugging components. The dude can keep his "best of breed stack": I'm working, I need to have tools that keep up with my pace, not tools that slow me down because they need to maintain compatibility for stuff built in 2004.

ok just check how bun macros work, they dont have seperete syntax or anything it just runs the js fn on build time and inlines the result could be useful for genereting ids, tbh i was looking for something like that for a while, i even looked into using stack trace line and column numbers lol. macros the way bun does it could be really usefull also could be useful for parsing and inlining html`` or css`` or any other tagged template literal normally you had to use plugins for baking and inlining stuff like that you can practically bake and inline anything you want on build time, which could be really useful EDIT: looking into bun API more, its really good.

i came here looking for Prime insulting that node guy but where is it?? did i miss anything

The post from the babel guy answering "Who says? Bun says!" after Yagiz's self own is priceless

Its kind of mean to dunk on people who have a lot more contraints than the bun team has. Doing an entire system rewrite in a trendy, immature language no one on your team has heard of is obviously not on the table if you make contributions to a project like Node.js But also, I think subjectively as an embedded programmer mainly working with C++, most web devs don't really think about performance. This is because, firstly, if you're making a web application, most performance is about optimizing your database solution and queries, something you don't write from scratch, and optimizing the browser's web rendering engine, something you don't control. Finally, people are kind of used to websites being slow. Other than very simple static web pages with no JavaScript or ads, nothing on the web feels "snappy". If your JS application is slow to build, slow to install, and slow to run, it's just one of many slow as balls webapps. So I do think it says something that yes, if you redesign web frameworks and apps specifically with performance in mind, it'll actually go fast

The hibachi shop down the street from me used the GoLang logo in their own logo, they should add the Bun logo now too

aren't csv files just text files with comma separators? a library for parsing that seems a bit 'left pad'y

Isn't every performance increase from any JavaScript runtime negated by any fix against branch prediction attack?

Drop in replacement for node is a bold claim for a 1.0 and I've already hit minor snags, but overall I'm digging bun for being a Swiss army knife (runtime, pkg mgr, "runs" ts files, etc.). The perf claims are impressive but academic from my pov until can be adapted to frameworks like remix. The pkg mngr perf is wow to see in action, but, frankly, shaving seconds off my install time isn't going to change my world -- it's such a small % of where time is spent building stuff. but still, it's wow fast.

For some context, here's how bun plans to make money long-term: "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."

Aw man i loved bower. At the time it really was the only option for client side JS package managing with lots of support

that's been my favorite outro yet

I've tried using bun again recently. There's two issues: built in fetch isn't perfectly drop in and performance is a fair bit slower.

11:21 @ThePrimeTime, your insights on Dax truly brighten my day. It's inspiring to see insightful individuals who can understand experiences without personally undergoing them. I'm from Venezuela.

can you show us how you leak those boxes again?

4:29, yes, what makes the entire node/npm/yarn/webpack thing slow is the freaking 200.000 thousand files, its pure overhead. It could have been coded in python using memory instead of files and it would be faster than having so many files.

I spent 8 hours trying to "drop in" bun as a replacement for node. It was frustrating because for the bits where it did work it was amazingly fast, but the unsupported libraries and (ironically) import syntax issues made it hard to just swap cleanly... hopefully some of these things will get fixed. And the dream of being past all that nonsense is very compelling, but it'll take some work to get there

They make it sound as if, because bun provides a bundler, you’re forced to use it. It just has it. The argument that one tool over many is ridiculous. You use bun where you want to use bun and use whatever you in the other areas.

I am missing something, forgive my ignorance, but what did Prime mean at 22:20 when he said MS charges $100 a month for vs code?

I run benchmark with Node 20, reduce is the same, for loop bun x2 faster. Bun doesn't have backwards compatibility with Node package fs/promise, can't write axios stream to a file, don't know if it doesn't work with anything else. But really excited about Bun

Bun is like a basket of gold, diamond, perl and uranium. You are free to leave that busket on an island 😂

there's room for innovation in the js ecosystem, Vite and esbuild have been a revolution and they still have a lot to improve, svelte is the first major framework that tries to "compile" approach vs serving the whole core in the browser like React and Angular, and there's definitely room to improve there. Maybe in the next years we'll have a bundler that mainly focus on the "svelte" way of serving the assets, or maybe we are going to have a bundler that is able to seamlessly handle js along with another language that compiles in WASM, maybe we are going to have the client in js/WASM and the server in Rust/WASM all under a single framework. I think we actually are 2-3 years away from a new revolution in the whole js ecosystem.

The future of bun is also somewhat dependent on if native module devs support it. If you can't use like sqlite or some other native db drivers I don't see a long lifetime for bun. Also the last drop in replacement for NodeJS with focus on performance was io.js and it barely make it to v1.3 if I remember correctly. I'm defo not switching my NodeJS v18 for no v1.0 bun on a hype ;) let that stuff simmer a bit and check back in a year or so if this is actually useful.

How should i come out to my parents that i identify as a url parser?

A saw a ton of weird benchmarks with bus vs node.. For example: bun's implementation of fs.copy doesn't actually copy the files but instead creates a CoW clone, and that's why it is faster...

"Have you seen our URL parser" LMAO

06:00 Yeah I'm with that. They should ask for the specifics first so they can address it. Technically they are but they're doing it in a way that it seems entirely rhtorical.

NodeJS does NOT have backwards compatibility, at least not between major versions. There's a reason why NVM exists..

25:35 Windows OS have so much legacy code... he is right, but the way how they written at that time with pseudo inheritance, u can't never ever find that kind of machinery of well written code... still to this day i'm amazed of the code...

how is node's budget a problem when so many people use it. Toss them a donotion if you use it and don't want to have to rewrite to bun in 5 years due to speed concerns. Know what's cheaper for a company tossing 5% of your budget with the stipulation of performance improvements, because a rewrite and team retool's a big fucking bill.

Yagliz had a strange point. Bun is almost always faster. Very few things is it even remotely slower. Tested on a bunch of my old Advent of code solutions :)

You are so exciting to watch. I really don’t see anything offensive in all you said. You said the TRUTH, whoever is hurt should go deal with their pain

That intro is fire

Let’s go Prime!!!❤❤❤

Idk what Matteo's point about the not copying deps thing. It's good. Pnpm symlinks and it's good. There is no bad.

Prime you said everything I thought that went through my mind when I read the thread as it unfolded 😂

5:06 OMG Twitch chat golden Kappa. This is so fricking rare.

Wait, they’re using Ada to parse URL’s?

I dont see why we cant have both: The performance option (bun) and the compatibility option (node.js). I'm not sure where deno fits in.

21:50 this guy has never heard of containers

Bun does not work as a drop in replacement at our work app sadly.

I think the core idea at 3:50 was "Although X, Consider Y." It was a rebuttal that although bun has a budget, it's still much cheaper in terms of the human investment. It's not a recommendation that VC backing makes Bun better. Also, the second response from Jessie and Matteo both seemed very reasonable. They seem to broadly agree on the major points.

0:40 Yeah that's kinda surprising though. People who write in languages like JS and python tend to be the people who tell me performance doesn't matter.

I will likely never use Bun but I just like listening to you talk

I've never thought of url parsers being something that needs improvement.

I can’t wait for everyone to move to bun only for them to pull a Docker or Terraform. Watch Bun 2 be subscription based.

After they already took the baton? yeah! 18:35

You could hand a twitter user the Panacea and they would complain that aspirin can’t cure every ailment like the mythical Panacea can.

3:50 I dislike the "Oh it's VC backed" argument because Jarred did a bunch of things for like a year before revealing Bun to the world. As seen at 9:40, he financed himself during that period. Bun was already performant before money was involved so I don't consider that as an argument for why it's fast or why it's able to get the results it gets lol

I like that they bundle a bunch of useful stuff together. For me the opposite of that is what is killing Python, a language that is pretty cool, but it’s a nightmare to get dependencies today, even worse than JS.

He doesn't want to say he doesn't have enough time. He's saying show me the money.

I mean it could be sustainable if Vercel offers them enough money for an acquisition. That seems like the quickest path for sustainability.

Can't wait for update vid

Golden Kapa doesn't work like it used to. They are available for 24 hours as hype train rewards now

this conflict is so similar to Clang and MSVC, usually MSVC take their own time if new standard specification came out, but now days MSVC is always the first one implementing all of standard specifications. competition make everything better.

20:10 Is socket io bad? I've always thought it was good.

I'm curious..why do people use JS on the backend? What are its major advantages (other than ease of hiring devs)? If speed is a concern I'd go with something like Go. If stability is a concern I'd chose Spring framework. Why do businesses chose Node as a backend knowing that APIs get deprecated quite frequently?

I'm just not sure if I should simply use golang instead.

17:50 When the python software foundation make pip more or less usable, i left anaconda and started using pip.

the slowclap became fastclap

If both work and the one is faster im going for the speed boiz

Node is fast where it matters--at runtime, serving end-users. It seems like most of the complaints that Node is taking umbrage over in these threads are actually more directed towards external tooling like npm, webpack, etc. And there's definitely interest in improving developer experience so it's great to see some competition.

I think the best part of this video was when you were clearly scarred by csv parsers so much that you had a purple link on a top 10 csv parsers 2022

If bun is funded, at some point they would like to make money on it. How they will do it? Would they create a subscription plan? Which kind of license would they use? I think they are using this time to be popular and at some point they will change the license to make money… what do you think?

Pnpm also uses symlinks. Giving us a tonne of issue on multi platform teams

Havent developed anything with nodejs for years.. Trying to start a new project and I just ran into error after error trying to initialize the project.... Then i remembered bun and was like "meh lets try it." BOOM, bun just initialized everything super fast and it worked. Im sticking with Bun.

but have you SEEN DAT URL PARSING DAWG?

"maybe websockets will be even easier" that sentence has never been said before

Node vs Bun vs Go