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 currently work in the POS industry (day job) and Food Festival Payments (my business).
For me, when it's working, the Typescript development experience is bar-none for me. Typescript (Javascript) can run almost anywhere, or at least all the types of devices I would care about targeting. I enjoy using 1 language for backend and frontend development. I'm fully aware of the issues in the TS/JS ecosystem but I still really enjoy writing TS despite that. I feel like I get "tastes" of a perfect future where the issues I have are fixed and I hope the current state of affairs is just growing pains we look back on as we do the IE6 days (which I developed for, some people forgot how bad it used to be).
Being able to write backend, frontend (web, iOS, Android), all in the same language feels like a super power, especially when you can share code between them. Without Typescript (and Vue/Quasar) there is no way I'd be able to run by own company and support web/iOS/Android without cross-platform frameworks utilizing Typescript. I've written Java, I've written Swift, it's not that I can't write them it's just that I'm not good at either and I don't have the time to get better at either.
I haven't played much with other languages (aside from PHP, which I use for my day job) other than a todo/hello-world here and there because at the end of the day TS fills my needs and has something going for it that no other language does, it runs on the web natively. With WASM that might change (has changed?) but for now TS give me the best DX.
I'm not sure if that answers your question and I'm happy to expand further.
Enterprise frontend and backend development, all Typescript. TS is easily the most productive language I've ever used (professionally worked in Java, then Javascript, with some Ruby and PHP). It scales from no-types JS to architecture astronaut seamlessly. You only have to use what's useful to you. My only hangups were esoteric type errors, but AI made this go away (mostly with more specific explanations of the issue).
We ported our webapps from JS to Typescript a while back, and I hate having to read untyped code, even (maybe especially) the stuff written by our best coders, even my own code. You have to run the code in your head just to understand the shape of "order".
I would never go back, I cannot fathom the resistance in the JS community.
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
Deno has at least attempted to have a business model. Oven/Bun has none in sight and I am having a hard time seeing how they will be any more successful with getting people to pay them money.
I'll never understand how anyone ever liked Perl. I remember before PHP came out and Perl + CGI was what all the forums used, and that kind of made sense before Node.js + TypeScript + Nginx were a thing (maybe). But for scripts? I mean, I guess that it makes sense as a sort of bash on steroids, but at that point, why not have something more structured? Then again, that's around the time that Lua, Ruby, Python etc were all being invented, and for that exact use-case, to be a better scripting language that bash or Perl. But... why even use Perl as an intermediate step? Why not just say "hmm, bash is too simple for this... I'll write a --" oh, I think I get it now. Your only option was Perl for a while, if you didn't want to write a full fledged C or C++ script, which would be much more verbose and unforgiving.
> 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.
Deno's original positioning was as a second version of NodeJS without the learning cruft cluttering the environment. To that extent I think Dahl and his team was successful.
As is so often the case, once you introduce MBAs/VCs, the focus shifts to ROI and fast. I see Deno Deploy as being part of that attempt.
People still tend to forget that software development tools are not commercially viable. For a long time we have become spoilt for choice with ever more and improving tools.
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.
Mostly because liability is only a thing in some areas, when programming becomes as scrutinised as other industries, and basic stuff like returns due to failed functionality are normal instead of "try to reboot it", security and quality will have other priority.
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.
It hardly matters on the enterprise space where projects live from LTS to LTS, and version upgrades only happen when someone allocates enough budget for a consultancy to come in and do some upgrade project.
These aren't the kind of folks rushing in to add Bun/Deno into their stacks.
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.
That might be because Bun doesn't need an editor extension. It has type definitions and works fine with the built-in TypeScript language server, formatter, etc.
Readit News
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.
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.
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.
Deleted Comment
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 currently work in the POS industry (day job) and Food Festival Payments (my business).
For me, when it's working, the Typescript development experience is bar-none for me. Typescript (Javascript) can run almost anywhere, or at least all the types of devices I would care about targeting. I enjoy using 1 language for backend and frontend development. I'm fully aware of the issues in the TS/JS ecosystem but I still really enjoy writing TS despite that. I feel like I get "tastes" of a perfect future where the issues I have are fixed and I hope the current state of affairs is just growing pains we look back on as we do the IE6 days (which I developed for, some people forgot how bad it used to be).
Being able to write backend, frontend (web, iOS, Android), all in the same language feels like a super power, especially when you can share code between them. Without Typescript (and Vue/Quasar) there is no way I'd be able to run by own company and support web/iOS/Android without cross-platform frameworks utilizing Typescript. I've written Java, I've written Swift, it's not that I can't write them it's just that I'm not good at either and I don't have the time to get better at either.
I haven't played much with other languages (aside from PHP, which I use for my day job) other than a todo/hello-world here and there because at the end of the day TS fills my needs and has something going for it that no other language does, it runs on the web natively. With WASM that might change (has changed?) but for now TS give me the best DX.
I'm not sure if that answers your question and I'm happy to expand further.
We ported our webapps from JS to Typescript a while back, and I hate having to read untyped code, even (maybe especially) the stuff written by our best coders, even my own code. You have to run the code in your head just to understand the shape of "order".
I would never go back, I cannot fathom the resistance in the JS community.
Personally, I loathe javascript but love typescript.
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).
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
Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
> 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.
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.
As is so often the case, once you introduce MBAs/VCs, the focus shifts to ROI and fast. I see Deno Deploy as being part of that attempt.
People still tend to forget that software development tools are not commercially viable. For a long time we have become spoilt for choice with ever more and improving tools.
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.
Deno is still better than node and its sort of a swiss army knife for developing servers in Typescript fast.
I’m biased but learning difficulty aside, Rust is very optimal as a language.
In general the lack of quality is a side effect of the lack of liability in many software fields, not the programming language that gets used.
That is pretty much the standard problem across programming.
In contrast, Deno gambled that Node compatibility wasn't critical and lost. Now they're backpedaling.
These aren't the kind of folks rushing in to add Bun/Deno into their stacks.