I really want to like Deno. I started to watch "just a few minutes" of their keynote (I assume it was the most recent one, this was a month or so ago) and was intrigued by it and ended up watching the whole thing.
Then I went to go play with it add... I ran into odd compatibility issues (no, I don't remember them, I'm sorry) and tried Bun and everything "just worked". I'm sure Bun is not perfect but so far, every one-off script I've thrown at it has "just worked" which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be.
If I never see an error about how I should change my "type" to "module" only to do it have it complain about 10 other things I will die happy.
I love Javascript, I love TypeScript, I feel like I'm primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K/V store ring very true. I kept looking for things like "What backend framework should I use?" and the answers were all over the place and not very mature options. It felt like I was building on sand.
I hope I'm 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.
I feel like they bit off more than they can chew. I want to like it, too. But they’re trying to create a whole new JavaScript ecosystem from the ground up, and a lot of it depends on maintaining a seamless compatibility layer that’s always a moving target.
It’s not just node. They have Fresh, which depends on Preact, which is a compatibility layer over the React API. Why? To save a few K on bundle size? They have JSR. Why?
The sales pitch is great: Typescript that just works. But in my experience, it didn’t “just work”. I tried building something with Fresh and ran into issues immediately. I bailed out.
Yea I had the misfortune of thinking I could write it in deno because deno was available in the extra repository of archlinux whereas bun wasn't
Big mistake. my project really required me to have so many custom deno commands like deno run -A --sloppyimports and so much more and that it was really causing me to be unable to find previous history of commands (something which I have in zshrc because of it for some reason)
I really regret not using bun for it. Bun is faster & to me it doesn't matter that much because deno is boasting that it can run nextjs, well quite frankly, I don't use nextjs, I use sveltekit which works on literally every single platform.
And also instead of deno cloud, I personally prefer cloudflare workers with sveltekit. It has been a breeze of mind to be honest, but I am not sure if cloudflare workers is 100% compatible with nodejs/bun but my deployments have always worked for some reason.
Respect. Everyone gets to love something. I’ve been through enough iterations of technology that I don’t attach like that anymore. But I find it interesting when people express these opinions. Can you share a little context? What background you’re from, industry your working in, what motivates your love?
I use Deno all the time... but it might not be exactly how it's marketed...
Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno.
It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off.
This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).
It's amazing for scripting, I use it for that all the time too. Just the basic premise of "we can have nice things [static types and a standard library] in scripts" is lovely
I hope it doesn't die, but I always thought the business model was going to be tough. Bun seems to be eclipsing Deno for sure, mainly due to its embrace of any and every syntax/feature/ecosystem, which makes me sad because Deno's opinionated stance was what had me so excited to begin with
> If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled.
I don't agree with the author's use of "rug pulled" here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun.
Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.
The "rug pull" I was referring to is more about the general Deno philosophy. It's gone from being a modern forward-thinking JS runtime, to being just a Node/NPM copycat with its own half-baked packaging system.
In regards to Deno Deploy I agree that scaling down is nicer, but they're extremely hush about it. Using Deploy for anything beyond a hobby project is a business risk.
Alternatively, this may be Deno’s “Dip”: A tough period of time before continued gains and small breakthroughs that build up over time to a new plateau. Maybe all new creative projects will have this as a part of their journey. I am confident Ryan Dahl is unlikely to give up, and is aware (and working to become more aware) of what is necessary to improve for deno to achieve the vision he has for it.
Dahl doesn't strike me as a business or product person. He's a genius when left to tinker. I get the impression Deno is floundering because of business/VC pressure. I see the original promise of Deno being compromised in an effort to increase users/customers. The project is no longer focused on just making a good JS runtime.
I read the post from a business lens and an outside observer and this was my hope too. If Deno is buckling down and cutting costs in order to survive a long winter and carry on that seems like the right move for the business and the community at the expense of latency.
I loved David Bushell's writing. Very entertaining as always.
I do agree many of Deno's products are in decline.
But I think deno is by far the superior typescript/javascript runtime. And deno can be run on many reputable edge providers. So deno deploy is not necessary. It's too bad because I did like the simplicity of deno deploy, but other edge provides seem to be good too.
Some of it does indeed need tweaking to get it work. But I find many amazing pieces of software written for Deno. And I find deno's tooling and security way more mature than node or bun.
As long as the tooling stays good and the runtime is updated. I'm staying.
I will be willing to switch to bun if the tooling/security gets good. I should revisit bun to see if it is now good. To my knowledge bun does not have granular permission levels like Deno. I don't understand why the runtime should have access to everything by default. I much prefer deno's way of doing things.
The rust reimplementation of the node modules is interesting to read. I took some ideas for the llrt runtime modules. As a comparison Bun Zig implementation is scarily ignoring a lot of edge cases.
One major reason I still haven't switched away from Node and NPM is major stability and support, pretty much everywhere, e.g. full automatic VS Code support. Plus, even if it's ever so slowly, Node.js is legitimately keeping up to date with the latest ES features and always improving its stdlib, and V8 is still the king of performance and likely to remain so, unless, say, a court were to split up Chrome from Google funding by monopoly laws. That said, Node progress is slow. I'm not entirely sure why. I'd be glad to get paid to help make Node.js better if that were a job. And I'm still waiting on #57696 to avoid using async in a few places that I otherwise wouldn't need to.
Node’s progress to modern stuff like ES modules has been glacial. Probably the primary reason Bun/Deno have any success. It is speeding up though, seems a fire was lit by competition.
I don't intent this to be mean to Deno, but did it ever really get traction? Hard to describe something as a decline if it never really held a significant position.
it’s really about taste. deno has insanely high standards, and the choices they make are great.
deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity.
if you’re looking at node and think it’s great, you should use it.
node compat makes me like deno more, not less.
it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.
Personally the problem is just lack of communication. When 2 of your core products look abandoned your inviting this criticism.
I love using Deno, even with the remaining node issues (usually relating to something in the Tower of Babel that is meta frameworks) it’s an exceedingly boring tool which is precisely what I’ve wanted for typescript for years.
I can see they have technical potential but what I want more than anything else right now is just some confidence they’ll be around in 5 years, in this sense I can’t seperate the software and the business as there’s not one without the other.
Hopefully the fresh & deploy v2 updates they’ve been silently working on deliver and this entire concern will evaporate.
I wired up some custom middleware on Bunny using Deno and it was the first time I really saw the value of it. It was really nice to just hot load dependencies via a URL, write my code, and go. Beyond that use case, though, not much has stood out.
I am trying to use it as a FaaS to some level of success
I only wish that the compiled binary retain full Deno capabilities, it would be even better if the permission model could limit file system access and limit cmd to a specific user
I've also been using Deno Deploy for AI integrations, and something I miss is being able to have multy-file projects without deploying from github
Just give me a online vscode environment, limited as it may be
Typescript LSP should be able to run in a worker, and I wouldn't mind having to install a browser extension if necessary
Meh, I worked at Deno until last year and I think the signal of seeing Deploy downsize regions is not much of anything. The Deploy product itself suffered from some early missteps in terms of design. If anything, scaling down to a few core regions puts them in a better position to rebuild a stronger offering.
There wasn't really a rugpull in the https:// dependency space either. It just turns out that the package approach for software is better and there are major unsolved problems in web-identifier-based code distribution.
I was skeptical of the value of JSR when it was first internally announced but TBH, but I think it's a strong offering in the packaging space and is in a better position than alternatives.
node.js compat is hard, packaging is hard, writing performant Rust/V8 hybrid code is hard, but the team is pretty packed with smart people who really understand the space.
This is sad news. I always found NodeJS' APIs to be a bit deficient, and liked Deno's better - with the caveat that they openly admit to copying designs from Go[1], so it's not necessarily original.
IMO in JS/TS world its atm Bun vs. Deno in replacing node, npm, pnpm, yarn whatever other package manager.
What i see is, that Deno try to go the vercel way and want to make some money to finance all this open source development. IMO totally legit.
And also, normal, when you spin up a (startup) idea, 19 of 20 will fail.
So i don't get the point of the article actually. The Article points to all this ideas but forgets that deno's core is the runtime. In between the lines, a node / LAMP-Stack history blinks up.
I like deno's security model where you have to enable things. But I think it made a HUGE mistake to the point of being useless.
Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled.
The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.
It’s definitely nice to know that nothing gets executed, read, written or sent without permission from the user when running a program/script with Deno.
You complain the flags always have to be set to get anything working so they are supposedly useless. No, you don’t have to set them in a grant-all fashion. All flags allow fine-grained permissions, e.g. --allow-env=API_KEY,PORT only allows access to the env vars API_KEY and PORT instead of all env vars. The same principle applies to --allow-net, --allow-run, --allow-read, --allow-write, etc. See `deno run --help` or https://docs.deno.com/runtime/fundamentals/security/ for more.
I think that’s still a win for Deno. Even using all but one flag is better than carte blanche. That said I often —allow-all because Im lazy. Containerising stuff helps.
My original view on Deno and JSR was positive and optimistic (it's all there on my blog). I've been using it for years and I still use Deno because it has more convenient/ergonomic APIs than Node.
If Deno halving the Deploy regions twice from 35 to 12, and 12 to 6 doesn't convince you then I don't know what will
Sorry for putting the security hat, but how does anyone run Deno in production without any worries when this is the state of affairs of their vulnerability notifications and scanning. No SBOM / SCA tool that I know of supports deno.lock and since it has a distributed nature, as far as I understand there is basically no way to be alerted on CVEs, unless you work hard to generate a compatible package-lock.json / yarn.lock file and stay with only npm compatible packages etc. Is it bothering only me?
From hanging around Deno's official Discord, Reddit, etc, I get the impression that there are simply not that many people using it.
I doubt they are making much money from the public-facing Deno Deploy product, and are probably reducing its number of regions because those who are using it are mostly just noodling around on the free tier.
Really liked Deno, particularly its support of url imports. As primarily a Java developer having to deal with Maven dependencies, I cannot stress enough how refreshing it was to just say "the dependency is right there, go get it".
The fact that Deno is lagging behind Node so it can shepherd people towards a first-party alternative that they just so happen to offer premium services for is... well, it didn't bode well.
I've since abandoned Deno for Bun, which has meant giving up url imports, but Bun always feels so fresh. It gave me first-party SQLite support, not an abstraction around SQLite that they hint hint, nudge nudge me towards paying for. That said, I have felt a little uneasy about Bun since its v1.2 release (https://bun.sh/blog/bun-v1.2).
[+] [-] joshstrange|11 months ago|reply
Then I went to go play with it add... I ran into odd compatibility issues (no, I don't remember them, I'm sorry) and tried Bun and everything "just worked". I'm sure Bun is not perfect but so far, every one-off script I've thrown at it has "just worked" which is amazing for me since I greatly prefer to work in TypeScript and (until recently with the type-stripping stuff in node) that was way harder than it needed to be.
If I never see an error about how I should change my "type" to "module" only to do it have it complain about 10 other things I will die happy.
I love Javascript, I love TypeScript, I feel like I'm primed to love Deno but all the parts of it felt half-baked. The comments in this article about things like Fresh and K/V store ring very true. I kept looking for things like "What backend framework should I use?" and the answers were all over the place and not very mature options. It felt like I was building on sand.
I hope I'm 100% wrong, I hope deno turns it around, I want more things like deno to exist, but the closing of data centers is not encouraging.
[+] [-] dimal|11 months ago|reply
It’s not just node. They have Fresh, which depends on Preact, which is a compatibility layer over the React API. Why? To save a few K on bundle size? They have JSR. Why?
The sales pitch is great: Typescript that just works. But in my experience, it didn’t “just work”. I tried building something with Fresh and ran into issues immediately. I bailed out.
[+] [-] Imustaskforhelp|11 months ago|reply
Big mistake. my project really required me to have so many custom deno commands like deno run -A --sloppyimports and so much more and that it was really causing me to be unable to find previous history of commands (something which I have in zshrc because of it for some reason)
I really regret not using bun for it. Bun is faster & to me it doesn't matter that much because deno is boasting that it can run nextjs, well quite frankly, I don't use nextjs, I use sveltekit which works on literally every single platform.
And also instead of deno cloud, I personally prefer cloudflare workers with sveltekit. It has been a breeze of mind to be honest, but I am not sure if cloudflare workers is 100% compatible with nodejs/bun but my deployments have always worked for some reason.
[+] [-] davidkwast|11 months ago|reply
[+] [-] unknown|11 months ago|reply
[deleted]
[+] [-] travisgriggs|11 months ago|reply
Respect. Everyone gets to love something. I’ve been through enough iterations of technology that I don’t attach like that anymore. But I find it interesting when people express these opinions. Can you share a little context? What background you’re from, industry your working in, what motivates your love?
[+] [-] kamranjon|11 months ago|reply
Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno.
It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off.
This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).
[+] [-] brundolf|11 months ago|reply
I hope it doesn't die, but I always thought the business model was going to be tough. Bun seems to be eclipsing Deno for sure, mainly due to its embrace of any and every syntax/feature/ecosystem, which makes me sad because Deno's opinionated stance was what had me so excited to begin with
[+] [-] edoceo|11 months ago|reply
Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
[+] [-] usef-|11 months ago|reply
> If you sense some ire here it’s because I went all-in on Deno. I was fooled. I was rugged pulled.
I don't agree with the author's use of "rug pulled" here. Deno took a shot and not all businesses succeed — they did have unusually strong competition in Bun.
Them scaling down the number of regions might make them sustainable longer with their current customers who have deployments. That seems nicer than a hard shutdown.
[+] [-] dbushell|11 months ago|reply
In regards to Deno Deploy I agree that scaling down is nicer, but they're extremely hush about it. Using Deploy for anything beyond a hobby project is a business risk.
[+] [-] magicink81|11 months ago|reply
[+] [-] dbushell|11 months ago|reply
[+] [-] esses|11 months ago|reply
[+] [-] nake89|11 months ago|reply
I do agree many of Deno's products are in decline.
But I think deno is by far the superior typescript/javascript runtime. And deno can be run on many reputable edge providers. So deno deploy is not necessary. It's too bad because I did like the simplicity of deno deploy, but other edge provides seem to be good too.
Some of it does indeed need tweaking to get it work. But I find many amazing pieces of software written for Deno. And I find deno's tooling and security way more mature than node or bun.
As long as the tooling stays good and the runtime is updated. I'm staying.
I will be willing to switch to bun if the tooling/security gets good. I should revisit bun to see if it is now good. To my knowledge bun does not have granular permission levels like Deno. I don't understand why the runtime should have access to everything by default. I much prefer deno's way of doing things.
[+] [-] hoppp|11 months ago|reply
Deno is still better than node and its sort of a swiss army knife for developing servers in Typescript fast.
[+] [-] rawkode|11 months ago|reply
[+] [-] Sytten|11 months ago|reply
[+] [-] hardwaresofton|11 months ago|reply
I’m biased but learning difficulty aside, Rust is very optimal as a language.
[+] [-] bsder|11 months ago|reply
That is pretty much the standard problem across programming.
[+] [-] 9d|11 months ago|reply
[+] [-] dbushell|11 months ago|reply
[+] [-] crowcroft|11 months ago|reply
[+] [-] theThree|11 months ago|reply
[+] [-] techgnosis|11 months ago|reply
[+] [-] dbushell|11 months ago|reply
[+] [-] TOGoS|11 months ago|reply
[+] [-] randall|11 months ago|reply
it’s really about taste. deno has insanely high standards, and the choices they make are great.
deno deploy subhosting seems unlikely to go anywhere, even if the serverless fad is coming to its plateau of productivity.
if you’re looking at node and think it’s great, you should use it.
node compat makes me like deno more, not less.
it’s fine to not use it, but most of the points are about deno the business, not deno the tech. postgres, rust, and a lot of other projects find a way out of the vc treadmill.
[+] [-] DimmieMan|11 months ago|reply
I love using Deno, even with the remaining node issues (usually relating to something in the Tower of Babel that is meta frameworks) it’s an exceedingly boring tool which is precisely what I’ve wanted for typescript for years.
I can see they have technical potential but what I want more than anything else right now is just some confidence they’ll be around in 5 years, in this sense I can’t seperate the software and the business as there’s not one without the other.
Hopefully the fresh & deploy v2 updates they’ve been silently working on deliver and this entire concern will evaporate.
[+] [-] rglover|11 months ago|reply
[+] [-] tough|11 months ago|reply
[+] [-] d0100|11 months ago|reply
I am trying to use it as a FaaS to some level of success
I only wish that the compiled binary retain full Deno capabilities, it would be even better if the permission model could limit file system access and limit cmd to a specific user
I've also been using Deno Deploy for AI integrations, and something I miss is being able to have multy-file projects without deploying from github
Just give me a online vscode environment, limited as it may be
Typescript LSP should be able to run in a worker, and I wouldn't mind having to install a browser extension if necessary
[+] [-] mmastrac|11 months ago|reply
There wasn't really a rugpull in the https:// dependency space either. It just turns out that the package approach for software is better and there are major unsolved problems in web-identifier-based code distribution.
I was skeptical of the value of JSR when it was first internally announced but TBH, but I think it's a strong offering in the packaging space and is in a better position than alternatives.
node.js compat is hard, packaging is hard, writing performant Rust/V8 hybrid code is hard, but the team is pretty packed with smart people who really understand the space.
[+] [-] RainyDayTmrw|11 months ago|reply
[1]: https://deno.land/[email protected]
[+] [-] exiguus|11 months ago|reply
[+] [-] BoorishBears|11 months ago|reply
Future devs will look back and wonder why we randomly let Guillermo Rauch ruin the ecosystem for a few years.
[+] [-] bluelightning2k|11 months ago|reply
Realistically, we need to grant access to env variables, network, etc. So those flags are functionally useless as always enabled.
The issue we face is making sure our dependencies don't do something nefarious. Demo doesn't solve that. I would really, really like to be able to specify these flags at the package level.
[+] [-] csiegert|11 months ago|reply
You complain the flags always have to be set to get anything working so they are supposedly useless. No, you don’t have to set them in a grant-all fashion. All flags allow fine-grained permissions, e.g. --allow-env=API_KEY,PORT only allows access to the env vars API_KEY and PORT instead of all env vars. The same principle applies to --allow-net, --allow-run, --allow-read, --allow-write, etc. See `deno run --help` or https://docs.deno.com/runtime/fundamentals/security/ for more.
[+] [-] dbushell|11 months ago|reply
[+] [-] MortyWaves|11 months ago|reply
[+] [-] dbushell|11 months ago|reply
If Deno halving the Deploy regions twice from 35 to 12, and 12 to 6 doesn't convince you then I don't know what will
[+] [-] knowitnone|11 months ago|reply
[+] [-] eranation|11 months ago|reply
https://www.reddit.com/r/Deno/comments/1g5mu0l/thats_all_goo...
https://www.reddit.com/r/Deno/comments/1dpexwv/dependency_vu...
[+] [-] frou_dh|11 months ago|reply
I doubt they are making much money from the public-facing Deno Deploy product, and are probably reducing its number of regions because those who are using it are mostly just noodling around on the free tier.
[+] [-] Defletter|11 months ago|reply
The problem came when I noticed how Deno was being steered towards SaaS. For example, Deno KV, which uses SQLite internally, became available with v1.33 (https://deno.com/blog/v1.33#built-in-kv-database). But actual SQLite support did not come until v2.2 (https://deno.com/blog/v2.2#support-for-nodesqlite) nearly two years later... and it's a node api!
The fact that Deno is lagging behind Node so it can shepherd people towards a first-party alternative that they just so happen to offer premium services for is... well, it didn't bode well.
I've since abandoned Deno for Bun, which has meant giving up url imports, but Bun always feels so fresh. It gave me first-party SQLite support, not an abstraction around SQLite that they hint hint, nudge nudge me towards paying for. That said, I have felt a little uneasy about Bun since its v1.2 release (https://bun.sh/blog/bun-v1.2).
[+] [-] mac9|11 months ago|reply