00:00 Bun is here00:31 porting to Bun01:05 log import perf02:40 MariaDB perf03:21 reporting perf03:50 bun install on dev06:14 macOS disk usage06:37 bun insta...
In my opinion, any advancement is worthwhile, even if current consensus is that it’s over-optimization. And if it starts tying up its loose ends, it’ll no doubt benefit node developers as well. Healthy competition and all that.
I’m with you on that. I’ve built dozens and dozens of node apps both professionally and for personal projects and yeah maybe the package installs could be faster, but the overall performance of the server has also been pretty good. If node is slow for you, maybe there’s some other optimizations to be made rather than switching the next new things as a solution.
I guess I don’t understand this obsession with speed? I work in development but I have never ran into a build that’s so slow that it impacts my work. Why is Node considered so bad that everyone wants to make is faster?
I guess I don’t understand this obsession with speed?
for me it hasn’t been build speed but rather execution
I’ve run into problems with dayjs slowing down requests where I need to do a lot of processing. There are arguments to be made about replacing dayjs with datefns and how I should’ve been doing it differently anyway, but fact is that if the whole execution environment was twice as fast, it probably wouldn’t have been much of a problem at all
because speed = your page loading fast = more clients = more satisfied clients = less environmental impact = less build time = less time downloading and lock-ing modules = more time for you … the list goes on.
I dont understand why is it so hard to understand that … guys … speed … does … matter? Our time matters? Our anything matters? And if you dont care, I do.
I’m with the parent poster. How often is it hindering your work?
It’s at tops, a 15-30 second wait, usually done at the start of the project.
I’m a unique use ase, where I have about 10 projects (because microservices) that I’d have to npm install, and it’s still not a pain to install them.
Are people running npm install dozens of times a week on the same project? Because why?
I’m not shitting on Bun. I’m actually supporting it’s growth. But until it solves some real performance bottlenecks, (switching from gulp/webpack to vite changed our compiling time from 18 seconds to 2 seconds), I can’t see any reason for people to change their workflow.
Hmm, npm can take up to five minutes for me. I usually just leave it alone and go do other stuff. And I have fiber internet, so it’s not download speed that’s the problem.
First: it can be a lot longer than 15-30s. One project I work on takes around 90s for a fresh install. This used to be worse in older versions of npm, and it’s worse on Windows.
Second: it also affects things like CI/CD. I prefer using Yarn 2+ for that reason (all dependencies are stored as part of your repo). It might not sound like much, but 30 extra seconds does decrease your productivity more than you might think if you have to wait for it every single time.
Build times in nodejs are not so great in even medium size projects if you make heavy usage of advanced typescript features - either yourself or through libraries like zod. So if something makes the nodejs runtime faster, it could potentially make ts compiler faster too - for which I’d be very grateful.
Pretty much. Their benchmarks seem to be VERY cherry picked to skew things in their favour, specially the testing framework part, where bun compares its speed to one of the slowest testing frameworks out there (jest) and claim victory.
I’m very glad that this guy actually made benchmarks instead of just reading what’s on bun’s site before posting a video about it.
Recently change node+npm+esbuild to bun runtime+package management+bundling and happy with the result.
The project is a static site built with middleman, tailwind, postcss and some frontend libraries.
It was simpler to work with for me. Node is way faster than ruby and so node speed was never an issue for me. But bun install is noticeably faster even for a small project.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
deleted by creator
Am I wrong to think that if you are REALLY crippled by the “slow speed” of node, you just shouldn’t be using JS from the beginning?
In my opinion, any advancement is worthwhile, even if current consensus is that it’s over-optimization. And if it starts tying up its loose ends, it’ll no doubt benefit node developers as well. Healthy competition and all that.
I’m with you on that. I’ve built dozens and dozens of node apps both professionally and for personal projects and yeah maybe the package installs could be faster, but the overall performance of the server has also been pretty good. If node is slow for you, maybe there’s some other optimizations to be made rather than switching the next new things as a solution.
I guess I don’t understand this obsession with speed? I work in development but I have never ran into a build that’s so slow that it impacts my work. Why is Node considered so bad that everyone wants to make is faster?
I don’t understand it either.
I’ve only had issues with npm speeds when the projects were stored in a HDD, and that’s not node’s fault.
for me it hasn’t been build speed but rather execution
I’ve run into problems with dayjs slowing down requests where I need to do a lot of processing. There are arguments to be made about replacing dayjs with datefns and how I should’ve been doing it differently anyway, but fact is that if the whole execution environment was twice as fast, it probably wouldn’t have been much of a problem at all
because speed = your page loading fast = more clients = more satisfied clients = less environmental impact = less build time = less time downloading and lock-ing modules = more time for you … the list goes on.
I dont understand why is it so hard to understand that … guys … speed … does … matter? Our time matters? Our anything matters? And if you dont care, I do.
You’ve never had an issue with how slow npm installs?
I’m with the parent poster. How often is it hindering your work?
It’s at tops, a 15-30 second wait, usually done at the start of the project.
I’m a unique use ase, where I have about 10 projects (because microservices) that I’d have to npm install, and it’s still not a pain to install them.
Are people running npm install dozens of times a week on the same project? Because why?
I’m not shitting on Bun. I’m actually supporting it’s growth. But until it solves some real performance bottlenecks, (switching from gulp/webpack to vite changed our compiling time from 18 seconds to 2 seconds), I can’t see any reason for people to change their workflow.
Hmm, npm can take up to five minutes for me. I usually just leave it alone and go do other stuff. And I have fiber internet, so it’s not download speed that’s the problem.
Webpack takes 10 minutes to build the release bundle in a project at work…
First: it can be a lot longer than 15-30s. One project I work on takes around 90s for a fresh install. This used to be worse in older versions of npm, and it’s worse on Windows.
Second: it also affects things like CI/CD. I prefer using Yarn 2+ for that reason (all dependencies are stored as part of your repo). It might not sound like much, but 30 extra seconds does decrease your productivity more than you might think if you have to wait for it every single time.
Ugh as a system developer I’m happy when compiling anything takes less than 5min
Build times in nodejs are not so great in even medium size projects if you make heavy usage of advanced typescript features - either yourself or through libraries like zod. So if something makes the nodejs runtime faster, it could potentially make ts compiler faster too - for which I’d be very grateful.
Bun no good => ☹️
Don’t have to learn another shiny JS thing => 😀
exactly me right now.
So, Bun claiming to be faster than Node is bull****, basically.
Pretty much. Their benchmarks seem to be VERY cherry picked to skew things in their favour, specially the testing framework part, where bun compares its speed to one of the slowest testing frameworks out there (jest) and claim victory.
I’m very glad that this guy actually made benchmarks instead of just reading what’s on bun’s site before posting a video about it.
I guess you could call it, a bun(ch) of trash.
Or perhaps, it’s all complete bun-shit.
sorry
Style points for the a-bun-dance of puns.
debunked
Not at every turn though. Also it runs on Webkit instead of Googles V8 :)
Bun is blazingly faster than node*
*As a package manager
Recently change node+npm+esbuild to bun runtime+package management+bundling and happy with the result.
The project is a static site built with middleman, tailwind, postcss and some frontend libraries.
It was simpler to work with for me. Node is way faster than ruby and so node speed was never an issue for me. But bun install is noticeably faster even for a small project.
This is mildly off topic, but is that thumbnail an Animorphs reference?
damn you for making me notice, but it totally is…