I think there’s a universe in which Deno took off but it’s clearly not ours. I’m inclined to believe this is because what Deno is trying for, a more mature standards based and security focused version of the JavaScript ecosystem, isn’t what people use JavaScript for. Makes me sad because I really appreciate what they are trying to do.
By far my biggest issue with Node is the dependency on the fragile NPM ecosystem. I could be wrong but I think if Deno had tackled this problem head-on it would have become more popular.
Provide a framework or built-in libs which allow you to build a number of use cases (JSON API, etc) with as little dependencies as possible. That would be something much more valuable than becoming a Node replacement for the NPM ecosystem.
Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.
> Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.
These days there's almost nothing you can't do in Deno that you can do in Node. If you think there is, please reply here but I think that time has passed.
The thing I ran into today was jsdom not seeming to work at all in Deno.
My use case was trying to run Playwright to scrape a site, copy the resultant HTML into jsdom, then run Mozilla's `readability` module on that to get a summary of the page. I found a replacement for Playwright (astral), and `readability` seems to be runtime agnostic as long as it has access to DOM APIs, but jsdom doesn't work with Deno yet.
I'd love to hear if there's an alternative to jsdom that I could use, because I unfortunately can't switch entirely over to NodeJS in this particular project, so either I find a replacement server-side DOM library, or I need to juggle two runtimes for different parts of the project. :/
Earlier today, it was producing an error that looked as if it couldn't render some elements. Unfortunately, I switched to a different branch where I tried to switch certain things over to Node, and now when I've switched back, there's a different error, now in the `readability` module, but still connected to its use of jsdom. It looks like it could be due to version mismatches — maybe readability requires a different version of JSDOM to the one installed by default — but now I'm trying to downgrade the currently installed version of JSDOM, and that doesn't seem to work — the version in deno.lock is stubbornly staying at the later version, despite having specified an older version in the `deno.jsonc` (and that older version appearing in the `workspace.dependencies` array at the bottom of the lock file).
I'll try again with a clearer head tomorrow, and maybe if I figure stuff out I can create a proper reproduction, but right now I don't know how to reproduce anything because it doesn't seem like my local environment is consistently reproducible, let alone trying to create something that would work on other machines. I'm surprised at how poor this behaviour is — I thought a big part of Deno@2 was to fix these sorts of dependency issues.
That is the big issue with all these alternative implementations, I don't want to bother with compatibility issues, when I can use the original instead, including in regards to native modules tooling.
One of the original selling points of Deno seemed to be that it didn’t use NPM. It would build its own broadly useful and good standard library.
The NPM compatibility madness really does kill it for me. Probably something to do with taking VC money and “expanding addressable market” or whatever.
I don't think it's that complicated, in my mind it's as simple as the fact that the npm/node ecosystem is huge and not supporting it at all means having to reinvent each and every library that exists there. That is a huge task and in my experience, the lack of support for npm/node packages (used to) really hamper deno's usefulness.
Now you can tap into the npm ecosystem when needed, but still use deno-first libraries as you please. If you don't like npm, then you can ignore it entirely
But that’s exactly what I’m saying, a big selling point WAS reinventing things. There would be a stdlib “http” package for all HTTP client needs, an “orm” package, and so on. This is how I remember Deno being sold many years ago, and I thought it was a noble cause.
I think Deno has done a good job pushing the ecosystem forwards, but I think it has the problem that anything it can do, NodeJS can also implement. Since Deno, NodeJS now follows most browser standards, also allows running Typescript natively, has a built-in test runner, and even has a similar permissions system to Deno (albeit behind an additional flag). I believe it can even import JSR modules if configured correctly.
So NodeJS can do pretty much everything Deno can, but it also can do all the stuff it could already do.
Haven't really been using Fresh; I feel like whenever I get into the blending of client/server with these ecosystems, things get real muddy real fast. Mostly been doing either sites (mostly fully ssr with Hono + very light vanilla), or fully client-rendered web pwas (solid or mithril).
Deno itself, though, is still a very comfy js environment. I pretty much use it for all js/ts that doesn't run in the browser (I also use it for build steps of said browser code). It just kinda has everything I need/want, so I don't have to add too many dependencies, and don't have to muck around in build/env stuff. Just feels kinda easy.
I was runtime/ecosystem hopping recently, trying to find a something that'll make me more comfortable in building RESTful crud + auth services.
I (tried) buildinv the same service in Go, Node(Fastify), Deno(Hono) and Rust (Axum).
Honestly my worst experience was with Deno. It's being built and shipped so fast even the fragmentation doesn't make sense. Some packages are on JSR and others on their own registry. Some NPM packages could be found on JSR but they'd be very out of date, locating docs was very difficult for those individual packages. The new deno.json format was very confusing, was it opt-in or wasn't it. Compatibility may have been fixed but I couldn't get too far with building because of the difficulty in finding upto date packages. They abandoned their own postgres client, which isn't on JSR either.
Now compare that with Rust, which doesn't have anything in it's std-lib to help you connect to a database, setup an HTTP server. However the ecosystem is cohesive enough, maybe partly due to tokio, that you could stumble your way to a recently/library maintained example project on GitHub.
At the end of it I honestly did not see much of a benefit to my development experience shifting to Deno. Projects where I could see some of those devex improvements are too large to migrate.
huh, I mean idk experiences differ. My main project's service is written in Rust/Axum, and I enjoy it a lot. But I thought it was actually kind of frustrating to find that combination; Axum was the 3rd http client I tried, after the first two failed me in different ways. If I had started with the https client first and hadn't already felt good about building the codebase in Rust, I might have just gotten annoyed and moved on. First impressions can sometimes skew the perspective a little.
fwiw, re finding up-to-date packages, you can also pull in npm dependencies. idk what you found confusing about the deno.json, but it's definitely optional; you can just write imports directly in the .js file if you want. I often make single-file scripts to run some npm package over a local file.
That's the issue, Deno wasn't my first impression of typescript for the backend. Every decision I was took, there was a voice in the back of my head whispering, "it's probably easier on node". Not the actual code, but getting information about how to actually achieve those things.
The problem with making something as important as a package file optional it makes it very confusing for new users to get started because a variety of tutorials and getting started guides end up having a lot variation between them.
I mean... I find deno.json-less scripts to be incredibly convenient for creating single-file scripts, and I've found deno configuration to be pretty clear. You're not wrong for disliking Deno; it has opinions, and those can turn people off. But I happen to find those opinions and decisions to be quite convenient and useful for me.
How would you rate the rest of the items in this experiment? Could you rank them based on "pleasure to work with", speed, stability, suitability for large projects, etc?
*shudder* vivid memories of my one week trying RoR right after Rails 8 was released...
What is Turbolinks? What is Sprockets? How does it relate to Turbo Frames or Turbo Streams? Is it different from Turbo or a part of it? Is it an addon? What are Cables? Why Action Cable? Is it different from Hotwire? Is it the same? Should we take Webpacker, Shakapacker — or Propshaft, after all? Do we use Puma or Unicorn? Devise, CanCanCan, Pundit? Poltergeist, Cucumber, Capybara. PaperTrail, Zeitwerk, Apartment. Fuck me, Rails.
I am not sure, deno seems really bleak as I had read the HN post about deno actively shrinking its datacenters and fresh activity.
This seems an attempt to show to the world that its not that, but I would say that it's still not working.
Deno deploy, their product is better on supabase or even bunny cdn which provides more locations than deno itself.
Bun also exists. And did we forget about node itself?
Cloudflare workers is a beast if we can work with non standards/ I personally feel a little bit that some code meant for node won't work on cf as much as it would on deno
hey Andy from Deno here. thanks for your comment. we reduced our Deno Deploy regions not because Deno is in decline. (in fact we have seen about 2x adoption since release of Deno 2.) it's just that we noticed more users using Deno Deploy for hosting applications vs. edge functions, which was our original vision for Deploy. in many scenarios, application performance is improved with fewer, more highly trafficked regions vs. many spread out but more idle regions. we will be covering that in more detail in a dedicated blog post next week.
Wow! Didn't expect anyone from Deno team to respond. I just thought I was shouting stuff in the void for my fellow HN people at most reading it.
Thanks for the clarification.
I have some questions though:-
Aside from the fact that deno allows npm compatibility, how is deno deploy any better than cloudflare hosting which I currently use, since cloudflare workers also have some compatibility layer I suppose and cloudflare workers can and do host applications and edge functions both.
I can understand if things like nextjs which don't run as smoothly on cf workers, if at all (I haven't tried them but I do know that its easier to run nextjs on vercel than any other competitor), but nextjs can run easily on deno, so that might be a really big niche tbh
But as a sveltekit user, here's my opinion
I have deployed so many sveltekit websites to cloudflare workers, 100k limit never disappoints me or limits me, cf workers also has a kv which is good for simple databases. I am seriously considering to always use cloudflare workers since currently I am just a student and it gives me 100k requests per month limit and after that its still really really cheap.
I had compared deno's tier and cf tier's sometime ago and cf was the winner there, I don't know what's the situation now but I am willing to hear.
Cf workers wrangler developer-experience is genuinely decent in my opinion, not as easy as deno deploy I suppose but still its worth it given all the previous points.
Deno is really nice compared to node, I in fact was the guy who watched fireship video and then the deno video itself and then I legit went to my brother's room knocking on his door (my brother is also a coder, in fact he knows his stuff whereas I am just this 16 year old student) and I legit wanted him to try out deno. But I am having mixed opinions now and I don't mean any defamation of deno team who are really nice and kind for what I've seen.
Have a really nice day Andy. Hope deno achieves success.
There are plenty of moribund open source projects. But looking at this month's 2.3 release, Deno's future strikes me as the opposite of bleak.
As for Deno Deploy, sure —¹ it may fail. But regarding the Deno folks scaling their footprint in response to changes like real-world usage patterns, adoption timelines, our rapidly-contracting economy, or whatever, that's a far better response than ostriching in the longer run.
¹ This em-dash was lovingly hand-crafted by a Mac user. Please don't em-shame.
I meant deno's future as of how the company would survive with competitors/ the ecosystem growing and node adopting. Because the company is basically the only one "really" working on the product, if the company can't find a decent source of revenue, (I am not sure "what" is the product that deno sells that others can't / aren't selling already ie. bunny cdn / supabase hosting deno subhosting)
I would love deno to win, maybe be even faster than bun and maybe help with permissions a little bit more as I played around with deno scripts and it quickly devolved into a permission nightmare from my personal experience, maybe I am inexperienced, but I didn't had the issues in bun.
Same, my typographically-savvy friend. This "dead giveaway" too shall pass — first it was certain words, today it's em-dashes, and tomorrow we'll be forced to introduce grammatical errors.
I might add it in the original comment attributing it to you as well. Thanks again.
Edit: wait I can't edit my original comment, I think it might be because its already commented on by people, so yeah this is the only way for people to find out about it.
Yes, I think that is why I had written "have we forgotten about node" because most people seem to forget node given deno/bun (including "me"), so Of course, node won't have deno or bun occupy its market share and it would also add those features.
Its a net positive for everybody except the people who are working in alternative implementations unless they are being sponsored or they are doing it for fun.
As a company, I am sorry, but I just see no ways of pure revenue once node improves
Scroll down to "Stream HTML straight from the server" -> Click "Lemonade" recipe link -> Click "Learn more about Partials" Button -> Press back button -> Press back button again -> Press forward button = The raw Lemonade recipe HTML partial gets rendered instead of the full page.
I believe that Fresh is pretty ideal for AI-paired web development since so much information about the application structure is easily parsable just by iterating through the file system (routes are folders and files). I have been using Claude Desktop MCP server with Fresh 1.0 and Claude can "read" the application pretty well.
I’ve been checking every couple weeks for a status update on Fresh for the last six months (others have been checking longer, it’s a vocal set of early adopters on GH and discord!).
I’m not even sure I’d have confidence in adopting Fresh, but I definitely was using it as a canary for the Deno org’s health. If they can’t maintain their flagship front end framework, after all, they must be circling the drain?
If that’s not the situation, I’m bewildered by their approach to communication.
Anyway, I’m still left wondering if Deno will be around in 18mo. It’s generally a nice DX, but so risky to bet on. I want them to succeed, but fear they won’t.
Considering Fresh as an option for a project I found it baffling (to say the least) that it had shipped an 1.0 with Tailwind as the only option for styling and even more that 2.0 is not even starting to address the topic.
Hiya. No questions but just an fyi: the version of `@fresh/init` mentioned in the article (`2.0.0-alpha.30`) fails to run. Looks like latest at this time (`2.0.0-alpha.33`) runs successfully.
As a hobbyist programmer, I’m wondering how the Open Telemetry support would be useful to me? I’ve read about tools like Grafana on Hacker News, but never installed any of them.
Using Fresh (v1) for a commercial project, mostly SSR with a very few islands. So far it has been great for my productivity and it’s reasonably fast for our purposes (we run it on a VPS, not Deno Deploy)
On a meta level: after decades of VC-speak overuse on the internet any headline that says "An update on Thing" reads as "We are shutting Thing down". So, people who decide not to read this article may simply assume that this is another piece of bad news about Deno.
It is not: the post talks about the development progress of their web framework, which seems to be their take on server-rendered pages with islands of interactivity. Kinda like Astro or maybe like Remix.
Please do not title your posts "An Update On X" if you aren't shutting it down. You can blame the SV startups for the connotation but that's where we're at now. But in this case, I guess it has worked as a form of clickbait :)
Well, in an ideal world, _everyone_ would be using informative headlines, regardless of whether they are shutting things down or not.
For this post in particular, "An Early Look at Fresh 2" would make a better title, albeit with less "clickbait potential" (well, people love drama). With a "An Update on X" headline you both fail to inform and give the impression that you are killing the thing.
Why is it harder to ask people who are shutting down to be explicit in their headlines? rather than telling all the people who aren’t shutting down to change their headlines?
Asking is easy, but they don't have a big incentive to make it clear up front that they're shutting down. Whereas the people who aren't shutting down do have a clear incentive to make sure that people don't think they're shutting down.
Unfortunately, history is littered with linguistic treadmills for concepts people don’t like to say. We destroyed our singular “you” like this, I don’t think we’re going to stop to save “an update on {thing}”.
> Please do not title your posts "An Update On X" if you aren't shutting it down.
The number of folks who would infer that is a fraction of a fraction of those who wouldn't, so please do keep titling status updates appropriately, as is done here.
I think there’s a universe in which Deno took off but it’s clearly not ours. I’m inclined to believe this is because what Deno is trying for, a more mature standards based and security focused version of the JavaScript ecosystem, isn’t what people use JavaScript for. Makes me sad because I really appreciate what they are trying to do.
Bun is really taking their lunch with a more simpler USP, "Faster"
By far my biggest issue with Node is the dependency on the fragile NPM ecosystem. I could be wrong but I think if Deno had tackled this problem head-on it would have become more popular.
Provide a framework or built-in libs which allow you to build a number of use cases (JSON API, etc) with as little dependencies as possible. That would be something much more valuable than becoming a Node replacement for the NPM ecosystem.
Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.
> Deno seems to be spending a lot of time and money into Node compat which so far (afaik) hasn't produced results.
These days there's almost nothing you can't do in Deno that you can do in Node. If you think there is, please reply here but I think that time has passed.
The thing I ran into today was jsdom not seeming to work at all in Deno.
My use case was trying to run Playwright to scrape a site, copy the resultant HTML into jsdom, then run Mozilla's `readability` module on that to get a summary of the page. I found a replacement for Playwright (astral), and `readability` seems to be runtime agnostic as long as it has access to DOM APIs, but jsdom doesn't work with Deno yet.
I'd love to hear if there's an alternative to jsdom that I could use, because I unfortunately can't switch entirely over to NodeJS in this particular project, so either I find a replacement server-side DOM library, or I need to juggle two runtimes for different parts of the project. :/
Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues) with some details and a reproduction?
All of the simple cases I've tried seem to work fine, e.g:
Earlier today, it was producing an error that looked as if it couldn't render some elements. Unfortunately, I switched to a different branch where I tried to switch certain things over to Node, and now when I've switched back, there's a different error, now in the `readability` module, but still connected to its use of jsdom. It looks like it could be due to version mismatches — maybe readability requires a different version of JSDOM to the one installed by default — but now I'm trying to downgrade the currently installed version of JSDOM, and that doesn't seem to work — the version in deno.lock is stubbornly staying at the later version, despite having specified an older version in the `deno.jsonc` (and that older version appearing in the `workspace.dependencies` array at the bottom of the lock file).
I'll try again with a clearer head tomorrow, and maybe if I figure stuff out I can create a proper reproduction, but right now I don't know how to reproduce anything because it doesn't seem like my local environment is consistently reproducible, let alone trying to create something that would work on other machines. I'm surprised at how poor this behaviour is — I thought a big part of Deno@2 was to fix these sorts of dependency issues.
JSDOM works on Deno. Here's a script:
Run it like this: This returns "Hello world" on my machine, deno 2.3.1I'd need more info about your problem but I'm not convinced that Deno's the problem and if there is one.
That is the big issue with all these alternative implementations, I don't want to bother with compatibility issues, when I can use the original instead, including in regards to native modules tooling.
One of the original selling points of Deno seemed to be that it didn’t use NPM. It would build its own broadly useful and good standard library.
The NPM compatibility madness really does kill it for me. Probably something to do with taking VC money and “expanding addressable market” or whatever.
I don't think it's that complicated, in my mind it's as simple as the fact that the npm/node ecosystem is huge and not supporting it at all means having to reinvent each and every library that exists there. That is a huge task and in my experience, the lack of support for npm/node packages (used to) really hamper deno's usefulness.
Now you can tap into the npm ecosystem when needed, but still use deno-first libraries as you please. If you don't like npm, then you can ignore it entirely
But that’s exactly what I’m saying, a big selling point WAS reinventing things. There would be a stdlib “http” package for all HTTP client needs, an “orm” package, and so on. This is how I remember Deno being sold many years ago, and I thought it was a noble cause.
> If you don't like npm, then you can ignore it entirely
But what if Deno had invested all that Node compat effort into something else?
I think Deno has done a good job pushing the ecosystem forwards, but I think it has the problem that anything it can do, NodeJS can also implement. Since Deno, NodeJS now follows most browser standards, also allows running Typescript natively, has a built-in test runner, and even has a similar permissions system to Deno (albeit behind an additional flag). I believe it can even import JSR modules if configured correctly.
So NodeJS can do pretty much everything Deno can, but it also can do all the stuff it could already do.
Haven't really been using Fresh; I feel like whenever I get into the blending of client/server with these ecosystems, things get real muddy real fast. Mostly been doing either sites (mostly fully ssr with Hono + very light vanilla), or fully client-rendered web pwas (solid or mithril).
Deno itself, though, is still a very comfy js environment. I pretty much use it for all js/ts that doesn't run in the browser (I also use it for build steps of said browser code). It just kinda has everything I need/want, so I don't have to add too many dependencies, and don't have to muck around in build/env stuff. Just feels kinda easy.
I was runtime/ecosystem hopping recently, trying to find a something that'll make me more comfortable in building RESTful crud + auth services.
I (tried) buildinv the same service in Go, Node(Fastify), Deno(Hono) and Rust (Axum).
Honestly my worst experience was with Deno. It's being built and shipped so fast even the fragmentation doesn't make sense. Some packages are on JSR and others on their own registry. Some NPM packages could be found on JSR but they'd be very out of date, locating docs was very difficult for those individual packages. The new deno.json format was very confusing, was it opt-in or wasn't it. Compatibility may have been fixed but I couldn't get too far with building because of the difficulty in finding upto date packages. They abandoned their own postgres client, which isn't on JSR either.
Now compare that with Rust, which doesn't have anything in it's std-lib to help you connect to a database, setup an HTTP server. However the ecosystem is cohesive enough, maybe partly due to tokio, that you could stumble your way to a recently/library maintained example project on GitHub.
At the end of it I honestly did not see much of a benefit to my development experience shifting to Deno. Projects where I could see some of those devex improvements are too large to migrate.
huh, I mean idk experiences differ. My main project's service is written in Rust/Axum, and I enjoy it a lot. But I thought it was actually kind of frustrating to find that combination; Axum was the 3rd http client I tried, after the first two failed me in different ways. If I had started with the https client first and hadn't already felt good about building the codebase in Rust, I might have just gotten annoyed and moved on. First impressions can sometimes skew the perspective a little.
fwiw, re finding up-to-date packages, you can also pull in npm dependencies. idk what you found confusing about the deno.json, but it's definitely optional; you can just write imports directly in the .js file if you want. I often make single-file scripts to run some npm package over a local file.
That's the issue, Deno wasn't my first impression of typescript for the backend. Every decision I was took, there was a voice in the back of my head whispering, "it's probably easier on node". Not the actual code, but getting information about how to actually achieve those things.
The problem with making something as important as a package file optional it makes it very confusing for new users to get started because a variety of tutorials and getting started guides end up having a lot variation between them.
I mean... I find deno.json-less scripts to be incredibly convenient for creating single-file scripts, and I've found deno configuration to be pretty clear. You're not wrong for disliking Deno; it has opinions, and those can turn people off. But I happen to find those opinions and decisions to be quite convenient and useful for me.
How would you rate the rest of the items in this experiment? Could you rank them based on "pleasure to work with", speed, stability, suitability for large projects, etc?
I struggle to keep up with all the cutesy names for design patterns that seem to change every other year in frontend and JS-based ‘full stack’ setups.
“We’re no longer building atoms, molecules and components, we’ve moved on to islands, continents and tectonic plates”
*shudder* vivid memories of my one week trying RoR right after Rails 8 was released...
What is Turbolinks? What is Sprockets? How does it relate to Turbo Frames or Turbo Streams? Is it different from Turbo or a part of it? Is it an addon? What are Cables? Why Action Cable? Is it different from Hotwire? Is it the same? Should we take Webpacker, Shakapacker — or Propshaft, after all? Do we use Puma or Unicorn? Devise, CanCanCan, Pundit? Poltergeist, Cucumber, Capybara. PaperTrail, Zeitwerk, Apartment. Fuck me, Rails.
I am not sure, deno seems really bleak as I had read the HN post about deno actively shrinking its datacenters and fresh activity.
This seems an attempt to show to the world that its not that, but I would say that it's still not working.
Deno deploy, their product is better on supabase or even bunny cdn which provides more locations than deno itself.
Bun also exists. And did we forget about node itself?
Cloudflare workers is a beast if we can work with non standards/ I personally feel a little bit that some code meant for node won't work on cf as much as it would on deno
hey Andy from Deno here. thanks for your comment. we reduced our Deno Deploy regions not because Deno is in decline. (in fact we have seen about 2x adoption since release of Deno 2.) it's just that we noticed more users using Deno Deploy for hosting applications vs. edge functions, which was our original vision for Deploy. in many scenarios, application performance is improved with fewer, more highly trafficked regions vs. many spread out but more idle regions. we will be covering that in more detail in a dedicated blog post next week.
Wow! Didn't expect anyone from Deno team to respond. I just thought I was shouting stuff in the void for my fellow HN people at most reading it.
Thanks for the clarification.
I have some questions though:-
Aside from the fact that deno allows npm compatibility, how is deno deploy any better than cloudflare hosting which I currently use, since cloudflare workers also have some compatibility layer I suppose and cloudflare workers can and do host applications and edge functions both.
I can understand if things like nextjs which don't run as smoothly on cf workers, if at all (I haven't tried them but I do know that its easier to run nextjs on vercel than any other competitor), but nextjs can run easily on deno, so that might be a really big niche tbh
But as a sveltekit user, here's my opinion I have deployed so many sveltekit websites to cloudflare workers, 100k limit never disappoints me or limits me, cf workers also has a kv which is good for simple databases. I am seriously considering to always use cloudflare workers since currently I am just a student and it gives me 100k requests per month limit and after that its still really really cheap.
I had compared deno's tier and cf tier's sometime ago and cf was the winner there, I don't know what's the situation now but I am willing to hear.
Cf workers wrangler developer-experience is genuinely decent in my opinion, not as easy as deno deploy I suppose but still its worth it given all the previous points.
Deno is really nice compared to node, I in fact was the guy who watched fireship video and then the deno video itself and then I legit went to my brother's room knocking on his door (my brother is also a coder, in fact he knows his stuff whereas I am just this 16 year old student) and I legit wanted him to try out deno. But I am having mixed opinions now and I don't mean any defamation of deno team who are really nice and kind for what I've seen.
Have a really nice day Andy. Hope deno achieves success.
> I am not sure, deno seems really bleak…
There are plenty of moribund open source projects. But looking at this month's 2.3 release, Deno's future strikes me as the opposite of bleak.
As for Deno Deploy, sure —¹ it may fail. But regarding the Deno folks scaling their footprint in response to changes like real-world usage patterns, adoption timelines, our rapidly-contracting economy, or whatever, that's a far better response than ostriching in the longer run.
¹ This em-dash was lovingly hand-crafted by a Mac user. Please don't em-shame.
I meant deno's future as of how the company would survive with competitors/ the ecosystem growing and node adopting. Because the company is basically the only one "really" working on the product, if the company can't find a decent source of revenue, (I am not sure "what" is the product that deno sells that others can't / aren't selling already ie. bunny cdn / supabase hosting deno subhosting)
I would love deno to win, maybe be even faster than bun and maybe help with permissions a little bit more as I played around with deno scripts and it quickly devolved into a permission nightmare from my personal experience, maybe I am inexperienced, but I didn't had the issues in bun.
I don't want to live in a world where we have to add footnotes when using em dashes
Same, my typographically-savvy friend. This "dead giveaway" too shall pass — first it was certain words, today it's em-dashes, and tomorrow we'll be forced to introduce grammatical errors.
hey now typos make you authentic, that's a plus
1337$|"33|< ph7\^/
The HN post referenced in case others missed it:
Deno's Decline - https://news.ycombinator.com/item?id=43863937 - May 2025 (157 comments)
Thanks a lot!
I might add it in the original comment attributing it to you as well. Thanks again.
Edit: wait I can't edit my original comment, I think it might be because its already commented on by people, so yeah this is the only way for people to find out about it.
I have been around for a bit, until now being a laggard in alternative implementations has always paid off.
Eventually the reference implementation gets the features that are more relevant, and we move on.
Yes, I think that is why I had written "have we forgotten about node" because most people seem to forget node given deno/bun (including "me"), so Of course, node won't have deno or bun occupy its market share and it would also add those features.
Its a net positive for everybody except the people who are working in alternative implementations unless they are being sponsored or they are doing it for fun.
As a company, I am sorry, but I just see no ways of pure revenue once node improves
A bit of Deno trivia: it runs the big "Chicago Brick" video wall in Google's main office in Fulton Market; they open-source the code here:
https://github.com/google/chicago-brick
(I contributed a little "Penrose-tile" module during my time there, though I never got it in production :P)
Cool. Do you know of any recorded video of the video wall in action? I wasn't able to find any.
I can't find one either! Here's a 10-year-old article with a picture of it, though it looks slightly different now: https://www.dnainfo.com/chicago/20151204/west-loop/long-awai...
The Fresh home page has a routing bug on it (https://fresh.deno.dev)
Scroll down to "Stream HTML straight from the server" -> Click "Lemonade" recipe link -> Click "Learn more about Partials" Button -> Press back button -> Press back button again -> Press forward button = The raw Lemonade recipe HTML partial gets rendered instead of the full page.
Or just go here straight from this link: https://fresh.deno.dev/recipes/lemonade
Maybe they should add some logic to prevent being able to load partials as their own page.
Super excited about Fresh 2.0
I believe that Fresh is pretty ideal for AI-paired web development since so much information about the application structure is easily parsable just by iterating through the file system (routes are folders and files). I have been using Claude Desktop MCP server with Fresh 1.0 and Claude can "read" the application pretty well.
Fresh is awesome. I have a couple of commercial products running it right now and I find it very fast to develop with.
It powers my friend's canadian roasted coffee business website, available here: https://torque.cafe/en/
I’ve been checking every couple weeks for a status update on Fresh for the last six months (others have been checking longer, it’s a vocal set of early adopters on GH and discord!).
I’m not even sure I’d have confidence in adopting Fresh, but I definitely was using it as a canary for the Deno org’s health. If they can’t maintain their flagship front end framework, after all, they must be circling the drain?
If that’s not the situation, I’m bewildered by their approach to communication.
Anyway, I’m still left wondering if Deno will be around in 18mo. It’s generally a nice DX, but so risky to bet on. I want them to succeed, but fear they won’t.
Happy to answer any questions :)
Considering Fresh as an option for a project I found it baffling (to say the least) that it had shipped an 1.0 with Tailwind as the only option for styling and even more that 2.0 is not even starting to address the topic.
Can you comment on the topic?
Hiya. No questions but just an fyi: the version of `@fresh/init` mentioned in the article (`2.0.0-alpha.30`) fails to run. Looks like latest at this time (`2.0.0-alpha.33`) runs successfully.
Thank you! We fixed it.
As a hobbyist programmer, I’m wondering how the Open Telemetry support would be useful to me? I’ve read about tools like Grafana on Hacker News, but never installed any of them.
Using Fresh (v1) for a commercial project, mostly SSR with a very few islands. So far it has been great for my productivity and it’s reasonably fast for our purposes (we run it on a VPS, not Deno Deploy)
On a meta level: after decades of VC-speak overuse on the internet any headline that says "An update on Thing" reads as "We are shutting Thing down". So, people who decide not to read this article may simply assume that this is another piece of bad news about Deno.
It is not: the post talks about the development progress of their web framework, which seems to be their take on server-rendered pages with islands of interactivity. Kinda like Astro or maybe like Remix.
I was definitely expecting it to be an incredible journey before clicking.
You hit the nail on the head. I actually came to the comments to check my assumption that this was about a “rebrand” before reading the article
I feel the same way when I get an email with a vague subject - it's bad news and someone is quitting.
People think they are being gentle but it has the opposite effect now.
A Fresh update
Please do not title your posts "An Update On X" if you aren't shutting it down. You can blame the SV startups for the connotation but that's where we're at now. But in this case, I guess it has worked as a form of clickbait :)
I think the opposite would be better: get startups to rip the bandaid off and title their posts: “We’re shutting down.”
Then you don’t have to waste your energy reading corporate waffle.
Well, in an ideal world, _everyone_ would be using informative headlines, regardless of whether they are shutting things down or not.
For this post in particular, "An Early Look at Fresh 2" would make a better title, albeit with less "clickbait potential" (well, people love drama). With a "An Update on X" headline you both fail to inform and give the impression that you are killing the thing.
That would be a way better outcome, but there's also not much we can do to prevent that.
Why is it harder to ask people who are shutting down to be explicit in their headlines? rather than telling all the people who aren’t shutting down to change their headlines?
Asking is easy, but they don't have a big incentive to make it clear up front that they're shutting down. Whereas the people who aren't shutting down do have a clear incentive to make sure that people don't think they're shutting down.
You aren't from around here, are you? /s
Disruptors gonna disrupt even when broke AF and shutting down.
Unfortunately, history is littered with linguistic treadmills for concepts people don’t like to say. We destroyed our singular “you” like this, I don’t think we’re going to stop to save “an update on {thing}”.
> Please do not title your posts "An Update On X" if you aren't shutting it down.
The number of folks who would infer that is a fraction of a fraction of those who wouldn't, so please do keep titling status updates appropriately, as is done here.