Bun Catching Flak -- Node Getting Angry | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Reviewed Tweets (in order):
- x.com/jessfraz...
Posted by: Jessie Frazelle - @jessfraz
- x.com/matteoco...
Response by: Matteo Collina - @matteocollina
- x.com/var_epsi...
Posted by: Varepsilon - @var_epsilon
- x.com/thdxr/st...
Posted by: Dax - @thdxr
- / 1701207022073491933
Posted by: Cory House - @housecor
- x.com/youyuxi/...
Response by: Evan You - @youyuxi
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/dee...

[@samuelschwager]

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.

[@ThePrimeTimeagen]

agreed

[@rand0mtv660]

@@Microphunktv-jb3kj it matters in CI/CD. You can get faster feedback in CI/CD which in turn can give developers faster feedback during work. I don't mind "free performance" to be honest.

[@phoenix-tt]

​@@Microphunktv-jb3kj Adding to comment above, the difference is WAY WORSE in CI/CD. On my work the project builds in ~4 seconds on a local PC, while building ~30 seconds on a CI runner. The packages also install in 20 seconds locally compared to 1.5 mins on CI. I would certainly use Bun in CI instead when it gets more mature and gets to the major package managers.

[@phazechange3345]

It's actually even worse. When you're new and coming in to JS, it's extremely difficult to know anything about the build stack. All of the "hello world" blogs use different build stacks. None of them explain what each component of the build stack is. Not even each component of the build stack explains itself what its role is in the build stack when you visit their websites. And then, you try to move on from "hello world" and you have no clue what any of these things do, or how they interact, or why, and because all of the blogs use different things, you have to piece together different parts of different blogs and it's an absolute disaster. The necessary result of "best of breed" build stacks is that your web presence for newbies becomes untenable.

[@MelroyvandenBerg]

Agreed

[@alexaustin6961]

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.

[@ThePrimeTimeagen]

its funny how much of a pain in the ass it is but at the same time it was "the standard"

[@dickheadrecs]

@@ThePrimeTimeageninnovation is just the recontexualization of pain

[@kelvinabambora9]

​@@dickheadrecs This line is so unnecessarily metal af 😂

[@dickheadrecs]

@@kelvinabambora9 🤟😵‍💫🤟

[@advanceringnewholder]

It's fun and dandy writing in rust until you need linking c/c++ library

[@LaPingvino]

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.

[@oleksiistri8429]

True, instead installing and managing whole ecosystem -it is much easier to install one thing and be done with it. Also different tools of different versions can have higher chance of incompatibility issues

[@Scereye]

They had me at "ESM & CommonJS compatibility" ... That paragraph alone made me try out Bun...

[@HrHaakon]

So what you're saying, is that soon people will jump ship to JSPs again? (I'm joking, please don't hire dark web assassins to murder me.)

[@SaHaRaSquad]

Exactly. I don't understand how anyone who worked on a decently sized web dev project could be against simplification. The Turing-complete Rube Goldberg mess of tools you have to combine and get working just to build some projects is insane.

[@steph5726]

@@SaHaRaSquad Job safety and the classic WADITW The senior full stack template guy is also at fault in most case (Just clone that git repo, npm install and drag in 200+ deps and modify it to suit the use case)

[@PorthoGamesBR]

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.

[@TheDuckPox]

But also more speed does not always equal to less security. You can be insecure and slow or secure and fast at the same time.

[@emilemil1]

If you need maximum processing speed you shouldn't be using Node, Bun, or anything based on JavaScript in the first place. However build times always matters, and companies can lose a lot of money when their bugfixes are held back by hours of pipelines.

[@pianissimo7121]

​@@TheDuckPoxu r true but i think he meant they spent more time on security then performance. Thus security vs performance. Obviously they can have both but that requires more resources they don't have apparently

[@danielsan901998]

If you have a business is more efficient to pay for a C++ programmer to rewrite the application in C++ that paying for a C++ programmer to improve a huge ecosystem like node.

[@huge_letters]

I think their argument was more along the lines of "AWS can charge you more if your lambdas run slower. So why would they need Bun?"

[@ristekostadinov2820]

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

[@alanboody7004]

It's a amazing what a team can accomplish when they're being paid vs. voluntary. Don't get me wrong, I like open source and voluntary code contribution, but you still need to dedicate the bulk of your time to income to pay bills.

[@matthewrideout2677]

@@alanboody7004 The people paying for bun development aren't doing it as charity, it remains to be seen how they expect to tie this into revenue and if it will remain a good option for people that don't want to run proprietary monthly services in order to utilize all features. Like vercel requiring you to use their hosting to properly manage cache with app router.

[@unowenwasholo]

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

[@ThePrimeTimeagen]

facts

[@MungeParty]

I think it was a lot worse than that though. Okay hear me out, what's more pathetic: A) not going out of your way in your free time to prove something about some work topic from your work, or B) refusing to even entertain the notion of taking time to measure the quality of something that you spend all of your spare time doing? The first one you could maybe say is like a cop out, but the latter is just completely and utterly humiliating..

[@saymehname]

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

[@katiefincher2433]

lol "better". I'm sorry, is programming HARD? Lets re-invent the wheel yet again so you poor princesses don't have to think so much.

[@RalakFrozenDeath]

@@katiefincher2433 Programming has been about abstractions since the get-go. "Re-inventing the wheel" lmao.

[@VuTuanIT]

@@katiefincher2433 reinvent the wheel lol, say to the author of Node. Bun team don’t reinvent the wheel, they invent a new better kind of wheel

[@SiisKolkytEuroo]

Nothing in the current software stack even remotely resembles anything as timeless as "the wheel"

[@ilearncode7365]

This is usually not the case (that the new and different way is ‘better’)

[@jayshartzer844]

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

[@ThePrimeTimeagen]

its... the inevitable

[@aziemelzapratama5257]

man, they are talking about us like we are some caveman shit lol

[@Wellington-je9nx]

@@aziemelzapratama5257but are they wrong

[@tonyhart2744]

@@aziemelzapratama5257 because its true

[@Winnetou17]

@@aziemelzapratama5257 wait... we're not ?

[@khangle6872]

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

[@FraggleH]

You beat me to it - literally my first foray into working with a node project failed because my node version was too new.

[@demystifyingdev]

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?

[@dickheadrecs]

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

[@ThePrimeTimeagen]

-69 seconds

[@LarsRyeJeppesen]

Now Angular is even faster than React.

[@gabriel55671]

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

[@videoguy640]

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

[@ThePrimeTimeagen]

its not a bad point

[@ameer6168]

but they are getting benefit indirectly because company will hire them on the basis of their contributions

[@MrSquishles]

@@ameer6168 it's a repeated song and dance with open source devs complaining about needing a day job, that apparently does not happen nearly as much as it should.

[@luckerooni1153]

@@MrSquishles because in the end they want to be a passionate suffering artist but also want attention on the internet for their struggle instead of doing what everyone in FAANG does which is grind your ass off to be able to say you worked for FAANG on your resume then work almost where ever you want because people assume you're a genius. the same is true of contributing to open source code bases that matter. these guys wanna be billionaires who have unlimited free time while they also don't charge anyone any money for products and also have no external funding. you can't help but call it naive.

[@reinoob]

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

[@ynokenty]

And actually run those things faster than Node does!

[@bearwolffish]

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

[@random_bit]

Why would they be on Node thooo

[@gadgetboyplaysmc]

I get your point lmao but no one would be building those apps on Node

[@JosifovGjorgi]

and all CPU engineers

[@SaHaRaSquad]

At least Node wouldn't lose them 400 million in an hour

[@phoenix-tt]

@@SaHaRaSquad That would take Node about a couple months. But it'd probably just run out of memory in the first 10 minutes anyways

[@Muaahaa]

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

[@rikgirbes7911]

Same here unfortunately. Lots of issues are created at then moment on github. So to be honest its not production ready, at all. (Yet) I think in a few months though, when these issues are resolved, it should be good to go…

[@arden6725]

You sure about that? Bun uses node to run scripts by default unless you do bun run --bun

[@soulsearch7383]

@@arden6725 same happens to me. Script won’t even run after build. No even bun can run it.

[@Muaahaa]

@@arden6725Yeah, I was able to run the script without `--bun` but it would fail when I used the `--bun/-b` flag.

[@filipjnc]

⁠@arden6725 So why would I use bun if it runs node?

[@jengstrm2]

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.

[@ccj2]

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.

[@awesomedavid2012]

Absolutely. It's an admittance of their own failure

[@Spookyhoobster]

I think that's a little unfair. "Real evidence" in the software space is incredibly hard to both generate and verify. Nothing would get done if we all took the time to properly explain why do what we do. This is a great video that really opened my eyes on how complicated this stuff can get: kzbin.info/www/bejne/qF63fYZ4ma2YZ6M

[@deaddevil7]

There is another alternative: they viscerally hate the opposition.

[@glowingone1774]

cope out, you cant even explain it, and linked us to a video@@Spookyhoobster

[@xen2297]

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

[@sreeramambalam5041]

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

[@tpadilha84]

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

[@rapzid3536]

esbuild is so 2020. 2023 is the year of SWC.

[@sub-harmonik]

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

[@RenderingUser]

Well to be fair, there's probably some wizards that could build a library to parse that in On-1 time Lmao You _could_ do standard split() for everything, but it might end up being slow. Costed 200ms for me once

[@PwrXenon]

You either include it in std lib or deal with the dependency hell leaving it to the community becomes

[@sub-harmonik]

@@RenderingUser youtube isn't letting me post the link I guess, but checking out the one that claims to be fastest: it seems like rolling your own would not be that difficult and would probably be the same speed if not faster. heck even using split might be faster than theirs. But you don't have to use split.. Especially since the library version has to support options which add overhead, and if using it for a specific application you know what format to convert it to directly.

[@Yay295]

CSV values can contain commas, so you can't just split on all commas. It's still not too complicated, but there's a bit more to it than just that.

[@sub-harmonik]

​@@Yay295 yeah afaict those values have to be quoted. It's probably good enough to have a flipping boolean that keeps track of whether the current character is quoted. Then just copy the tokens/parse at every comma or newline/EOF.

[@rifatsimoom]

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.

[@Spiun666]

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.

[@_evillevi]

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

[@metropolis10]

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)

[@Varstahl]

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.

[@catcatcatcatcatcatcatcatcatca]

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.

[@LaPingvino]

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.

[@diadetediotedio6918]

I don't think this is quite exactly accurate, because "easier" or "harder" appears to be much more a matter of experience in this case. And I'm still thinking if it is not the case that the main performance benefits of bun comes not from zig itself but from the JavaScript engine they are using behind.

[@Fiercesoulking]

I'm kinda forced to use c++ after a long time. Its an OO language but without all the the OO stuff other languages have. Not only the split in 2 files for definition and declaration which cause confusion because it is not just always like this. The other problem is all OO languages strictly bind to the var name of an object a reference meaning an implicate pointer. When you return an object in C++ you get a shallow copy instead aaaargh. I know this is to avoid a memory leak but this makes it so that C++ functions under certain circumstances aren't in the mathematically definition of a function. Even if its not Zig C++ needs a replacement.

[@LaPingvino]

@@diadetediotedio6918 I think a good part is the JavaScript engine, but take note that they explicitly point out warmup times etc in their tests. A big part is being more efficient, and Zig basically steers you to be efficient at every step.

[@atiedebee1020]

​@@Fiercesoulkingi don't agree that C++ is an OO language. Its multi paradigm. It's the user's choice to do OOP or not

[@oleksiistri8429]

​​​​​@@Fiercesoulkingyou are just not experienced enough in C++. C++ has the most comprehensive and versatile OOP you can find out there, but yeah it can be very tricky sometimes. And this is done not to prevent memory leak, it is just how c++ mechanisms and syntax work, you need to learn how to do it properly. I understand your frustration coming from higher level language where everything is an object, even integer sometimes, lol.

[@vsolyomi]

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

[@GoalieSave25]

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

[@nomadshiba]

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.

[@NeoChromer]

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

[@Makeshitjusbecuz]

Same doesnt work with my app either

[@LaPingvino]

skill issue

[@JonLauridsen]

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

[@CyberDork34]

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

[@stxnw]

"Only this one thing should be fast, everything else can be slow because it definitely won't matter in the future!"

[@avi7278]

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

[@ThePrimeTimeagen]

i would play this one safe and wait for society to catch up, those dregs

[@avi7278]

@@ThePrimeTimeagen but I like big ports and I cannot lie

[@RolandAyala]

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.

[@MerkieAE]

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

[@dferg]

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.

[@yaksher]

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

[@tomu_sange]

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

[@MrSquishles]

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.

[@verrigo]

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?

[@_nom_]

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.

[@connorallen162]

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

[@jarredsumner5983]

sorry about this, can you file bugs? there are > 1400 issues but I promise we do look at them

[@connorallen162]

When I have more time to put into this I might write a medium article documenting my Bun swapover @@jarredsumner5983

[@jonesbbq307]

Idk if other people have asked this but I have to know. Why do you seem to intentionally left out the first and last characters when highlighting text?

[@alexlowe2054]

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.

[@nexovec]

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

[@falven]

21:50 this guy has never heard of containers

[@samcalder6946]

Best stack = the BASTARD stack Bun Astro Solid Tailwind Aurora Route53 Drizzle

[@ThePrimeTimeagen]

get that drizzle in there

[@samcalder6946]

Throw in a few more just so we can go for the full FAT BASTARD Fargate Auth0 TRPC

[@gadgetboyplaysmc]

@@samcalder6946Actually turn this into a real idea lmfao

[@alanhoff89]

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

[@thekwoka4707]

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

[@MCasterAnd]

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

[@exapsy]

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

[@dvhh]

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

[@philbushman9744]

Love these videos, big ups Todd 🍻

[@MrEnsiferum77]

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

[@manaslovesbirds]

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?

[@neonraytracer8846]

Stuff doesn't get deprecated that often, but the biggest argument is the ecosystem. One rarely needs to spend weeks or months building and testing a specific feature, because it already exists. Using JavaScript is generally a minus, but a little one until one need to serve millions of requests a day. It's not that big of a deal, and yes, it's easier to recruit for.

[@ShadowKestrel]

developers fresh out of coding bootcamp come a dime a dozen and only speak JS. Also, sometimes the decision-making engineers are just too lazy themselves to learn another language - why use something like go when "the supreme arsenal of footguns" (js) works

[@barreltitor1419]

sharing code between frontend and backend, and unfortunately a lot of AWS CDK packages are first class for Node and as you said, it's easier and cheaper to hire a fullstack dev than doing it right - world is just lazy and incompetent 🫨 there's also heaps of C# and Java devs which are both heavy and terrible in the world of Kubernetes and Cloud but unfortunately a lot businesses and devs are stuck with its existing toolchain.

[@jordanwright3052]

Easy to learn/train, asynchronous model makes sense for a lot of applications, huge ecosystem (plus, I feel like the docs for js stuff is better about providing good examples, pretty rare any decently sized package is gonna leave you stranded with a smorgasbord of function signatures with little explaining).

[@chienvu8144]

For small companies, it is not only just easier to recruit freshers but also fast to build since Python/JS have a huge community behind them. By the time you finish building your ideal application in Spring, probably you will see thousands of same applications floating in the market with lower quality. In business world, it's a huge factor to have your idea available asap.

[@monad_tcp]

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.

[@SM-ok3sz]

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.

[@MrAlanCristhian]

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

[@rotimibest8530]

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

[@ThePrimeTimeagen]

This may mean more than you realize

[@rotimibest8530]

@@ThePrimeTimeagen What do you mean?

[@0xCAFEF00D]

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.

[@PanosPitsi]

They mean to say more performance isn’t worth their inconvenience

[@Lemmy4555]

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.

[@echobucket]

Apple has been claiming for years that JavaScript in Safari is faster than V8... are the performance changes based on the difference between JavaScriptCore and V8?

[@MetroidChild]

Mainly I think its the lower latency to execute which makes user side scripts snappier.

[@richardchester2675]

"Have you seen our URL parser" LMAO

[@thekwoka4707]

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

[@bdidue6998]

Why do you think he didn't provide any benchmarks?

[@tylerlwsmith]

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

[@MungeParty]

The what if bun goes away argument is an argument against respecting yourself. It's like a Stockholm perspective, I don't want to fall in love cuz what if she breaks my heart. Nah you can just like not spend a million years fussing around with bundlers though in the meantime, what's the worst thing that happens? Go back to needing to spend time figuring out bundling? And like what is this scenario where overnight the bundler stops working in a way that there's some urgent crisis to change bundlers so quickly? There is no such crisis even possible, I defy anybody to describe such a scenario.

[@rand0mtv660]

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

[@random_bit]

Honestly, I wanna know what type of pitch he made to get that VC 😂 Poor investor in for a rude awakening when they find out package management is an unpaid service mostly

[@rand0mtv660]

@@random_bit they will probably create a deploy service like Deno has Deno Deploy. I don't see any option at the moment other than creating "Vercel for Bun" basically which would be the fastest and best environment to deploy your Bun applications in.

[@Winnetou17]

If the money weren't involved in why it's fast or in why it gets the results it gets... then the need for a VC then ? I think you're confusing scope here.

[@random_bit]

@@Winnetou17 Everyone needs money to survive, the VC funding was done to pay for the development time spent on Bun, why else would you need $$$ ? Do you think software gets written magically by people full-time while they don't get paid?

[@rand0mtv660]

@@Winnetou17 I'm just saying that people use that as an argument in a wrong way.

[@LarsRyeJeppesen]

The biggest issue with Bun imho, is that it's dependent on 1 person only. Are you betting your entire business on something developed by 1 person? What if he's hit by a bus tomorrow?

[@nrwchd]

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.

[@lainwired3946]

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

[@steamer2k319]

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.

[@MetroidChild]

Remember that time spent having to find appropriate libraries, compiling code, and debugging is time not spent optimizing the end-user experience, what does it matter if you run fast if you can't make it to the track?

[@steamer2k319]

@@MetroidChild Fair enough and I did already mention that the interest in developer experience is warranted. That's not to say that those things are impossible with Node. You mostly just have to know you're doing (which often comes from experience in being burned). Once you're familiar with a few good libraries and tools, you can totally focus on the problem domain--better than with most other tools. People like to complain, though, and good thing they do because: 1) Removing attention from outdated tooling makes it easier to find/learn the better stuff 2) Even great tools can be made greaterer

[@SimonBuchanNz]

pnpm install vite, pnpm vite, pnpm vite build. Wow, so hard. We had a real rough time for a while with esm interop, but we seem to mostly be past that now, or at least it has already peaked. If you're greenfield, then you can pretty much just go pure esm with your packages. Rollup used to have trouble with legacy commonjs, now it's fine with everything. Not to mention, Deno has been out for a while, with most of the same claims, and can actually promise that it's not adding a crapload of memory issues given it's written in Rust. Why should I be so excited again?

[@MetroidChild]

@@steamer2k319 Your second point here is the most important, there is no reason Node couldn't make deals with 3rd parties to co-bundle the most robust and performant core libraries/services, or absorb the teams if possible. This is common practice for many other open source projects.

[@xerostyle]

that's been my favorite outro yet

[@bdidue6998]

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

[@julianavar3836]

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.

[@ttdat89]

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

[@betterinbooks]

you're getting tearing when something changes really fast. why aren't you using picom or another compositor?

[@ycombine1053]

I'll trade a url parser for actually solving modules any day of the week

[@cotneit]

I feel like even if Bun team disappears people will much more readily contribute to it because it's written in Zig instead of C++

[@doctorgears9358]

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

[@paulsoukup6872]

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

[@ShadoFXPerino]

Node isn't backwards compatible either lol, 20.6.0 breaks my Apollo GraphQL gateway setup

[@ThePrimeTimeagen]

hah that is pretty good

[@hugosmar]

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

[@ugopalatucci]

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?

[@RocketLR]

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.

[@zperk13]

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

[@falven]

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.

[@273MICKO]

correct me if i am wrong, Python technically an open source with "Dictactorship govern" group right?

[@ea_naseer]

benevolent dictator

[@fennecbesixdouze1794]

The benchmarks Bun presented are incredibly dishonest. This is supposed to be a runtime, i.e. it's supposed to replace Node, but they spend most of their time in the video comparing bun to npm/pnpm/yarn, which are just package managers for node not the runtime. Then when they finally go to comparing the runtimes, they include the time running in the package manager in order to skew the results. Maybe Bun is much faster, but the stats they presented were so clearly and deliberately dishonest at this point I have a rotten taste in my mouth about the whole project. I suppose the VC money pushed them to this level of dishonesty?

[@bigfishoutofwater3135]

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

[@ivolol]

"Can one small team support something this complex long term?" is a massive middle finger to all the tiny teams (mostly countable on a hand with some fingers blown off) that have supported some monumentally important FOSS projects for decades now. Most of which also aren't VC backed.

[@teamgartz-motorsports6881]

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.

[@michaelutech4786]

How many people did it take to fail with Multics, how many developed UNIX? It's not a question of numbers.

[@Kane0123]

Two things: 1. “I don’t know nuthin”… seems suss 2. What’s the path to profitability for a business like Oven? Why would a VC invest?

[@NatoBoram]

"Bun kept segfaulting on me" Me too, Prime. Me too. But today, Bun is amazing!

[@limpiadora]

Remember kids: bun is still JavaScript

[@UODZU-P]

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

[@mad_fresc4842]

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.