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)
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.
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.
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. :/
// from https://gist.github.com/kt3k/6123515ff5d1e167f82dfe4aa12ee5d9
import { JSDOM } from "https://jspm.dev/jsdom";
const doc = new JSDOM(`<!DOCTYPE html><p>Hello world</p>`);
console.log(doc.window.document.querySelector("p").textContent);
Run it like this: deno run 'https://gist.githubusercontent.com/kt3k/6123515ff5d1e167f82dfe4aa12ee5d9/raw/f27520c629e56ab6e53e411c455ecc289300bb28/jsdom-in-deno.ts'
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.
All of the simple cases I've tried seem to work fine, e.g:
import { JSDOM } from "npm:jsdom";
const dom = new JSDOM(
`<!DOCTYPE html><p>Hello world <img src="https://example.com/logo.svg" /></p>`,
);
console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world"
console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"
The NPM compatibility madness really does kill it for me. Probably something to do with taking VC money and “expanding addressable market” or whatever.
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
So NodeJS can do pretty much everything Deno can, but it also can do all the stuff it could already do.
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.
People think they are being gentle but it has the opposite effect now.
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.
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 (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.
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.
“We’re no longer building atoms, molecules and components, we’ve moved on to islands, continents and tectonic plates”
It powers my friend's canadian roasted coffee business website, available here: https://torque.cafe/en/
Then you don’t have to waste your energy reading corporate waffle.
Disruptors gonna disrupt even when broke AF and shutting down.
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.
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.
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.
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.
Imustaskforhelp•3h ago
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
sync•3h ago
Deno's Decline - https://news.ycombinator.com/item?id=43863937 - May 2025 (157 comments)
pjmlp•2h ago
Eventually the reference implementation gets the features that are more relevant, and we move on.
CharlesW•2h ago
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.
egglemonsoup•2h ago
CharlesW•2h ago
tough•2h ago
lambtron•2h ago