
经过不懈的努力,博客2.0也是初具雏形。初代博客陪我走过了一年的时间,现在,我想要赋予这个站点更强的玩具属性。即使我写不出文章,也能对博客进行各种各样的改动,满足我对各种新奇技术的探索。
关于Cloudflare
博客2.0的最大功臣,非“赛博菩萨”Cloudflare莫属,我在一个平台上就完成了几乎所有的作业。如果哪天,Cloudflare提供了代码托管的功能,我甚至可以不需要Github。
目前的站点的结构如下:
项目 | 框架 | 服务提供 |
---|---|---|
域名解析 | / | Cloudflare |
CDN与防护 | / | Cloudflare |
博客本体 | Astro | Cloudflare Pages |
评论系统 | twikoo-cloudflare | Cloudflare Workers+Cloudflare D1+Cloudflare R2 |
图床 | 无(未来或许是PicGo) | Cloudflare R2 |
Cloudflare CDN的可访问性不好,这是事实,但是这并不是Cloudflare的问题,我们没有理由奢求更多。最极端的情况,如果Cloudflare CDN在中国大陆完全不可访问,关闭Cloudflare的代理也能够缓解,不是什么大问题。
Cloudflare太过善良,以至于我很想为它做些什么,可惜Cloudflare目前不支持.top
域名,要不然我一定要转移域名到Cloudflare,以示感谢。
关于Astro
一年前的我非常排斥Node.js,因为江湖中总是流传着它的传说:“比黑洞更深不见底”的node_modules,感人的站点生成速度,还有版本管理地狱。但是在我与Go/Hugo相处的一年中,我确实也感受到了Node.js的优点,繁荣的生态、便利的包引入、大量的开发者与社区讨论。在一番挣扎后,我决定亲身体验它的好坏,毕竟调查过后才有发言权。
相比于最主流的Hexo,我选择了新生的Astro。作为后来者,Astro在设计上就强调了性能与易用,技术细节还有待了解,但至少目前的站点确实能让我感受到所言非虚。同时,作为新项目,Astro的生态和社区却意外成熟,这是开发者们对它的肯定。
在基础的使用体验上,我必须承认,Hugo太过优秀,以至于找不到对手。毫秒级的站点生成时间,100MB的小巧玲珑,模块式的部件替换,还有便利的主题功能。如果你是一位“建站新手”或“极简主义者”,我觉得Hugo一定能让你满意。相比之下,Astro笨重又缓慢。对于现在的站点,占地700MB、编译时间3分钟,简直不像是一个时代的产物。即使我使用Bun来提升效率,也改变不了Astro的先天缺陷。
相应的,我得到的是极强的拓展性与可玩性。Astro的“UI无关”理念,能让我随意取得他人的优秀组件与设计,而不必担心前端框架的移植。在Hugo与Blowfish中需要自行获取的图标,在Node.js与Astro这里,只需简单的一句import。唯一的小遗憾,就是我心心念念的Bangumi组件,没办法直接引入,最后还是要靠我自行实现。npm里的bangumi包,迷惑性真是太强了。
关于Fuwari
讨论主题前,我必须要吐槽Astro对主题功能的设计。Astro提出的主题功能,耦合度极高,不如说它是“框架”、“手脚架”。所有的修改与个性化,都直接在原有代码上执行,而不是像Hugo一样,提供一种Overlay功能,能让用户在不触碰原有代码的情况下实现修改。对于熟悉Git操作的用户,还可以通过cherry-pick
和rebase
进行同步,而对于我这种只会add
、commit
、push
三板斧的普通用户,想要同步上游真是令人头疼。
最后,我选择将主题添加为子模块,然后手动同步所需的代码,勉强解决了与主题上游同步的问题。
说回主题,我选择了Astro社区中比较出名的Fuwari,它在设计与性能方面表现都相当不错,也难怪使用者众多。我上手Fuwari的第一感受就是:“它真好看”,大量的过渡动画、统一的圆角和块状设计、还有自定义主题色,比Blowfish精致太多。
Fuwari最大的问题是开发进度缓慢,尤其是作者相当坚持自己的美学,很多小细节都希望自己设计。慢工出细活我倒是不反感,但是一些最基本的功能,例如评论系统,都没有完成的情况下,缓慢的开发确实让我有些心急。
博客的很多功能,都来自社区的二次开发,包括评论系统和友链页,感谢他们的贡献,让Fuwari的可用度高了很多。
关于Twikoo
站点的评论区是变动最频繁的部分,目前我的选择是twikoo-cloudflare,这也是Cloudflare生态下的唯一选择。其他的评论系统,例如MiniValine或基于Cloudflare Workers实现的原生评论系统,从可持续性的角度看,都不如twikoo-cloudflare。
非常诡异的一点是,Waline和Twikoo作为最流行的两大评论系统,竟然没有数据迁移的直接途径。最后不得已,我选择手工录入先前的评论,可能会出现意料外的问题,但是能保全数据,也无所谓了。
Astro+Fuwari之后?
相比于先前对迁移的热情,我必须要说,翻新一个已经存在大量数据的站点是一件很耗费时间和精力的事情;而且Astro与Fuwari的组合也足够好玩,实在是没有必要再“搬运”我的博客。
曾经我对Zola有着谜之执着,但是在听说Zola开发者的独裁与固执后,这份执念也消散了。一个流行的软件,一定是适应大多数人的需求、符合大部分人习惯的优秀产品,Zola声称自己比Hugo优秀,结果在功能性和生态远远不及,实在是很难说服我这位前Hugo用户再去尝试Zola。
在决定使用Bun进行开发前,我首先了解的是Deno,毕竟“Deno, the next-generation JavaScript runtime”的口号很响亮,Deno还附带了官方开发的框架Fresh。我就曾计划使用Deno+Fresh的组合,进行一次全新的、跨时代的站点建设,可惜我高估了自己的实力。没有了主题之类的预设功能,从零开始开发一个站点真是寸步难行。
虽说计划失败了,但是不代表我会就此放弃,目前我唯有期待,Fresh也能有简化开发的功能出现。