node

On Microsoft Github, in a repository such as https://github.com/nodejs/node press `.` (the full stop key) and it will take you away to github.dev, load Microsoft's VS Code in-browser to view and edit code with VS Code plugins and highlighting. And from there you can use GitHub Codespace to "develop in a cloud-hosted, customizable environment" to run and debug.

I'll make no comment on how masterful/well written this is, but these are the most used libraries in the JS world by far margin: https://github.com/nodejs/node/tree/master/lib

Bonus fact: I wanted the 'app' (https://jakearchibald.com/2021/cors/playground/) to allow the HTTP method to be set to anything, which meant I needed a server that could accept anything. I usually use NodeJS, but it turns out the HTTP library they use turns the HTTP method into an enum, so only a subset is supported (https://github.com/nodejs/node/blob/d798de1c653efa5ec0015d44...). This restriction only exists in their HTTP/1 library, their HTTP/2 library supports any method. Anyway, I couldn't use that, so I used Deno via Deno Deploy. Their HTTP library supports any method, and the APIs they use are very similar to web APIs, so it was really easy to get started. Here's the server code: https://github.com/jakearchibald/cors-playground/blob/main/i....

Compare the Linux foundation's treatment of projects: Node: Neither the OpenJS foundation, nor its parent the Linux foundation claims owner ship of Node: https://github.com/nodejs/node/blob/master/LICENSE Linux: No copyright assignment, just a compatible license required: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... The CNCF and the kubernetes system does do a CLA, so it's not a concept the Linux foundation has never heard of it, but clearly it's not required for every project they support. See also SPI's stance, which provides the legal support for projects like Debian and Arch Linux: https://www.spi-inc.org/projects/relationship/

The disagreement is as to who it is easy for; the author seems to only consider programmers by trade and then blame some notion of propagating a legacy of unsafe calls. Every language the author lists as vulnerable was intended, at launch, to be used both as a serious programming language as well as program launching glue or by non-career programmers for things that aren't production grade applications. The only language I can think of that is explicitly an application development language is Rust, and as the author mentions this vuln is not present. And as a note, the alternative to exec in NodeJS are keeping execFile and using these ~10 lines [1] or using spawn directly with these 216 lines [2]. I barely trust myself to reliably reproduce those. [1] https://github.com/nodejs/node/blob/df25424b9195d31224529895... [2] https://github.com/n

Like I said, is aligning more and more: * https://github.com/nodejs/node/issues/19393 * https://github.com/nodejs/node/issues/19308 Web APIs is not something that Deno is doing and Node isn’t. It is more something that Deno has done a few of which Node hasn’t yet.

Probably all tests, the `src` folder containing the core NodeJS code is at https://github.com/nodejs/node/tree/master/src. Also keep in mind it builds on top of V8, which is mostly C++: https://github.com/v8/v8.

I spent the good part of last night compiling a previous version of nodejs to try out quic. I wanted to see if it could replace webrtc for a multiplayer game. You have to compile a previous commit from the repo because the experimental implementation of quic was removed according to this issue: https://github.com/nodejs/node/pull/37067 Not sure when we can expect it to come back. You can just feel the pain in those comments. All that hard work.

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style. Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857 Just take a look at a random stdlib source file: https://github.com/nodejs/node/blob/master/lib/readline.js ``` if (input && input.input) { // An options object was given output = input.output; completer = input.completer; terminal = input.terminal; history = input.history; historySize = input.historySize; signal = input.signal; ``` It's junior-level code writing all over the project. That is a failure in my mind, especially when I know the l

Some side notes: - The readFileSync in this benchmark has UTF-8 decoding (produces a string instead of a Buffer). That’s why it’s slower; not sure why it’s included. - The first guess/suggestion, > I suspect the cause is right here: [https://github.com/nodejs/node/blob/3b2863db12818778671713b5...] > Instead of creating a new Buffer for each chunk, it could allocate a single Buffer and write to that buffer. I don't think Buffer.concat or temporary arrays are necessary. is already what the code does. Multiple chunks and Buffer.concat are only involved if more data gets read than stat initially reports.

I'm brand new to the code, but I don't think it is as simple as you state. The 'one function' you linked to just passes a ReadFileContext into binding.open[1]. The ReadFileContext appears to have its own read that uses its own allocated Buffers[2] under some circumstances, but under others they are mysteriously already there[3]. Then binding.open refers to an internalBinding of fs[4], which I'm unsure of, is that js or C++ code? This[5] suggests C++ is involved, but there is also an open in lib/fs.js[6] with that signature, though it also just calls binding.open at the end with the same signature, so I think it's off into C++ by then. At that point, I lose the trail. Maybe C++ is even doing the allocating. This is not easy code to grok in its full extent. 1 - https://github.com/nodejs/node/blob/master/lib/fs.js#L356 2 - https://github.com