原创作者：庄晓立（LIIGO）
原创时间：2025年6月6日
原创链接：https://blog.csdn.net/liigo/article/details/148479884
版权所有，转载请注明出处！

相识

Deno，是Nodejs原开发者Ryan Dahl重新设计并组织开发的JS/TS运行时平台。

Fresh，是专用于Deno平台的基于Preact实现的WEB开发框架。

这二者都是小众项目。Deno甚至还不如后生小子Bun知名度大；Fresh更不用提了，听过的人很少。

考虑到Deno是破旧立新的开源项目（相对于Nodejs），再加上其传奇的设计师，以及使用Rust语言开发，它对我有天然的吸引力，我对它有天然的亲近感。从0.1到1.0到2.0，我一直关注着它的开发进展，始终报以期望。感觉他们一步一个脚印，开发进展还是很快很扎实的。

2023年初我有一个小项目要做微信公众号后台，技术选型时选到了Fresh，那是我第一次接触Fresh。当时觉得Rust/CSharp/Nodejs的方案都重，Fresh更轻量级。

选型Fresh起到决定性作用的是如下两篇Deno官方博客上的技术文章：

• You Don’t Need a Build Step （Fresh没有构建步骤）
• A Gentle Introduction to Islands （Fresh支持岛屿架构）

为了它我忍了类React/JSX前端（当时有偏见后来觉得真香）。后来又陆续用它做了几个小项目（部分日常使用至今），总体感觉这个Fresh很不错，开发和部署门槛都低，都好用。Fresh引导我首次接触React/Preact，JSX，useState()，我很感激它。

相离

使用Fresh过程中发现了它的一些小毛病，但也无伤大雅：

• 例1，React/Preact不支持双向数据绑定，需要手动监听表单事件读取新值赋值给状态变量。
• 例2，Fresh的各种handlers方法签名杂乱不一。
• 例3，JS中if-else是语句不是表达式不方便嵌入JSX。

部署至Deno Deploy时也遇到过一些棘手的维保问题，不提了，毕竟咱也不是付费用户。

前面说过“没有构建步骤”是Fresh吸引我的一大亮点，是我当初选用Fresh的决定性因素之一。可是2024年初，他们自己阉割了这一特性。让我说什么。我也忍了。

2023年底至2025年初这一年多时间里，Fresh没有实质开发进展。开发人员先是去做JSR，晾了Fresh几个月；回来后挖了个大坑（发起Fresh2），不久又去做Deno2，又晾了Fresh几个月；JSR和Deno2都完事后，依然没有回归开发Fresh2的任何迹象；几个月后才知道人家又被调去开发Deno Deploy新版啦，无语！持续关注一年半，我(LIIGO)几乎天天翻它的源码仓库啊，收获的只是一遍遍的失望。三番五次的被他们“耍”，你说我该不该爆粗口，再痴等傻等我是那个！至此已基本确定放弃关注Fresh。（当然我知道这是开源项目，不该有超出常规的企望。）

压倒骆驼的最后一根稻草来了。是Deno老大ry前些天发布的一篇辟谣文章，是对近期网络传言“DENO将死”的官方辟谣。读完这篇文章，居然给我一种“辟谣就是实锤”的颠倒感。在辟谣文中，他承认Deno Deploy最初可用全球部署区域是25个，高峰时高达35个，现在仅剩6个了。他解释为这是成本驱动（不挣钱只能压缩成本？）也是使用量驱动（用户跑了？）。他承认以前追求的边缘部署策略已被证实不合时宜（用户不买账呗？），需要重新设计实现。他承认DenoKV不算成功，将来可能要大改。他承认Fresh开发延宕太久让用户失望。再考虑到从Deno 1.0的“反Nodejs”到Deno 2.0的“完全兼容Nodejs”的一百八十度大转身，以上种种，似乎多处印证了这种感觉：他们的重大决策多有失误，数次押宝没押对。是时候反思他们的技术和产业前瞻性了。

2025年，我要远离Deno和Fresh。同时我也送上祝福，希望它们早日凤凰涅槃，卷土重来。希望将来有一天，我还会拥抱它们。