Deno 2.8

https://deno.com/blog/v2.8

by roflcopter69 • 2 months ago

419 187 2 months ago

deno.com

orf• 2 months ago

The release post for v2.8 is not yet published. Check GitHub releases page for the latest release status of Deno.

eskori• 2 months ago

By the time I read this, the blog post doesn't exist yet:

The release post for v2.8 is not yet published.
Check GitHub releases page for the latest release status of Deno.

The release is here: https://github.com/denoland/deno/releases/tag/v2.8.0

EDIT: Formatting

cf100clunk• 2 months ago

Deno is a JavaScript and TypeScript runtime, for those who don't recognize the name. Here's a review of Deno 2.6 vs competitors Bun 1.3 and Node.js 25:

https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

kayson• 2 months ago

It's surprising to me that bun is so much faster serving web requests. The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?

Similarly, it seems, though they didnt exactly say, that they're running bun with a warm package cache... What about the others? Do they have caches?

kloop• 2 months ago

The article mentions Zig as a factor, but is micromanaging memory really gaining over 2x vs node?

As someone who has optimized by reducing/batching heap allocations, 2x seems within the realm of possibility, depending on the exact circumstances.

That being said, iirc, node also has more hooks for things like observability than bun does, which might hurt it here

infensus• 2 months ago

Bun's http server is basically µWebSockets (C++ library) under the hood. You can also use it in Node via µWebSockets.js, the official bindings.

vmsp2• 2 months ago

I wonder how Deno's faring.

Node's the stable solution and will be with us forever. You can now use TypeScript with it and, soon enough, you'll be able to build your app to a single executable -- including native deps.

Bun's chaotic but, nonetheless, it's _fast_ and it's taking an interesting approach by including everything in the stdlib. Plus, bought by Anthropic.

Deno had an awesome story with the sandbox and ease of import for third-party dependencies. Sandboxes feel pretty commoditized now and I'm not sure the import mechanism ended up being that much nicer than a `npm add`.

freedomben• 2 months ago

and, soon enough, you'll be able to build your app to a single executable -- including native deps.

Whoa, did not know that. That's a killer feature!

sirsinsalot5• 2 months ago

Code, as a single executable you say?! Whatever will they think of next?

TingPing• 2 months ago

Plus, bought by Anthropic.

Who thinks this is a positive?!

vmsp2• 2 months ago

That wasn't a value judgment on the acquisition. I was just pointing out that it made the project more sustainable.

simonw3• 2 months ago

It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.

hobofan• 2 months ago

They did lay off ~half the company ~2 months ago: https://news.ycombinator.com/item?id=47467746

neals2• 2 months ago

It's good to have some options, to prevent the ecosystem from stalling

appplication• 2 months ago

I agree philosophically, but the JavaScript ecosystem has never been languishing for lack of options. If anything, excessive fragmentation is a real concern.

rozenmd• 2 months ago

You can already ship single executables, my product's CLI is a Node single executable application

turadg• 2 months ago

The new *deno pack* command is a nice addition for safe and simple packaging.

For those using Node.js, a similar single command is available with https://www.npmjs.com/package/ts-node-pack

Now that Node.js supports importing .ts modules, more repos can use them without a build step or putting any build artifacts in the checkout.

WorldMaker7• 2 months ago

Yeah, that's my immediate debate in reading this blog post: `deno pack` might be a great replacement to my existing `npm publish` workflow for my open source packages and continue shifting my work to Deno-first/Deno-mostly, but on the flipside, with Node's growing TS support I'm also considering switching to Typescript-only npm packages as a (tiny) message to the ecosystem.

Though I'm also happy that JSR exists as that (mostly) cleaner ecosystem.

Ciantic• 2 months ago

Node refuses to support TypeScript within node_modules, see https://github.com/nodejs/node/issues/58429 this means you can't do "Typescript-only npm packages".

They made that intentionally at the beginning:

Currently there is consensus that Node.js should NOT run TypeScript files inside `node_modules. It is not supported to avoid package maintainers to release TS only package.

notnullorvoid4• 2 months ago

It sounds a lot like DNT (https://github.com/denoland/dnt) which has existed for a long time, but having it in Deno cli does bring significant visibility.

mohsen1• 2 months ago

Deno now defaults to npm:

This is an interesting development. npm after all is the de-facto ecosystem and leaning into it makes sense.

I'm wondering how Deno would've been received if it supported npm and package.json from day 1.

afavour2• 2 months ago

I actually lost interest in Deno once it started leaning into NPM. I thought it was a bold and wise idea to make a clean break from the mess of Node and restart with a sensible ecosystem. Absent that... I'm just sticking with Node.

pjmlp7• 2 months ago

As someone that works in projects with standard IT tools, not supporting NPM made it a non starter for us.

No way it would go through standard build pipelines, or team skills.

WorldMaker7• 2 months ago

I think Deno's done a pretty good job at keeping what it did well in Deno 1 while also playing ball with Node/npm compatibility. JSR feels like the more sensible ecosystem we all need (especially high scoring packages) and while this current change leaves JSR prefixed when doing a `deno install` it doesn't change the fact that the more packages you install from JSR instead of npm the better things feel. (Especially once you can break from package.json and node_modules, but even the baby steps along the way to that goal still feel pretty good.)

mmastrac• 2 months ago

I previously worked at Deno and even with all that tbh, I am not sure the http deps were the right way to go. I've really wanted to like them but package managers really have advantages.

I would not say npm was the right direction. I actually was a fan of JSR (didn't work on it but all my experience with it was great)

notnullorvoid4• 2 months ago

This is a really odd change. Deno already supported installing npm packages, this only removes the "npm:" prefix requirement for cli commands. Considering the nightmare that is npm, I was quite happy for jsr to become the defacto registry for the Deno ecosystem. If anything I would've expected the "jsr:" prefix to be the default.

survirtual• 2 months ago

I wrap most node-isms and use deno as the runtime. Works well. If a project is pure typescript I just have deno run it. Extra options for security are great, installation scripts disabled by default, etc.

If you're using node directly, please stop. At a minimum use Bun.

With agentic work, there is little reason to use anything besides Rust and Typescript in any case. Room to disagree but type safety, memory safety, and a large corpus of work is critical. Agents need difficult errors and baked in patterns they navigate it easily. For UI, Typescript makes the most sense just because of the mass of design examples.

dan_rock_wilson• 2 months ago

Deno: has a basic permission model that is very helpful, written in Rust, and native TypeScript support.

I'm not deep in the webdev / node / Bun ecosystems, I've just been a happy user of Deno for small services for several years. Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?

Just the permission system alone (though I wish it extended to modules) is so compelling with Deno that I'm perplexed at why someone would transition from node to bun and not node to Deno.

yroc92• 2 months ago

I use (and like) both. Bun is a drop-in replacement for node. If you don't want to fuss with test config, tsconfig, esmodules, etc., I find that it just works. Deno has a nice standard lib, great CLI support, and I used to love deno deploy but its gotten very clunky these days.

3uler• 2 months ago

But if you look at the node compliance tests, deno has better compliance now days…

WorldMaker7• 2 months ago

I imagine some of Bun's growth is just simply V8 fatigue. JavaScriptCore does have some different runtime characteristics and it is nice to a diversity in language engines.

(It seems too bad ChakraCore is mostly out to pasture and not keeping up with TC-39 and that there's still no good Node-compatible wrapper for SpiderMonkey, but having one for JavaScriptCore is still a breath of fresh air.)

vmg124• 2 months ago

I'm very confident that users of these runtimes do not care about the underlying Js engine powering them. Bun succeeded because it was compatible with node and required much less configuration to get a standard typescript and react app running.

npn• 2 months ago

because for most people they don't need what deno promises.

me for example only use nodejs or bun to run a basic sveltekit server, so it can render the html for the first time. all core functionalities are delegated to backend services written in crystal or rust. I don't need some bloated js runtime that hoard 500MB of ram for that purpose (crystal services only take 20+ MB each).

bun promised a lean runtime, every essential functionality is written in zig to increase the speed and memory footprint. and javascriptcore also uses less memory compare to v8. the only thing we expect is for bun to stabilize and can run 24/7 without memory leaking or crashing.

too bad it is a failed promise now.

robflynn• 2 months ago

I hadn't heard of crystal somehow, I work with ruby a lot so that might be fun to play around with.

wk_end• 2 months ago

When Deno first came out it was deliberately incompatible with Node, which limited its ecosystem and audience. Bun came along with a lot of Deno's great features but also Node compatibility, and people really took to that.

But Deno's got Node compatibility now, and Node has adopted a lot of the features that make Deno and Bun so usable. So I'm not sure the choice matters so much these days.

vmg124• 2 months ago

Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).

So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.

I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.

Edit: And Deno is now more compatible with node than bun.

tuananh2• 2 months ago

Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

and yet Bun's npm compat is much much lower than deno

https://x.com/rough__sea/status/2057579066744881188

nailer• 2 months ago

(thinking emoji) they could merge.

Seriously, they're both Rust now. They share goals.

gslepak• 2 months ago

In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things

"Probably"? Are you saying there's a chance he wasn't right?

I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.

VerifiedReports4• 2 months ago

I started a new project with Deno specifically to avoid the NPM mess, and because it was created by Node's creator to fix its shortcomings. I'm new to Web development, but so far the experience has been pretty good.

Nice to see Deno being maintained. The features listed seem pretty substantial.

shepherdjerred• 2 months ago

I used Deno for about a year. I liked it for the reasons you gave, but there were way too many compatibility issues with packages like Astro, Prisma, Vite.

So, I switched to Bun and things have been much smoother!

dmit2• 2 months ago

Can someone explain why it sounds like there's such rapid growth of Bun?

In my case, when I start a little Typescript side project, instead of drowning in the sea of npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime/etc I can just use one thing. And yes, only some of those are Pokémon moves and not actual tools from the JS/TS ecosystem.

satvikpendem2• 2 months ago

But...Deno also has an all in one CLI too. The question was why Bun specifically grew in popularity over Deno.

vorticalbox2• 2 months ago

I think the main issue was when deno first came out it used urls for imports then later added support for npm.

By then bun was already a thing and just ate into its share.

VerifiedReports4• 2 months ago

Why do you consider URLs a problem?

yoyohello132• 2 months ago

Same, I'm mostly a back end dev but when I dip my toes into frontend for personal projects Deno just seems like the most sane choice. It's really nice to work with. I'm kind of sad it doesn't seem to have taken off among the JS folks.

ddosmax556• 2 months ago

I can tell you my experience as a js package dev, last tried a few weeks ago. We're building an npm package that's supposed to run on both node.js, deno & bun & the web.

This is an annoying to do for exactly two platforms: node.js, and deno.

node.js bcs it requires a workaround whenever something networking comes in: fetch doesn't work the same. So you structure you're code around having a node.js workaround. Same story for some other APIs. But you can test if itn works!

Deno is more annoying, you just can't test your package with deno before publishing. Before we released to npm, we installed a tar file and sent those around for testing. Works in node, in vite (node, for browser), works in bun, like a charm. Doesn't work with deno unless you switch to package.json, and you use exactly the subset of the spec that deno supports. You can't "deno install xyz.tar", you have to use npm for that (inserts a single line into package.json), THEN you can use deno to execute. No docs, no hint, just trial & error.

Even more annoyingly, npm & bun both offer 'link': in package repo, call npm/bun link, in the test repo do npm/bun link @yourpackage, and that's it, it's installed. Creates a dyn link to the source's build dir so you can rebuild without packing or sending tars or anything like that, you just build in your package dir and the test project is immediately updated.

Deno doesn't have that. What's worse, they don't tell you they don't have that. Also basically no error messages. It just fails in weird ways. Spent hours trying to do it. Now I just publish without testing for deno and wait for bug reports.

So out of the three: bun just works. That's it. Better than any platform. It just works, and it has a nicer CLI & nicer error messages, and it's faster on startup. It has the web api and the node api (i think) and its own api that's very nice as well, nicer than e.g. node. And e.g. if you run bun link, it tells you exactly what happened: this is what just happened, this is what you have to do to use it elsewhere. Node doesn't have that!

I think deno recognized bun's strategy of using npm dev's backbone as being the better call - that's why they're now slowly introducing node.js features, even though that goes against their original USP.

bartlomieju3• 2 months ago

Thanks for feedback, I opened a PR to implement linking functionality that seems more familiar to npm's strategy: https://github.com/denoland/deno/pull/34359

giancarlostoro• 2 months ago

Deno is from scratch attempting to pass as many NodeJS tests as possible. Bun piggybacks off the WebkitJS library iirc and shims anything nodejs specific it needs.

culi• 2 months ago

Bun had some early (imo, extremely deceptive) benchmarks that showed it had really good performance compared to Node and Deno. Zig was also a fledgling hotlang and Bun managed to translate the Zig community into more energy behind Bun. In addition to that, the creator of Bun became a minor celebrity for spending probably over 12 hours almost every single day working on it.

Everything just came together at the right time really quickly and they managed to capitalize on it.

Also at the time Deno had only just started to backtrack on npm-compatibility and it was still in its infancy (I'd say its fully mature today). Bun was ahead of that curve which made it immediately useful.

cptmurphy2• 2 months ago

Deno permission system is so basic. What you need is capability system

AgentME4• 2 months ago

Javascript/Typescript as it is now isn't a great language for a real capability system because any code can monkey-patch global objects and use that to steal capability objects from elsewhere. JS code of different privilege levels needs to be run in separate realms at the very least. (Though there are proposals for things like frozen realms that try to make JS more suitable for capability systems.)

chamomeal2• 2 months ago

I’m also perplexed that deno isn’t more quickly becoming the defacto server side JS/TS runtime. It really feels like the grown-up version of node.

Node always felt immature compared to stuff like go or java. I still preferred it to go and java. But deno is like node without all the shitty parts. It’s just so simple and productive and has so much good stuff built in. Even building projects with npm packages is easier with deno than with node now.

Bun feels like a faster horse, I guess. I really can’t imagine going back to node/bun on purpose, if I have a choice

wiseowise2• 2 months ago

Node always felt immature compared to stuff like go or java.

Not enough boilerplate and EnterpriseBeanFactorySingleton?

nsonha• 2 months ago

"basic permission model" used to be the only thing Deno had going for, and the keyword is "basic". They pivot pretty late to become a drop-in replacement for nodejs (using the term drop-in loosely here).

Bun has a pragmatic approach from the beginning for being a all-in-one toolset (not just a runtime) and node's replacement. They also has gradual adoption paths such as using bun only as package manager and/or test runner.

paulddraper• 2 months ago

Bun prioritized Node.js compatibility.

Deno since adjusted, but Bun gained a lot of market share in the meantime.

spixy• 2 months ago

Because I don't care about that permission system. Server will run in some container or k8s anyway.

And node / bun development is much easier because of many many npm packages.

interstice• 2 months ago

Although the attacks on the NPM ecosystem are making that sound more like a liability by the day.

wiseowise2• 2 months ago

Can someone explain why it sounds like there's such rapid growth of Bun? Is it just being used as a bundler, but not as JS runtime?

Bundler + used by Claude Code, that’s pretty much it.

pier254• 2 months ago

Bun doesn't require special tooling since it uses standard TS and follows the Node conventions. With Deno you need special tooling for eg the weird import system and package manager.

Bun also includes stuff that you'd need a third party dependency with Deno or Node. Eg: database drivers, S3 client, etc.

Finally, Bun overall has better performance and efficiency compared to Deno.

That said, I'm going back to Node after the recent Bun fiascos with their Rust AI re-write.

Curosinono3• 2 months ago

I don't get it why the hell is TypeScript still not nativly supported in modern browsers?

tuananh2• 2 months ago

JS promise to never break the web. can't say the same about TS

bel8• 2 months ago

JS can't really break the web.

It's a trillion+ market.

If that ever happens for some exquisite reason, it would be forked in under 2 milliseconds by the browser consortium.

vmg124• 2 months ago

Likely because everybody would still strip types, bundle and minify their typescript code anyway.

brazukadev• 2 months ago

it is still a DX improvement

hollowturtle2• 2 months ago

Because "it doesn't exist". It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean? If you want to support a static typed language then you could just compile it down to wasm, if you just want to support types and ignore them at runtime there's an overhead price to pay, or should do runtime type checking? And with which tsconfig? Strict or not?

VerifiedReports4• 2 months ago

All good questions. But... it would simply eliminate a step and result in a single language.

Python supports types and is interpreted, right?

Curosinono3• 2 months ago

It is a language, it doesn't matter to what it is downcompiled to be able to be run in a browser.

Its now 13 years old, not a hard language to have a proper runtime for it and it would just get rid of all the npm stuff.

And for the amount of typescript we now have, it would be worth it to have proper native support.

wpollock3• 2 months ago

Because "it doesn't exist". It's just a layer on top of js, ...

C++ was originally a layer on top of C. The first C++ compiler, "cfront" was actually a transpiler to C.

There is nothing preventing TypeScript from becoming "native" in a similar way.

lelanthran• 2 months ago

It's just a layer on top of js, it doesn't have its own runtime, and btw what would supporting ts a the browser level mean?

It means that `<script src="some-url.ts">` works.

WorldMaker7• 2 months ago

Because standardization is a political process that takes time and consensus to achieve?

https://github.com/tc39/proposal-type-annotations

Curosinono3• 2 months ago

TypeScript is now 13 years old. They could have, by now, made it a lot easier to be able to use Typescript in a browser out of the box without magic behind it.

IshKebab2• 2 months ago

There wouldn't be any benefit. It's not sound so it can't really be used to improve performance.

There was a proposal to support TypeScript syntax, but ignore the actual types (this is basically how Python works). That would be kind of nice because you can skip the compilation step completely (less faff for small projects), but I don't think it went anywhere... or if it is it's getting there at a snail's pace:

https://github.com/tc39/proposal-type-annotations

yoyohello132• 2 months ago

My gripe is why doesn't Webassembly fully support dom manipulation. If we got that working anyone could just bring any language to the browser and we would finally be free from the shackles of JS.

sirsinsalot5• 2 months ago

Or at least some kind of cursor based text buffer tree that wasm can bind to the dom/shadow tree, rather than a fuller API

pier254• 2 months ago

It's probably coming:

https://tc39.es/proposal-type-annotations/

yesbabyyes• 2 months ago

Just make it a habit to write your types in JSDoc and be done with it. It's so much nicer in every way. Typescript checks your types, you are incentivized to write some brief documentation, and (self promotion) if you use something like my library testy you get your JSDoc examples tested.

https://github.com/linus/testy

ale2• 2 months ago

I think if Deno had held on to their initial values for a little longer the pressure towards node compatibility would have been mended by AI agents, because a lot of the pressure is the result of skill issues: if the only way you know how to set up is using express.js then any subsequent tool or runtime must provide a similar abstraction for a “smooth” transition, regardless of how bad the first solution was in the first place. Nowadays you introduce devs to new tech by delivering your product with a set of skills that in practice have replaced documentation and sometimes can be very good at showing better alternative approaches to whatever you’re building.

pjmlp7• 2 months ago

If the JS/TS SDK I get from a SaaS vendor doesn't work on Deno without changes, I am not going to spend one second to make it work.

IshKebab2• 2 months ago

I don't know why they copied NPM's backwards `npm install/ci` thing. Most people think that `install` does use the lock file.

XCSme2• 2 months ago

Is anyone here using Deno in production?

garganzol4• 2 months ago

Absolutely, and having zero problems with it. Which gives a bit awkward and surreal feeling because usually we are used to have at least some problems when using similar technologies, not zero.

XCSme2• 2 months ago

Nice, at what scale?

just123• 2 months ago

I like Deno for the web standards. I think it should be sponsored by the government for it to flourish.

KuhlMensch• 2 months ago

npm by default: When I tried Deno ~1-2 years ago - I immediately shinned myself on this and decided to wait for more sensible defaults. (I've not followed closely, just the basic story)

And reading the features, I'm impressed! - I spot many commands & features that map to my workflow.

Well done Deno team.

garganzol4• 2 months ago

Deno rules, I write some tiny and mid-size web services using it. Works like a Swiss clock, the project ideology is well aligned with the Unix sprit.

In my personal opinion, Deno authors are a bit humble. For example, when grateful users offer donations to the project, the authors politely decline them. I understand why, but at the same time it may create unneeded monetary pressures on the project in the long run.

What can work reasonably well is a shut-up-and-take-my-money monthly subscription for users depending on the project long-term success.

steve_adams_862• 2 months ago

Works like a Swiss clock

It really is such a pleasure. It feels almost like a blend of JS and Go. Fast, flexible, slightly saner package management with more powerful capabilities than other JS/TS alternatives, a better security model, better standard library (so to speak)... And very fast. I love it.

notnullorvoid4• 2 months ago

A lot of these changes seem geared toward adopting Node/NPM default DX. To the point where Deno DX (or what it was previously) now comes second.

The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default. Those types were a pain to deal with even in Node projects, resulting in multiple tsconfigs to avoid those types polluting platform agnostic or web code.

If Deno continues this trajectory then there is less and less reason to use it over Node.

garganzol4• 2 months ago

I somewhat agree with you.

For example, in Deno v2.8 they've changed the return type of setTimeout and setInterval functions from webstandard-compliant 'number' to opinionated 'NodeJS.Timeout'. Which is a short-sighted change trying to reap immediate short-term implementation-centric benefits in the expense of the future. Pains of churn and breaking API changes are welcoming their new bearers...

bartlomieju3• 2 months ago

Bartek from the Deno team here. Thanks for the feedback. I assure you this is not a short-sighted change. This has been a problem since before Deno 1.0. We resorted to hacks like different set of globals for user code and different for code inside node_modules/ directory. It was a maintenance headache, made global lookups super slow and was really hard to explain to users. While Web "setTimeout" might have been nice in the beginning the fact that it required additional APIs like "Deno.unrefTimer" made it worse than Node's setTimeout.

bartlomieju3• 2 months ago

Bartek from the Deno team here. Thanks for the feedback, I understand your frustration.

The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.

Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.

While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.

danborn262• 2 months ago

The continuous performance improvements in Deno are really impressive. Node compatibility getting better with every release makes the transition a lot easier for existing projects.

danielcasper• 2 months ago

I literally just discovered Deno today. I wish there was Deno for Python / WASM path was really mature. Maybe I'm missing something here, but trying to secure both a Python runtime and JS runtime for AI.

csjh• 2 months ago

It should be pretty mature outside of Wasi. To be fair, there's really nothing that's super mature in terms of Wasi support, except maybe Wasmtime

rochacon• 2 months ago

For Python, `uv` [1] delivers a similar experience. Faster dependencies. Better dependency management with `pyproject.toml`. Just use it with `uv run` or `uvx`.

[1] https://github.com/astral-sh/uv

rutierut• 2 months ago

As someone who has used Deno on multiple hobby projects, I’m convinced Deno is where the JS ecosystem should be heading.

Professionally though, it’s complicated recommending it outside of specific and mostly tightly scoped use-cases. At some point the project just changes direction because of business reasons and you need node.

syrusakbary• 2 months ago

It's great to see that since the release of Edge.js [1], they started to take Node.js compatibility more seriously (they went from ~40% to about 75% in just 2 months, so either coincidental or not this is clearly a step on the right direction).

Good work to everyone on the Deno team!

[1] https://edgejs.org/

cptmurphy2• 2 months ago

Are you not tired of self-promotion?

brendonjohn• 2 months ago

I’ve loved using deno.

Full time for the last three months.

Deno replaced a pnpm monorepo I was using.

danborn262• 2 months ago

The steady release cadence for Deno has been impressive to watch. Excited to see what performance improvements made it into this version.

sombragris• 2 months ago

My perspective is that of an user, not a developer. I use Deno since yt-dlp required a JS engine and recommended it. So while I don't use it for development, I have to build it for my system.

This software is a beast to build and package. On first compilation, it spent like ~5-6 hours just pulling Rust crates. This time thankfully was significantly reduced once the relevant packages were in cargo caché; only the changed/added ones were picked up.

But the second problem is even more annoying. Building Deno happily consumes about ~16-20 GB of precious disk space on space-constrained SSDs. This is too much.

I think we should go back to more efficient software, both in object code formats (the product) as well as in the build process. Why would a single JS runtime need 20 GB storage to be built? This is wasteful.

Deno 2.8

Related Stories