Live data from Hacker News

Node.js needs a virtual file system

blog.platformatic.dev

121–130 of 275 posts

Re: Node.js needs a virtual file system

#121
post #29

Taking the question of whether this would be a useful addition to Node.js core or aside, it must be noted that this 19k LoC PR was mostly generated by Claude Code and manually reviewed by the submitter which in my opinion is against the spirit of the project and directly violates the terms of Developer's Certificate of Origin set in the project's CONTRIBUTING.md

Fully disagree with this take. Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives. Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions: I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.…

I appreciate hearing your point of view on this. In my opinion the future of Open Source and AI assisted coding is a much bigger issue, and different people have different levels of confidence in both positive and negative outcomes of LLM impact on our industry.

It is great to have a legal perspective on compliance of LLM generated code with DCO terms, and I feel safer knowing that at least it doesn't expose Node.js to legal risk. However it doesn't address the well known unresolved ethical concerns over the sourcing of the code produced by LLM tooling.

Re: Node.js needs a virtual file system

#122
post #61
post #55

Earlier quoted context omitted.

Bun, .NET, PHP, Java

For Bun you're thinking of simple key / values, hardly a database. They also have a SQLite driver which is still just a package.

I think you're confusing the database engine with the driver?

Re: Node.js needs a virtual file system

#123
post #55

Earlier quoted context omitted.

Bun, .NET, PHP, Java

For .NET only the old legacy .NET Framework, SqlClient was moved to a separate package with the rewrite (from System.Data.SqlClient to Microsoft.Data.SqlClient). They realized that it was a rather bad idea to have that baked in to your main runtime, as it complicates your updates.

It's still provided by Microsoft. They are responsible for those first party drivers.

Re: Node.js needs a virtual file system

#125

Earlier quoted context omitted.

The two main points are that: 1. Copyright cannot be assigned to an AI agent. 2. Copyrighted works require human creativity to be applied in order to be copyrighted. For point 2 this would apply to times were AI one shots a generic prompt. But for these large PRs where multiple prompts are used and a human has decided what the design should be and how the API should look you get the human creativity required for copy…

That indemnity clause is only for Team, Enterprise and API users. Do you know what was used here? Also the commercial version is limited to “…Customer and its personnel, successors, and assigns…”. I am very much not a lawyer and couldn’t find definitions of these in the agreement but I am not sure how transferable this indemnity would be to an open source project.

I reviewed it and it looks like personal Claude Code subscriptions are not covered, so it's riskier than I claimed.

Re: Node.js needs a virtual file system

#126
post #68
post #54

Earlier quoted context omitted.

Bun provides native MySQL, SQlite, and Postgres drivers. I'm not saying Node should support every db in existence but the ones I listed are critical infrastructure at this point. When using Postgres in Node you either rely on the old pg which pulls 13 dependencies[1] or postgres[2] which is much better and has zero deps but mostly depends on a single guy. [1] https://npmgraph.js.org/?q=pg [2] https://github.com/porsa…

Node has sqlite, though I have not had any issues using better-sqlite3 and worker processes for long running ops

Until the day it gets pwned by a malicious actor. Which is something we've seen quite a lot of times on npm deps.

Re: Node.js needs a virtual file system

#127
post #42
post #37

Earlier quoted context omitted.

How exactly does it violate the Developer's Certificate of Origin clause?

The submitted code must adhere to either of (a), (b), (c), and separately a (d) clause of: https://github.com/nodejs/node/blob/main/CONTRIBUTING.md#dev... If submitter picks (a) they assert that they wrote the code themselves and have right to submit it under project's license. If (b) the code was taken from another place with clear license terms compatible with the project's license. If (c) contribution was written…

To many, it qualifies under either A or B, and therefore C as well. Under A, you can think of the LLM as augmenting your own intelligence. Under B, the license terms of LLM output are essentially that you can do whatever you want with it. The alternative is avoiding use of AI because of copyright or plagiarism concerns.

Re: Node.js needs a virtual file system

#128
How about trying to reduce dependencies? 11ty is going in correct direction, dropping significant chunk of various dependencies or replacing them with packages with no dependencies or using platform features, that becomes readily available.

Re: Node.js needs a virtual file system

#130
post #29

Taking the question of whether this would be a useful addition to Node.js core or aside, it must be noted that this 19k LoC PR was mostly generated by Claude Code and manually reviewed by the submitter which in my opinion is against the spirit of the project and directly violates the terms of Developer's Certificate of Origin set in the project's CONTRIBUTING.md

Fully disagree with this take. Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives. Note aside, OpenJS executive director mentioned it's ok to use AI assistance on Node.js contributions: I checked with legal and the foundation is fine with the DCO on AI-assisted contributions. We’ll work on getting this documented.…

> Not allowing AI assistance on PRs will likely decimate the project in the future, as it will not allow fast iteration speeds compared to other alternatives.

It's not an AI issue. Node.js itself is lots of legacy code and many projects depend on that code. When Deno and Bun were in early development, AI wasn't involved.

Yes, you can speed up the development a bit but it will never reach the quality of newer runtimes.

It's like comparing C to C++. Those languages are from different eras (relatively to each other).

Post reply on HN