4 ms·

From the README: "Why? Reading and writing lots of tiny files incurs significant syscall overhead, and (npm) packages often have lots of tiny files. (...)" It

by seeekr 5y ago

From the README: "Why? Reading and writing lots of tiny files incurs significant syscall overhead, and (npm) packages often have lots of tiny files. (...)" It seems the author is working on a fast JS bundler tool (https://bun.sh https://bun.sh) and the submission links to an attempt to fix some of the challenges in processing lots of npm files quickly. (But of course could be useful beyond that.)

jraph 5y ago
> "Why? Reading and writing lots of tiny files incurs significant syscall overhead, and (npm) packages often have lots of tiny files" Ah, those trees of is-character packages depending on is-letter-a packages, themselves depending on is-not-number packages each appearing several times in different versions are probably challenging to bundle and unpack efficiently. We might want to address file systems too, so they too can handle NPM efficiently (actual size on disk and speed). Or maybe the actual fix is elsewhere. Runs, fleeing their screen screaming in fear and frustration (no offense to the author, I actually find the problem interesting and the work useful)
- aaaaaaaaaaab 5y ago
  Obviously, what we really need is an OS optimized for npm.
- zkldi 5y ago
  If I had asked them what they wanted, they would've said faster filesystems.
eyelidlessness 5y ago
Came to mention Bun when I saw this hit the front page. I’ve been following Jarred’s Twitter since I heard about Bun and it’s quite impressive (albeit incomplete). To folks wondering why another bundler/what makes Bun special: - Faster than ESBuild/SWC - Fast build-time macros written as JSX (likely friendlier to develop than say a Babel plugin/macro). These open up a lot of possibilities that could benefit end users too, by performing more work on build/server and less client side. - Targeting ecosystem compatibility (eg will probably support the new JSX transform, which ESBuild does not and may not in the future) - Support for integration with frameworks, eg Next.js - Other cool performance-focused tools like Hop and Peechy[1] (though that’s a fork of ESBuild creator’s project Kiwi) This focus on performance is good for the JS ecosystem and for the web generally. 1: https://github.com/Jarred-Sumner/peechy https://github.com/Jarred-Sumner/peechy
rob74 5y ago
Maybe the way to fix these issues would be to try to reduce the package bloat in the npm ecosystem? Otherwise I'm afraid a faster bundler will only result in even more packages being bundled. But I guess it's hard to get that genie back into the bottle...

by seeekr 5y ago

jraph 5y ago

> "Why? Reading and writing lots of tiny files incurs significant syscall overhead, and (npm) packages often have lots of tiny files" Ah, those trees of is-character packages depending on is-letter-a packages, themselves depending on is-not-number packages each appearing several times in different versions are probably challenging to bundle and unpack efficiently. We might want to address file systems too, so they too can handle NPM efficiently (actual size on disk and speed). Or maybe the actual fix is elsewhere. Runs, fleeing their screen screaming in fear and frustration (no offense to the author, I actually find the problem interesting and the work useful)

aaaaaaaaaaab 5y ago
Obviously, what we really need is an OS optimized for npm.
zkldi 5y ago
If I had asked them what they wanted, they would've said faster filesystems.

eyelidlessness 5y ago

Came to mention Bun when I saw this hit the front page. I’ve been following Jarred’s Twitter since I heard about Bun and it’s quite impressive (albeit incomplete). To folks wondering why another bundler/what makes Bun special: - Faster than ESBuild/SWC - Fast build-time macros written as JSX (likely friendlier to develop than say a Babel plugin/macro). These open up a lot of possibilities that could benefit end users too, by performing more work on build/server and less client side. - Targeting ecosystem compatibility (eg will probably support the new JSX transform, which ESBuild does not and may not in the future) - Support for integration with frameworks, eg Next.js - Other cool performance-focused tools like Hop and Peechy[1] (though that’s a fork of ESBuild creator’s project Kiwi) This focus on performance is good for the JS ecosystem and for the web generally. 1: https://github.com/Jarred-Sumner/peechy https://github.com/Jarred-Sumner/peechy

rob74 5y ago

Maybe the way to fix these issues would be to try to reduce the package bloat in the npm ecosystem? Otherwise I'm afraid a faster bundler will only result in even more packages being bundled. But I guess it's hard to get that genie back into the bottle...