std

The stuff on JSR is lifted out of Deno. JSR can install packages for Node and Bun [0]. Most of the "@std" packages in the link above claim support for Bun (the right hand of the package list "stack of avatars" will have the Bun avatar; easier to read on individual package pages where it becomes a header, though), and there is a Bun test matrix in the GitHub Actions CI. (Right now it looks like it just has Bun latest in the matrix, though.) In terms of coordination, I don't see any obvious Bun contributors in a quick skim [1], but it seems open to contribution and is MIT licensed. [0] https://jsr.io/docs/using-packages#adding-a-package [1] https://github.com/denoland/std/graphs/contributors

They are separate packages, curated by the Deno team[1]. The interfaces are pretty consistent and useful. 1. https://github.com/denoland/std

I'm impressed with Deno's code. https://github.com/denoland/deno https://github.com/denoland/deno_std

Start off by doing things the deno-"native" way and it's very fun. Most or all of the js tooling woes go away. It starts as just a .ts file that works. I love it for small CLI utilities. There are some quirks[0] but it's well designed UX overall. Stuff like node stdlib support is a necessary evil for some things. Like sharp (libvips binding) and nestjs didnt work at all before that iirc. And alternatives a lot of work to make. 0: https://github.com/denoland/deno_std/discussions/2102

At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are. https://github.com/denoland/deno_std/pull/2400 The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted. I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was

It is like Demo deprecating fs.exists().[1] [1]https://github.com/denoland/deno_std/discussions/2102

This was fun to read through. I would need to profile the code, but the startup time being bad for Deno seems like maybe a combination of the code in here being unoptimized: https://github.com/denoland/deno_std/blob/0ce558fec1a1beeda3... (Ex. Lots of temporaries) And usage of the readFileSync+TextDecoder API instead of readTextFile (which is also a docs issue since it suggests the first one). It seems the code loads the 100MB into memory, then converts to another 100MB of utf8, then parses with that inefficient csv parser. The rust and go versions look to be doing stream/incremental processing instead.

Much of Node.js is written in C, yet it's still called Node.js. Deno has some JavaScript/TypeScript in it. On GitHub https://github.com/denoland/deno is 22.8% JavaScript and 13.2% TypeScript, and https://github.com/denoland/deno_std is 68.2% JavaScript and 31.6% TypeScript. So to me the title is misleading about the name (Deno is certainly not named Deno.js), but not about what Deno is written in.

Bartek from Deno here, this is mostly true. The runtime heavily relies on the Web standards, while Go was a heavy inspiration for Deno's standard library (deno_std [0]) in the early days. Since then, we've been relying on Web standards even more and the standard library started seeing more modules added that were based on popular npm modules. On another note: huge thanks for rust-analyzer, not only is it my main daily driver, but we also used it as a reference for implementation of "deno lsp" - the language server that ships with Deno. [0] https://github.com/denoland/deno_std

I've been looking at Deno very briefly recently (overall a good impression) and I was very much surprised that just getting the visitor's IP address took like a dozen lines of code. My test case was, basically reproducing something like <?php echo $_REQUEST . "\n" . $_SERVER; ?> and I was a little surprised how much convenience was baked into it and how you wouldn't have access to all that in other libs. That someone created an issue[1] makes me think I am not just not looking good enough and it's actually tedious. [1]: https://github.com/denoland/deno_std/issues/1884

Deno will have a more substantial standard library. https://github.com/denoland/deno_std

Disclaimer: I contribute to Deno. IMHO it will take 1-2 months before someone deploys simple production services. We're already working on standard library, which you can see here: https://github.com/denoland/deno_std