| ▲ | arendtio 4 hours ago |
| Why is there so much buzz around bun? Can't we just go back to node + npm + vitest + vite? |
|
| ▲ | virajk_31 4 hours ago | parent | next [-] |
| Breaking: JavaScript developers create three new frameworks/kits while you were reading this sentence. |
| |
|
| ▲ | andyfleming 4 hours ago | parent | prev | next [-] |
| There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun. https://nubjs.com |
| |
| ▲ | kachnuv_ocasek 4 hours ago | parent [-] | | What are the benefits, though? | | |
| ▲ | christophilus 4 hours ago | parent | next [-] | | With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing… Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps. | |
| ▲ | dhamidi 4 hours ago | parent | prev [-] | | This: node + npm + vitest + vite
Turns into: bun
That's the benefit | | |
| ▲ | stevefan1999 4 hours ago | parent | next [-] | | I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged). I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json | |
| ▲ | Octoth0rpe 4 hours ago | parent | prev | next [-] | | Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph. People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation. Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions) | |
| ▲ | chuckadams 4 hours ago | parent | prev | next [-] | | To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default. | |
| ▲ | 2 hours ago | parent | prev [-] | | [deleted] |
|
|
|
|
| ▲ | root_axis 2 hours ago | parent | prev | next [-] |
| > Can't we just go back to node + npm + vitest + vite? You're kind of stating the reason for the buzz there: one runtime that does everything you need rather than cobbling together a dozen different tools. Not that there's a problem cobbling together different tools made to do a job, each tool has a purpose and solves a problem, but having all problems solved out of the box is very convenient. Bun does offer an additional major advantage, i.e. the bundler has a runtime API, so the same process that serves your assets can also bundle them in memory without having to coordinate an external bundler writing static files to disk. |
|
| ▲ | coldtea 4 hours ago | parent | prev | next [-] |
| >Can't we just go back to node + npm + vitest + vite? The mere enumeration shows how bad it is. |
| |
| ▲ | mnahkies 4 hours ago | parent | next [-] | | I think it's a pretty reasonable split of responsibilities, and not uncommon. Eg: JDK + maven + junit + tomcat Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc) | | |
| ▲ | all2 an hour ago | parent [-] | | Is this the old monolith vs micro-services argument? I guess this boils down to 'how granular and function specific are your building blocks?' and where you draw the lines programmatically: library interfaces in a single program/executable, API/ABI between two or more programs/executables, HTTP API/other transport protocol across network boundaries between two or more programs/executables, and so on. I'm not sure I'm slicing this along the correct abstractions, though. |
| |
| ▲ | tavavex 2 hours ago | parent | prev | next [-] | | Why? Is fewer things always better? How far should it be consolidated? Taking it to an extreme, would having a tool named Everything that does anything you could imagine in relation to web dev be better? | |
| ▲ | arendtio an hour ago | parent | prev [-] | | Well, do one thing an one thing good as in Unix philosophy? - Runtime - Package manager - Test runner - Build tool |
|
|
| ▲ | rapind 4 hours ago | parent | prev | next [-] |
| At this point, I'm not sure anyone should still be using npm. |
| |
| ▲ | quantummagic 3 hours ago | parent | next [-] | | Seriously. The only way to use it is to be a very religious person. You have to pray every single time you use it that your system doesn't become compromised. | | |
| ▲ | arendtio an hour ago | parent [-] | | But isn't this a problem with the ecosystem and not with the program? I mean, with yarn / etc., you have the same problems, don't you? |
| |
| ▲ | 4 hours ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | paxys 2 hours ago | parent | prev | next [-] |
| Every new framework gets buzz on HN and is forgotten a day later. Meanwhile 99% of developers never left node + npm + vite in the first place. |
|
| ▲ | epolanski 4 hours ago | parent | prev [-] |
| Node is too slow, plain and simple. I've experimented a lot with all nodes up to 24 latest and bun has consistently led to sizeable speed ups. |
