Node.js needs a virtual file system • Hacker News Board

Re: Node.js needs a virtual file system

#271

Post by nulltrace » Fri, Mar 20, 2026, 10:46 PM UTC

NoNameProvided wrote: post #202

nulltrace wrote: post #174

Earlier quoted context omitted.

I publish a package with zero deps and people still pull in a pile of transitive stuff from their lockfile. "pg" has 13 dependencies and nobody even blinks. One gets compromised and suddenly every Node backend using Postgres is in scope. Bun shipping native drivers feels like the right call, fewer moving parts.

I understand the general point you're making, but the pg package isn’t a good example. It has 6 deps, not 13, and 5 of those are internal packages from the same monorepo without additional dependencies. There’s only a single external dependency, and that one brings in just one additional package. In my opinion, the pg repo and packages are an example of how OSS stuff should be maintained. Clean repo, clean code, well…

Fair point, I was counting what lands in node_modules rather than direct deps. And most of those are brianc's monorepo packages so the trust surface is way smaller. Bad example on my part.

Re: Node.js needs a virtual file system

#272

Post by int_19h » Sun, Mar 22, 2026, 6:04 AM UTC

epolanski wrote: post #242

int_19h wrote: post #201

Earlier quoted context omitted.

We'd have a lot less enshittification all around, I suspect.

Sure thing, your nurse ain't gonna clean your mom, in the restaurant the chef ain't gonna prepare a dish he doesn't like, your accountant ain't gonna file your taxes if you've given him data he doesn't like, etc. Your paid to do a job, you're either professional or you aren't.

You'd just have to pay more to convince people to do the jobs they hate.

It does mean that nurses might end up getting paid more than software engineers, but why is that a bad thing?

Re: Node.js needs a virtual file system

#273

Post by eviks » Sun, Mar 22, 2026, 7:03 AM UTC

SAI_Peregrinus wrote: post #140

ryandrake wrote: post #111

Earlier quoted context omitted.

One of the worst is media players that all insist on grafting their own "library" on top of my already-working OS filesystem. So I can't just run the media player and play files. No, that would be too simple. I have to first "import" my media into a "library" abstraction and then store that library somewhere else on my filesystem. Terrible!

There's a legitimate problem they're trying to solve there: there are several ways to sort media that don't match up well with a hierarchical filesystem¹. They solve it badly. Good players maintain a database for efficient queries of media metadata, and periodically rescan the folders to update it. Shitty media players try to manage the files themselves, and still end up needing to maintain a database. The worst of t…

> two artists collaborate on an album, which one gets the album in their folder?

Both. Links exist

> What if you want to sort all songs in the display by publication date

You click on the "pub date" column

> metadata database will be needed for efficient search

Yes, nothing can beat caching as illustrated by Everything.

Re: Node.js needs a virtual file system

#274

Post by syrusakbary » Mon, Mar 23, 2026, 11:35 AM UTC

dijksterhuis wrote: post #163

syrusakbary wrote: post #156

Earlier quoted context omitted.

Since when we accepted that we can’t go fast and offer stability at the same time? Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed. This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)

it’s a well known true-ism you can have it cheap, correct or fast. but you can only have two of them at the same time. and we’re talking about FOSS here, so cheap kinda has to be one of them.

Well, with the help of AI now you can have Fast, Affordable, and Correct.

Re: Node.js needs a virtual file system

#275

Post by dijksterhuis » Mon, Mar 23, 2026, 4:58 PM UTC

syrusakbary wrote: post #274

dijksterhuis wrote: post #163

Earlier quoted context omitted.

it’s a well known true-ism you can have it cheap, correct or fast. but you can only have two of them at the same time. and we’re talking about FOSS here, so cheap kinda has to be one of them.

Well, with the help of AI now you can have Fast, Affordable, and Correct.

"Correct" usually means "exactly matches the specification" .... these systems do not do that based on what's been indicated on a bunch of articles, HN discussions, etc. etc. documenting people's collective experiences. It often doesn't one-shot tasks, it requires hand-holding. Oftentimes to a significant degree. Especially if not working on a CRUD webapp with a lot of boilerplate which heavily skew the training data. LLMs return the most likely sequence of individual elements of code, not the most correct code.

So, it's fast if you get lucky and are able to one-shot it, affordable-ish if you get lucky and are able to one-shot it and correct if you get lucky.

And that tends to happen if you're working on a specific set of codebases which are close to the most commonly occurring codebases in the training data set -- i.e. CRUD webapps / heavy boilerplate usage. Most FOSS projects probably don't fit in that camp (i have no data to support this, it's just my gut experience).