12 ms·

Reports of Deno's Demise Have Been Greatly Exaggerated

223 points by stephdin 1y ago

azdavis 1y ago
This is likely in response to https://news.ycombinator.com/item?id=43863937 https://news.ycombinator.com/item?id=43863937
eknkc 1y ago
Whenever I read a blog post assuring me that something is not how it looks, it turns out to be exactly how it looks at the end. BTW, I don't use deno and haven't been following any news whatsoever so this is simply a shitty statement from an outsider. It is interesting that I tested deno a couple of times but kept using node until bun came around and I basically switched to bun. I can't say why exactly.
- fluidcruft 1y ago
  I agree also as an outsider. These sorts of "meta" discussions always smell of spin aimed at investors and usually are not good news for customers. Customers generally care about things like product and long term reliability and stability. These meta things always have the tone of Monty Python's "Bring out your dead!" segment.
- CuriouslyC 1y ago
  Bun has high node compatibility with lightning fast testing and a good/fast built in package manger. I'd use bun for local dev even I was deploying with node.
  - bredren 1y ago
    Why not esbuild? It was ~fast enough first and free of capital entanglements.
    - CuriouslyC 1y ago
      Bun is still faster, and Bun's testing is insanely fast -- I had a test suite that would take 30 seconds with Jest that finished in 800ms with bun. Plus Bun's networking performance is insane compared to Node, and you can have a lot more concurrent clients in a light vpc (think 1gb).
      - bredren 1y ago
        I think you're saying the integration of fast testing and building is what moves the needle for you? Because esbuild is limited to the build portion. I haven't explored fast testing alternatives to pair with esbuild.
    - pjmlp 1y ago
      And Go is much safer as implementation language.
      - CuriouslyC 1y ago
        Go is safer for networking heavy/performance critical services, but for anything that's IO/upstream limited the performance of Bun and Go will be comparable and there are more people who are node proficient/it lets people work across the stack with the same tooling.
        pjmlp 1y ago
        What has that to do with Zig?
candiddevmike 1y ago
Post is by the CEO and doesn't really address the criticisms around Deno, just seems to justify their own internal decisions (or his?). Seems like Deno products work really well for Deno though!
- nchmy 1y ago
  What criticisms of deno do you think went unaddressed?
  - candiddevmike 1y ago
    They don't really address stability, and even go as far to say they aren't chasing parity. Blog post gives off major "you're holding it wrong" vibes.
wyuenho 1y ago
Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region. I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.
- mosura 1y ago
  My gut feeling is that people want a modernized heroku. Managed RDBMS and an auto scaling set of servers that use it. That covers a massive proportion of the companies that don’t need or want massive scale.
  - o_m 1y ago
    Most people and even most companies don't need horizontal scaling. Hardware has been much faster and cheaper since Heroku's heyday. Scaling vertically with 80+ cores on a single CPU and 256gb+ of ram only costs a few hundred dollars a month these days. With caching on a server like that, it can handle a million requests a second, or tens of thousands a second for dynamic data from the database on the same server.
  - leptons 1y ago
    If Deno were supported on AWS Lambda I might think about using it. FaaS on a major infrastructure provider is what I need. I'm not putting a project that means anything to me on Deno's servers, they aren't really leading the industry and might not be around in the blink of an eye the way the tech world is going lately.
  - aryonoco 1y ago
    Isn’t that Supabase?
    - mosura 1y ago
      No, that is just a database and runner for functions. Heroku simplified deployment and operations dramatically, specifically for full Rails apps.
mattlondon 1y ago
I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with bun.sh - node backwards compatibility (although not using V8). Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node?
- diggan 1y ago
  > Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice.
  - Octoth0rpe 1y ago
    > why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.
    - diggan 1y ago
      > Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.
afavour 1y ago
I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matter: they’re both VC funded. The post is a good illustration of why that matters. Very little of it is about Deno itself, instead it’s mostly about the paid-for services Deno Inc offers. They have to prioritise and chase that because their investors want to see financial growth. It’s the same reason they abandoned the idea of Deno being a fresh start in the JS ecosystem (an idea I loved) and instead started patching in Node compatibility layers. They had to reduce friction, not add to it. But for me that compromised the reason for using it in the first place. Node has many flaws. And it’s boring. But its existence doesn’t depend upon the whims of random investors who might decide to pull the plug at any moment. So I’m just going to stick with it.
- nchmy 1y ago
  Could it be that they added node compatibility because people wanted node compatibility. If investors pushed for it as well, then they were just being sensible... I started working with JS/TS just before Deno 2 came out and having, essentially, full node (and TypeScript) compatibility was the primary reason I switched to it. It is all just so simple in comparison to node. But, I agree about the VC funding - it certainly gives cause for concern about Deno's direction and longevity. But what other option is there, really? Hopefully what was said in this post about reduction of Deno Deploy locations being a function of use rather than economics was true
  - afavour 1y ago
    > Could it be that they added node compatibility because people wanted node compatibility I imagine that’s exactly the reason! But they outlined their reasoning for a clean break pretty well in their 1.0 announcement post[1] and they haven’t, to my knowledge, posted a follow up “here’s why we were wrong about all that” post. All of which is to say I understand the business reasons why they did it, but to me it compromises the original technical promise of Deno. A rebooted, sensible JS ecosystem was the reason I was interested in Deno originally. I use Node every day and I’m mostly happy with it but whenever I need to dive into a dependency to see what’s going on it’s a five layer deep rats nest of transpiled and sometimes even minifed code using different module formats and platform specific APIs. I’d love to be done with all that. Sometimes it pays to be bold when you’re challenging an entrenched incumbent. Any non-Node JS platform has to pitch "don't use the status quo, take a risk, use me" and absent the original benefit I don’t see a good argument to use Deno, especially when factoring in the risk of VC-driven priorities. I’m not saying everyone has to agree with me on that but it’s my personal perspective. [1] https://deno.com/blog/v1 https://deno.com/blog/v1
dbushell 1y ago
Doesn't inspire confidence. I guess we’ll see soon enough what Deploy will become since that's "imminent". KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now. Fresh is being refactored with an alpha in "late Q3 2025 (likely September)". It was a fairly basic framework to being with. The no compilation/build step was the only interesting idea and that's going away. The runtime is actively developed but I find this statement amusing: > We’re not chasing feature parity with other runtimes. The release notes on Node/NPM compatibility would suggest otherwise.
- fallinditch 1y ago
  > KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now. I think you're right, I was just about to use it for something but now I'm considering other options...
- pier25 1y ago
  > KV is dead Yeah this is a terrible move. Companies aren't relying on KV precisely because it's in beta not because it was a bad idea. I use Cloudflare Workers KV a lot and I'm not interested in durable objects. I was really interested in Deno KV until now. Plus the optics of announcing a product and abandoning it are not good. Ryan is a great technical guy but these decisions don't look good from a strategic perspective.
diggan 1y ago
> There’s been some criticism lately about Deno - about Deploy, KV, Fresh, and our momentum in general. It seems like they never replied to the criticism against their momentum (something I haven't seen myself, what would the argument even be), was that intentional or just missed? > Some of that criticism is valid. Would have been great to also outline what criticism is/was valid, and how they're aiming to solve those things. Sure, maybe a bit "shoot yourself in the foot" but personally I really prefer companies that are upfront about the drawbacks, and makes it more likely I'll chose them. Migadu is a great example of this, where they have a pro/con page where they are upfront about the drawbacks of using Migadu (https://migadu.com/procon/ https://migadu.com/procon/). Just the existence of that page is probably ~20% of why I chose Migadu in the first place.
- skybrian 1y ago
  Here’s how they addressed momentum: > Since the release of Deno 2 last October - barely over six months ago! - Deno adoption has more than doubled according to our monthly active user metrics. The obvious question is: doubled, but compared to what? And what are they measuring? They’re not disclosing any real metrics on adoption. I think what happened is that people were giving them the benefit of the doubt because they were new and you could imagine huge growth. The disappointment is by comparison to vague hopes and dreams.
  - anon7000 1y ago
    Monthly active users is a real measurement.
    - robertlutece 1y ago
      sure, but from 1 to 2 or from 1M to 2M
      - Cthulhu_ 1y ago
        In 2022 it was 250.000 monthly users [0], according to a "community" blurb on their homepage they have over 400.000 [1]. [0] https://deno.com/blog/changes#a-large-and-growing-ecosystem https://deno.com/blog/changes#a-large-and-growing-ecosystem [1] https://deno.com/ https://deno.com/
v3ss0n 1y ago
There is barely very little positive points in moving existing node to deno - which are mostly frontend.
deleted 1y ago
[deleted]
nicce 1y ago
> One of the biggest questions we’ve been hearing is about Deno Deploy — specifically, the reduction in available regions. While we understand the optics of this scaling back, it isn’t for the reasons often feared or accused. > Rather, reality is: most applications don’t need to run everywhere. They need to be fast, close to their data, easy to debug, and compliant with local regulations. We are optimizing for that. Why does this sound very odd? I chose to not use Deno Deploy because region was not close enough and it would have just make everything slower than using other means. (Because there are many options to host data closer to overall end-users, and some regulations also happen on country level)
popcorncowboy 1y ago
I get the "earnest, 'authentic', 'responsible' engagement by the CEO", but this post and title is lifted straight out of media-playbook-fails-101. Post a title like this at your peril. The content doesn't "own" the missteps, it writes the epitaph of Deno. All this article does is validate the "reports" of "demise" and unavoidably presents as "doth protest too much". If you insist on engaging with a negative narrative there are more constructive ways to frame it. Don't talk about "committing" to anything, just DO. Ryan, if you do nothing else, think about changing the title. But this entire post should ideally get rewritten. There are some really positive things you're doing. But they're covered in stink.
yahoozoo 1y ago
The problem with Deno is that it has lost the plot. When it was first announced years ago, it was simply a safer, faster JS/TS runtime “written in Rust” which I assume it still is but now you go to the website and you click a “Products” drop down containing a bunch of other shit. It’s like they looked at what Vercel did with introducing a deployment platform after their initial NextJS work and wanted to follow suit.
- bredren 1y ago
  Was it this or did the JavaScript / node communities get their acts together? I had thought a lot of what Deno was setting out to do was cool beans for a time but parity was faster to come from js/node than expected.
deleted 1y ago
[deleted]
redwood 1y ago
Anyone looking at Mastra on top of Deno for at-scale concurrent agent orchestration?
ecares 1y ago
Deno is just a marketing company dressed as a software startup
- rc00 1y ago
  And Rust is the perfect lingua franca to accomplish this. The demise of both of these trends cannot come soon enough.
- deleted 1y ago
  [deleted]
- rc00 1y ago
  And Rust is the perfect lingua franca to accomplish this. The demise of both of these trends cannot come soon enough.
rafram 1y ago
I’m not sure why anyone would want their JS runtime to be their package manager, code formatter, compiler, bundler, web framework, KV store, and cloud provider(!) all at the same time. There’s just no way that they can ship the best product in all of those categories.
- rglover 1y ago
  It's less likely (and really, depends on the quality of the team and their attention to detail—it's not a "law"), but certainly not a "no way." I'm far more concerned when the official answer to a feature missing is "just use a third-party!" That spoils a lot of tools for me as I immediately read that as "you're on your own, buddy, have fun with your Frankenstein app!" Over time, unless the team building the thing is entirely tone deaf, I'd expect each individual tool to improve as demanded/necessary. Not only that, but knowing that those tools are being thought about as parts of a whole is deeply comforting (I trust them more than standalone tools as interdependency headaches have likely been solved). One of the biggest headaches in JS is the tendency for tool builders to just eschew responsibility in favor of sending their community on a goose chase. I commend the Deno folks for taking this approach. We should have more, not less of this attitude in the ecosystem.
- yencabulator 1y ago
  Skip the last 3 and it's a pretty sweet combo.
jppope 1y ago
Personally I love what Ryan and the Deno team have done, if there is anything to really say its that incumbency in languages and software ecosystems is really strong- and its stronger the further down the stack you get. I will say that I was disappointed when they added NPM into the project, I understand why they did it but I would have preferred they not do it. With that said all of my blogs and client sites are all being happily built in lume with deno right now (hosted on cloudflare) and they have been great for years now. I am still very happy for having made that change.
eqvinox 1y ago
This is really OT, but if I don't ask now I might never get an answer… Someone mentioned to me "Deno-style event loops" / "Deno-style main loops". I asked what that is but they were gone. I've tried to look it up, to no avail. I do quite a bit of work on low level event loops. I'm continually interested in how different projects are doing it and what ideas and tricks they come up with. It bugs me to no end that I can't find anything on what this "Deno style loop" is supposed to be. Anyone know what's meant / have a pointer or two?
- skybrian 1y ago
  I’m guessing the use of Promises rather than Node-style network programming, which gets pretty hairy.
sholladay 1y ago
I was excited about Deno precisely because it was a greenfield approach without backwards compatibility. Early on, they focused on reducing complexity and it worked. There were definitely some new pain points compared to Node, but I found them pretty manageable. At some point, rather than coming up with native solutions to those pain points, they retreated and started leaning on backwards compatibility as a workaround. Today, Deno feels more complex than Node does because it contains both approaches. And now there are lots of edge cases where a Node package ought to work, but doesn’t because of one unimplemented API or option or a bug that exists only in Deno. My favorite testing framework, AVA, still isn’t supported. I used to just ignore the npm compatibility layer and target Deno itself, but that’s become more cumbersome to do over time. For example, look at `deno run —help` and look at how many command line options and env vars there are. It’s exploded in the past few years. A lot of that is for npm interoperability. For me, it’s just a lot of noise. The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Yet they don’t seem to want to do that. I really want Deno to succeed, if for no other reason than because it’s pushing Node to do things that they should’ve done years ago, such as adding a permission system. I just don’t think the current vision for Deno is very coherent or consistent with its original purpose.
- mark_and_sweep 1y ago
  > My favorite testing framework, AVA, still isn’t supported. Have you checked recently? The docs (https://docs.deno.com/runtime/fundamentals/testing/ https://docs.deno.com/runtime/fundamentals/testing/) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework. > The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Again, have you checked recently? According to the docs this is supported: "Deno's built-in linter, `deno lint`, supports recommended set of rules from ESLint to provide comprehensive feedback on your code. (...) You can specify custom rules, plugins, and settings to tailor the linting process to your needs." (https://docs.deno.com/runtime/fundamentals/linting_and_formatting/ https://docs.deno.com/runtime/fundamentals/linting_and_forma...) I've been using Deno for 6 years now. And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.
TiredOfLife 1y ago
"Google Stadia is not shutting down" was posted by Stadia 2 months before being shut down.
k__ 1y ago
It might just be my perception, but I had the impression Deno got his ass whooped by Bun and Node.js. While some people whine about the Node.js compat, I'd assume it's the main point that kept Deno on life-support in the long run. Bun did it right from the start and it seems people love it. Being quite a bit faster than Node.js (even with the compat APIs) and Deno obviously helps too. If they keep that going, they'd enter Go level of performance.
- ctz 1y ago
  It is instructive to compare Bun and Deno's issue tracker. Like, the five most recent issues for Bun at the time of writing are all crashes. Some of these are controlled panics or assertion failures, but others are like "we are now executing from address -1" or "we are trying to read from address 0x00000069." Recently written software simply should not have these classes of problem.
  - pjmlp 1y ago
    That is what happens when the user base basically wants a Modula-2 with C syntax. Yes, preferably safer than C ever was, but that isn't what a 21st century systems language is supposed to be.
  - nicce 1y ago
    In Chrome, many of those bugs would be $5000 bounty and you don’t even need the exploit code.
  - Sytten 1y ago
    When you read the Bun codebase it is scary how they ignore edgecases. The codebase of Deno is actually legit, I used it as reference for LLRT modules. This is really a case were Rust will shine compare to Zig.
NHQ 1y ago
Deno ought to become an engine for the innovative development of web browsers. That is what we need, and what it could very well offer. Better permissions, protocol choices, simpler extensions, all around more options and control. Business wise turn their deploy system into a resource for the browser base, for instance app store, for instance flash compute/rendering, for instance agent hosting services.
ffsm8 1y ago
Mark Twain was born in 1835, made the quote in 97 and died in 10. So the quote was done around 60 yrs old. And he perished roughly 1/4 of the of the time later. Demo was released in 2018, it has now quoted the statement, 7 yrs later. I guess the next 2 years are gonna be interesting?
- thunderbong 1y ago
  Is this a pattern seen elsewhere?
  - ffsm8 1y ago
    Of projects and companies saying "we're not going to close down" and then - shortly after - shutting down? It's not rare, so kinda. The reason a project addresses these rumors at all means that they've noticed a trend and are worried about it. Just like meta isn't publishing articles how react isn't going anywhere - they know it won't, despite the countless articles claiming otherwise. What this kind of statement actually means it's basically "we're not secure, but we can't admit to it as that would cement it." Which funnily enough applied to Twain too, as he did indeed suffer from the illness people were gossiping about. It was just a lot less eminently dangerous then the rumors claimed
teucris 1y ago
I’m seeing some debate on Deno’s decision to ensure Node compatibility, apparently as it gives up a core value prop of early Deno to try and hit the reset button. Can someone help me understand what was lost here? Is there no longer a way to use Deno without using the Node ecosystem?
- drewbitt 1y ago
  It adds complexity. Instead of being forced to do things the Deno way, now users don't migrate at all from node code and then (not unreasonably, due to their mission of node compat) complain when they don't work. A large amount of feature work stalled due to the node compat work for over a year. Even now, in 2.3.0 over 30% of all listed changelog items are node compat. They started pushing you to use config files to better integrate with your dependencies as a new default. etc
IshKebab 1y ago
> Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database Honestly that seemed really obvious from the start - it's hard to think of many use cases where this isn't the case. Glad they realised anyway.
- Cthulhu_ 1y ago
  > it's hard to think of many use cases where this isn't the case Especially in 2021 (iirc) the lambda and edge function architectures were being pushed hard, so it's understandable they went in this direction at the time. But like with all things, eventually things balance out and you realise most software is still "old fashioned".
- 4ndrewl 1y ago
  Well it's 95% of the real world, but probably only 5% of the hype world.
quantadev 1y ago
When there's two competing technologies, and they're both solving the same problem, I always go with whatever's more popular, unless there's a compelling reason not to. This is mainly because of community support and having more companies/developers motivated to rapidly solve challenges that come up, and/or fix bugs. But especially in the AI/LLM era it's even _more_ important to use what's most popular because the LLM will know more about it, and can pull information from vastly more resources, including it's most important "source" of all: The model weights.
drewbitt 1y ago
I really like Deno. I use it every day. But this is not a blog post I would have wrote. It just feels defensive.
MortyWaves 1y ago
It's a shame that the author famous for shitting on Deno has caused them to even need to write this.

223 points by stephdin 1y ago

This is likely in response to https://news.ycombinator.com/item?id=43863937 https://news.ycombinator.com/item?id=43863937

eknkc 1y ago

Whenever I read a blog post assuring me that something is not how it looks, it turns out to be exactly how it looks at the end. BTW, I don't use deno and haven't been following any news whatsoever so this is simply a shitty statement from an outsider. It is interesting that I tested deno a couple of times but kept using node until bun came around and I basically switched to bun. I can't say why exactly.

fluidcruft 1y ago
I agree also as an outsider. These sorts of "meta" discussions always smell of spin aimed at investors and usually are not good news for customers. Customers generally care about things like product and long term reliability and stability. These meta things always have the tone of Monty Python's "Bring out your dead!" segment.
CuriouslyC 1y ago
Bun has high node compatibility with lightning fast testing and a good/fast built in package manger. I'd use bun for local dev even I was deploying with node.
- bredren 1y ago
  Why not esbuild? It was ~fast enough first and free of capital entanglements.
  - CuriouslyC 1y ago
    Bun is still faster, and Bun's testing is insanely fast -- I had a test suite that would take 30 seconds with Jest that finished in 800ms with bun. Plus Bun's networking performance is insane compared to Node, and you can have a lot more concurrent clients in a light vpc (think 1gb).
    - bredren 1y ago
      I think you're saying the integration of fast testing and building is what moves the needle for you? Because esbuild is limited to the build portion. I haven't explored fast testing alternatives to pair with esbuild.
  - pjmlp 1y ago
    And Go is much safer as implementation language.
    - CuriouslyC 1y ago
      Go is safer for networking heavy/performance critical services, but for anything that's IO/upstream limited the performance of Bun and Go will be comparable and there are more people who are node proficient/it lets people work across the stack with the same tooling.
      - pjmlp 1y ago
        What has that to do with Zig?

candiddevmike 1y ago

Post is by the CEO and doesn't really address the criticisms around Deno, just seems to justify their own internal decisions (or his?). Seems like Deno products work really well for Deno though!

nchmy 1y ago
What criticisms of deno do you think went unaddressed?
- candiddevmike 1y ago
  They don't really address stability, and even go as far to say they aren't chasing parity. Blog post gives off major "you're holding it wrong" vibes.

wyuenho 1y ago

Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region. I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.

mosura 1y ago
My gut feeling is that people want a modernized heroku. Managed RDBMS and an auto scaling set of servers that use it. That covers a massive proportion of the companies that don’t need or want massive scale.
- o_m 1y ago
  Most people and even most companies don't need horizontal scaling. Hardware has been much faster and cheaper since Heroku's heyday. Scaling vertically with 80+ cores on a single CPU and 256gb+ of ram only costs a few hundred dollars a month these days. With caching on a server like that, it can handle a million requests a second, or tens of thousands a second for dynamic data from the database on the same server.
- leptons 1y ago
  If Deno were supported on AWS Lambda I might think about using it. FaaS on a major infrastructure provider is what I need. I'm not putting a project that means anything to me on Deno's servers, they aren't really leading the industry and might not be around in the blink of an eye the way the tech world is going lately.
- aryonoco 1y ago
  Isn’t that Supabase?
  - mosura 1y ago
    No, that is just a database and runner for functions. Heroku simplified deployment and operations dramatically, specifically for full Rails apps.

mattlondon 1y ago

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with bun.sh - node backwards compatibility (although not using V8). Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node?

diggan 1y ago
> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice.
- Octoth0rpe 1y ago
  > why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.
  - diggan 1y ago
    > Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.

afavour 1y ago

I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matter: they’re both VC funded. The post is a good illustration of why that matters. Very little of it is about Deno itself, instead it’s mostly about the paid-for services Deno Inc offers. They have to prioritise and chase that because their investors want to see financial growth. It’s the same reason they abandoned the idea of Deno being a fresh start in the JS ecosystem (an idea I loved) and instead started patching in Node compatibility layers. They had to reduce friction, not add to it. But for me that compromised the reason for using it in the first place. Node has many flaws. And it’s boring. But its existence doesn’t depend upon the whims of random investors who might decide to pull the plug at any moment. So I’m just going to stick with it.

nchmy 1y ago
Could it be that they added node compatibility because people wanted node compatibility. If investors pushed for it as well, then they were just being sensible... I started working with JS/TS just before Deno 2 came out and having, essentially, full node (and TypeScript) compatibility was the primary reason I switched to it. It is all just so simple in comparison to node. But, I agree about the VC funding - it certainly gives cause for concern about Deno's direction and longevity. But what other option is there, really? Hopefully what was said in this post about reduction of Deno Deploy locations being a function of use rather than economics was true
- afavour 1y ago
  > Could it be that they added node compatibility because people wanted node compatibility I imagine that’s exactly the reason! But they outlined their reasoning for a clean break pretty well in their 1.0 announcement post[1] and they haven’t, to my knowledge, posted a follow up “here’s why we were wrong about all that” post. All of which is to say I understand the business reasons why they did it, but to me it compromises the original technical promise of Deno. A rebooted, sensible JS ecosystem was the reason I was interested in Deno originally. I use Node every day and I’m mostly happy with it but whenever I need to dive into a dependency to see what’s going on it’s a five layer deep rats nest of transpiled and sometimes even minifed code using different module formats and platform specific APIs. I’d love to be done with all that. Sometimes it pays to be bold when you’re challenging an entrenched incumbent. Any non-Node JS platform has to pitch "don't use the status quo, take a risk, use me" and absent the original benefit I don’t see a good argument to use Deno, especially when factoring in the risk of VC-driven priorities. I’m not saying everyone has to agree with me on that but it’s my personal perspective. [1] https://deno.com/blog/v1 https://deno.com/blog/v1

dbushell 1y ago

Doesn't inspire confidence. I guess we’ll see soon enough what Deploy will become since that's "imminent". KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now. Fresh is being refactored with an alpha in "late Q3 2025 (likely September)". It was a fairly basic framework to being with. The no compilation/build step was the only interesting idea and that's going away. The runtime is actively developed but I find this statement amusing: > We’re not chasing feature parity with other runtimes. The release notes on Node/NPM compatibility would suggest otherwise.

fallinditch 1y ago
> KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now. I think you're right, I was just about to use it for something but now I'm considering other options...
pier25 1y ago
> KV is dead Yeah this is a terrible move. Companies aren't relying on KV precisely because it's in beta not because it was a bad idea. I use Cloudflare Workers KV a lot and I'm not interested in durable objects. I was really interested in Deno KV until now. Plus the optics of announcing a product and abandoning it are not good. Ryan is a great technical guy but these decisions don't look good from a strategic perspective.

diggan 1y ago

> There’s been some criticism lately about Deno - about Deploy, KV, Fresh, and our momentum in general. It seems like they never replied to the criticism against their momentum (something I haven't seen myself, what would the argument even be), was that intentional or just missed? > Some of that criticism is valid. Would have been great to also outline what criticism is/was valid, and how they're aiming to solve those things. Sure, maybe a bit "shoot yourself in the foot" but personally I really prefer companies that are upfront about the drawbacks, and makes it more likely I'll chose them. Migadu is a great example of this, where they have a pro/con page where they are upfront about the drawbacks of using Migadu (https://migadu.com/procon/ https://migadu.com/procon/). Just the existence of that page is probably ~20% of why I chose Migadu in the first place.

skybrian 1y ago
Here’s how they addressed momentum: > Since the release of Deno 2 last October - barely over six months ago! - Deno adoption has more than doubled according to our monthly active user metrics. The obvious question is: doubled, but compared to what? And what are they measuring? They’re not disclosing any real metrics on adoption. I think what happened is that people were giving them the benefit of the doubt because they were new and you could imagine huge growth. The disappointment is by comparison to vague hopes and dreams.
- anon7000 1y ago
  Monthly active users is a real measurement.
  - robertlutece 1y ago
    sure, but from 1 to 2 or from 1M to 2M
    - Cthulhu_ 1y ago
      In 2022 it was 250.000 monthly users [0], according to a "community" blurb on their homepage they have over 400.000 [1]. [0] https://deno.com/blog/changes#a-large-and-growing-ecosystem https://deno.com/blog/changes#a-large-and-growing-ecosystem [1] https://deno.com/ https://deno.com/

v3ss0n 1y ago

There is barely very little positive points in moving existing node to deno - which are mostly frontend.

deleted 1y ago

[deleted]

nicce 1y ago

> One of the biggest questions we’ve been hearing is about Deno Deploy — specifically, the reduction in available regions. While we understand the optics of this scaling back, it isn’t for the reasons often feared or accused. > Rather, reality is: most applications don’t need to run everywhere. They need to be fast, close to their data, easy to debug, and compliant with local regulations. We are optimizing for that. Why does this sound very odd? I chose to not use Deno Deploy because region was not close enough and it would have just make everything slower than using other means. (Because there are many options to host data closer to overall end-users, and some regulations also happen on country level)

popcorncowboy 1y ago

I get the "earnest, 'authentic', 'responsible' engagement by the CEO", but this post and title is lifted straight out of media-playbook-fails-101. Post a title like this at your peril. The content doesn't "own" the missteps, it writes the epitaph of Deno. All this article does is validate the "reports" of "demise" and unavoidably presents as "doth protest too much". If you insist on engaging with a negative narrative there are more constructive ways to frame it. Don't talk about "committing" to anything, just DO. Ryan, if you do nothing else, think about changing the title. But this entire post should ideally get rewritten. There are some really positive things you're doing. But they're covered in stink.

yahoozoo 1y ago

The problem with Deno is that it has lost the plot. When it was first announced years ago, it was simply a safer, faster JS/TS runtime “written in Rust” which I assume it still is but now you go to the website and you click a “Products” drop down containing a bunch of other shit. It’s like they looked at what Vercel did with introducing a deployment platform after their initial NextJS work and wanted to follow suit.

bredren 1y ago
Was it this or did the JavaScript / node communities get their acts together? I had thought a lot of what Deno was setting out to do was cool beans for a time but parity was faster to come from js/node than expected.

deleted 1y ago

[deleted]

redwood 1y ago

Anyone looking at Mastra on top of Deno for at-scale concurrent agent orchestration?

ecares 1y ago

Deno is just a marketing company dressed as a software startup

rc00 1y ago
And Rust is the perfect lingua franca to accomplish this. The demise of both of these trends cannot come soon enough.
deleted 1y ago
[deleted]
rc00 1y ago
And Rust is the perfect lingua franca to accomplish this. The demise of both of these trends cannot come soon enough.

rafram 1y ago

I’m not sure why anyone would want their JS runtime to be their package manager, code formatter, compiler, bundler, web framework, KV store, and cloud provider(!) all at the same time. There’s just no way that they can ship the best product in all of those categories.

rglover 1y ago
It's less likely (and really, depends on the quality of the team and their attention to detail—it's not a "law"), but certainly not a "no way." I'm far more concerned when the official answer to a feature missing is "just use a third-party!" That spoils a lot of tools for me as I immediately read that as "you're on your own, buddy, have fun with your Frankenstein app!" Over time, unless the team building the thing is entirely tone deaf, I'd expect each individual tool to improve as demanded/necessary. Not only that, but knowing that those tools are being thought about as parts of a whole is deeply comforting (I trust them more than standalone tools as interdependency headaches have likely been solved). One of the biggest headaches in JS is the tendency for tool builders to just eschew responsibility in favor of sending their community on a goose chase. I commend the Deno folks for taking this approach. We should have more, not less of this attitude in the ecosystem.
yencabulator 1y ago
Skip the last 3 and it's a pretty sweet combo.

jppope 1y ago

Personally I love what Ryan and the Deno team have done, if there is anything to really say its that incumbency in languages and software ecosystems is really strong- and its stronger the further down the stack you get. I will say that I was disappointed when they added NPM into the project, I understand why they did it but I would have preferred they not do it. With that said all of my blogs and client sites are all being happily built in lume with deno right now (hosted on cloudflare) and they have been great for years now. I am still very happy for having made that change.

eqvinox 1y ago

This is really OT, but if I don't ask now I might never get an answer… Someone mentioned to me "Deno-style event loops" / "Deno-style main loops". I asked what that is but they were gone. I've tried to look it up, to no avail. I do quite a bit of work on low level event loops. I'm continually interested in how different projects are doing it and what ideas and tricks they come up with. It bugs me to no end that I can't find anything on what this "Deno style loop" is supposed to be. Anyone know what's meant / have a pointer or two?

skybrian 1y ago
I’m guessing the use of Promises rather than Node-style network programming, which gets pretty hairy.

sholladay 1y ago

I was excited about Deno precisely because it was a greenfield approach without backwards compatibility. Early on, they focused on reducing complexity and it worked. There were definitely some new pain points compared to Node, but I found them pretty manageable. At some point, rather than coming up with native solutions to those pain points, they retreated and started leaning on backwards compatibility as a workaround. Today, Deno feels more complex than Node does because it contains both approaches. And now there are lots of edge cases where a Node package ought to work, but doesn’t because of one unimplemented API or option or a bug that exists only in Deno. My favorite testing framework, AVA, still isn’t supported. I used to just ignore the npm compatibility layer and target Deno itself, but that’s become more cumbersome to do over time. For example, look at `deno run —help` and look at how many command line options and env vars there are. It’s exploded in the past few years. A lot of that is for npm interoperability. For me, it’s just a lot of noise. The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Yet they don’t seem to want to do that. I really want Deno to succeed, if for no other reason than because it’s pushing Node to do things that they should’ve done years ago, such as adding a permission system. I just don’t think the current vision for Deno is very coherent or consistent with its original purpose.

mark_and_sweep 1y ago
> My favorite testing framework, AVA, still isn’t supported. Have you checked recently? The docs (https://docs.deno.com/runtime/fundamentals/testing/ https://docs.deno.com/runtime/fundamentals/testing/) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework. > The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Again, have you checked recently? According to the docs this is supported: "Deno's built-in linter, `deno lint`, supports recommended set of rules from ESLint to provide comprehensive feedback on your code. (...) You can specify custom rules, plugins, and settings to tailor the linting process to your needs." (https://docs.deno.com/runtime/fundamentals/linting_and_formatting/ https://docs.deno.com/runtime/fundamentals/linting_and_forma...) I've been using Deno for 6 years now. And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.

TiredOfLife 1y ago

"Google Stadia is not shutting down" was posted by Stadia 2 months before being shut down.

k__ 1y ago

It might just be my perception, but I had the impression Deno got his ass whooped by Bun and Node.js. While some people whine about the Node.js compat, I'd assume it's the main point that kept Deno on life-support in the long run. Bun did it right from the start and it seems people love it. Being quite a bit faster than Node.js (even with the compat APIs) and Deno obviously helps too. If they keep that going, they'd enter Go level of performance.

ctz 1y ago
It is instructive to compare Bun and Deno's issue tracker. Like, the five most recent issues for Bun at the time of writing are all crashes. Some of these are controlled panics or assertion failures, but others are like "we are now executing from address -1" or "we are trying to read from address 0x00000069." Recently written software simply should not have these classes of problem.
- pjmlp 1y ago
  That is what happens when the user base basically wants a Modula-2 with C syntax. Yes, preferably safer than C ever was, but that isn't what a 21st century systems language is supposed to be.
- nicce 1y ago
  In Chrome, many of those bugs would be $5000 bounty and you don’t even need the exploit code.
- Sytten 1y ago
  When you read the Bun codebase it is scary how they ignore edgecases. The codebase of Deno is actually legit, I used it as reference for LLRT modules. This is really a case were Rust will shine compare to Zig.

NHQ 1y ago

Deno ought to become an engine for the innovative development of web browsers. That is what we need, and what it could very well offer. Better permissions, protocol choices, simpler extensions, all around more options and control. Business wise turn their deploy system into a resource for the browser base, for instance app store, for instance flash compute/rendering, for instance agent hosting services.

ffsm8 1y ago

Mark Twain was born in 1835, made the quote in 97 and died in 10. So the quote was done around 60 yrs old. And he perished roughly 1/4 of the of the time later. Demo was released in 2018, it has now quoted the statement, 7 yrs later. I guess the next 2 years are gonna be interesting?

thunderbong 1y ago
Is this a pattern seen elsewhere?
- ffsm8 1y ago
  Of projects and companies saying "we're not going to close down" and then - shortly after - shutting down? It's not rare, so kinda. The reason a project addresses these rumors at all means that they've noticed a trend and are worried about it. Just like meta isn't publishing articles how react isn't going anywhere - they know it won't, despite the countless articles claiming otherwise. What this kind of statement actually means it's basically "we're not secure, but we can't admit to it as that would cement it." Which funnily enough applied to Twain too, as he did indeed suffer from the illness people were gossiping about. It was just a lot less eminently dangerous then the rumors claimed

teucris 1y ago

I’m seeing some debate on Deno’s decision to ensure Node compatibility, apparently as it gives up a core value prop of early Deno to try and hit the reset button. Can someone help me understand what was lost here? Is there no longer a way to use Deno without using the Node ecosystem?

drewbitt 1y ago
It adds complexity. Instead of being forced to do things the Deno way, now users don't migrate at all from node code and then (not unreasonably, due to their mission of node compat) complain when they don't work. A large amount of feature work stalled due to the node compat work for over a year. Even now, in 2.3.0 over 30% of all listed changelog items are node compat. They started pushing you to use config files to better integrate with your dependencies as a new default. etc

IshKebab 1y ago

> Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database Honestly that seemed really obvious from the start - it's hard to think of many use cases where this isn't the case. Glad they realised anyway.

Cthulhu_ 1y ago
> it's hard to think of many use cases where this isn't the case Especially in 2021 (iirc) the lambda and edge function architectures were being pushed hard, so it's understandable they went in this direction at the time. But like with all things, eventually things balance out and you realise most software is still "old fashioned".
4ndrewl 1y ago
Well it's 95% of the real world, but probably only 5% of the hype world.

quantadev 1y ago

When there's two competing technologies, and they're both solving the same problem, I always go with whatever's more popular, unless there's a compelling reason not to. This is mainly because of community support and having more companies/developers motivated to rapidly solve challenges that come up, and/or fix bugs. But especially in the AI/LLM era it's even _more_ important to use what's most popular because the LLM will know more about it, and can pull information from vastly more resources, including it's most important "source" of all: The model weights.

drewbitt 1y ago

I really like Deno. I use it every day. But this is not a blog post I would have wrote. It just feels defensive.

MortyWaves 1y ago

It's a shame that the author famous for shitting on Deno has caused them to even need to write this.