This site runs on Fresh 2 and Deno. I chose that stack deliberately, I shipped it, and I would not reach for it on most of the work that pays me. Both things are true at once, and the distance between them is the whole point of this article.
What Fresh gets right
Fresh is a pleasure to work in. Routing is the file system. The server renders first and ships almost no JavaScript. There is no build step standing between you and the page. You write something, you refresh, it is there.
There is a nostalgia to it that I do not think its fans talk about honestly enough. It feels like the web before we buried it under hydration and bundlers and a client-side router for a page with four links. That feeling is real, and it is worth something. It is not worth as much as people claim.
Where it stops working
The islands model is a bet. The bet is that most of your page is static and only a few pieces are interactive, so you ship JavaScript for those pieces and nothing else.
When the bet holds, Fresh is excellent. When it does not, you are working in handcuffs.
State is the first wall you hit. An island is an isolated root. Two islands that need to agree about something are two separate applications that happen to sit on the same page, and every solution to that is a workaround: a store outside the component tree, a custom event, a signal you thread through by hand. None of it is hard. All of it is friction that a normal React or Vue app never charges you.
Polling is the second wall. Anything that lives — a queue that updates, a job that reports progress, a dashboard that refreshes — wants a long-lived client with real state. That is precisely the shape the islands model is built to avoid.
Heavy DOM work is the third. Drag and drop, a canvas, a rich text editor, a virtualised table of ten thousand rows. These are not exotic requirements. They are Tuesday. And each one drags a bigger and bigger island onto a page that was supposed to be mostly static, until you are shipping a single-page app with extra steps.
The escape hatches cost more than they save
The Fresh and Deno teams know all of this, and their answer is flexibility: use npm packages, use React-compatible libraries inside your islands, use other runtimes.
I have used those escape hatches. They work, right up until they do not, and when they do not the failure is rarely a clean error message. It is a peer dependency resolving to a version nobody intended. It is a library that assumes a bundler you are not running. It is something that works locally and dies in the deploy because the module graph resolved differently there.
When you write code to make money, that is the worst possible class of problem. Not because it is unsolvable — because it is unbudgetable. A client does not pay you to spend a day discovering that a date picker assumes CommonJS. The last thing you want to spend time and money on is integrating a dependency that would have been five minutes anywhere else.
That is my real objection to Fresh in a commercial setting. Not that it is bad. That it asks you to commit to its way of shipping code, and business is where you least want to be committed to anything. Flexibility and adjustment are how the money is made.
Deno itself
Deno is great on paper. The security model is the right idea. TypeScript without a toolchain is genuinely nice. The standard library is coherent in a way Node's ecosystem never managed.
But I keep arriving at the same question and never finding an answer: why this instead of Node or Bun?
Node has everything, runs everywhere, and every developer you might hire already knows it. Bun gives you most of Deno's ergonomics — TypeScript, a good standard library, a fast install — while staying compatible with the ecosystem that already exists. Bun did not ask me to give anything up. Deno does, and I cannot name what I get back that is worth the trade.
Is the whole project a fantasy about replacing Node? I do not think the people building it are naive, and I think the goal is legitimate: Node carries a decade of decisions its own author regrets, and someone should try to do better. But replacement is not happening. Node is not a technology any more, it is infrastructure, and infrastructure does not get replaced because something newer is nicer. It gets replaced when it stops working, and Node works.
Astro does islands better
If you want the islands model, Astro executes the concept better than Fresh does. It is more abstract and far more agnostic: bring React, bring Svelte, bring Vue, bring nothing. The architecture is the product, not the runtime and not the framework's own component model.
That is the difference. Fresh asks you to adopt a philosophy. Astro sells you a technique and lets you keep your tools.
So is it worth it in 2026?
For a content site — a blog, a portfolio, documentation, marketing pages — Fresh is genuinely good and the performance is real. This site is exactly that shape, which is why it is built this way, and why I have not regretted it once.
For a product with state, live data, real interactivity, and a dependency list you did not personally audit, I would not choose it, and I would not put a client's budget behind it.
Fresh is not a toy and it is not a fantasy. It is a specialist tool being marketed as a general one. Knowing which of those you are holding is most of the job.