个人博客从Hexo到React手搓的近十年

Wordpress 时期

16 年初买过阿里云的学生服务器做 wordpress 博客,还搞了域名备案什么的,最后上面只发了课堂 Linux 笔记。当时一搜自建博客都推荐wordpress。到 16 年后半年时在网上看到 Github Pages ,不要服务器还可以绑域名,竟然有这等好事!从此开始了 Hexo 的静态博客之路。

Hexo Hugo

后来换成了 Hugo。用 Go 写的编译比 Hexo 快多了,有比较现代化的主题。但感觉好多喜欢的模板都在 Hexo 上,又换了回去。

我自己是喜欢功能很全的极简风,网站装修这种东西,弄久了就是想手搓。再往后学了 React,但当时做了个 SPA 后发现,这对搜索引擎不友好。Next.js 的出现打破了这个问题,可以导出静态页面,当时觉得简直是魔法。从此走上了手撮博客的道路。

Next.js

手搓博客大致要求是:

  • 博客主体完全静态
  • 完全兼容 Hexo 用法
  • 有无限滚动的说说页面
  • 有评论阅览量统计
  • 有站内全文搜索
  • 有 rss 和 sitemap

技术选型参考的 Josh WComeau 文章。当时他看好 Styled-Components 和 Mdx(老实说现在觉得是个错误,一是还是要自己做 CSS 水合避免闪屏,二是,写文章时真的不会想写代码,图片都懒得加,最后还只是用 .md)

但是当时 Next.js 的 SSG 只有 Pages Router,不使用他家的 ISR(需要服务器)就很难做不被卸载的菜单栏和全局进度条动画。并且有的小版本代码分割有问题,rss 的编译部分老被认成客户端,我服了,有点讨厌这个框架了。

去年有朋友帮我用 AI 重构到了 App Router。但他用了一个现成的 Markdown 库,但我为了让说说部分写起来简单,以及渲染看起来长得像社交媒体,解析是手撮的。所以说说相关的部分,以及rss 、搜索,都没挪过去,功能缺了很多。

React Router 7

后来想了想,我用 Next.js 不就是看重他的路由和 SSG。既然React 18 有 RSC 了,那我不如直接 React,静态渲染就抓路由用 renderStaticMarkup 跑一遍好了……

于是上个月问了问哈基米,接触到了 React Router 7,一个完美符合我需要的路由框架。还接触到了 Velite 预构建数据。用 AI 做技术选型还是靠谱的。元旦前一天开始改了 7 天,重构了,并且加好了我心心念念的静态页面间全局进度条。

离开了 Next.js 后,才发现原来外面根本没下雨,原来静态页面导出并不需要 30 秒,只需要 3 秒啊……React Router 7 目前在我心中是完美的路由框架,他只是个处理路由的,写起来是 React 本身的自由度。

不过搓了半天文章没怎么写,全在吹水,说说算是最值得的一个模块了。

所以请看博客

还有 404 页面(不是

性能 Desktop:

主页:

原本的说说页面是打算拿 telegram 和 X 的 api 做同步的。但后来发现其实 iCloud 同步到手机上开 Obsidian 写也是一样的…… Obsidian 还有 Dataview 和 模板 QuickAdd 按钮,何尝不是一种静态博客后台管理工具。……

评论是 Waline,从 Valine 迁移的。还是万年的 LeanCloud 免费额度数据库,反正没人哈哈。

80 个赞

太强了!

2 个赞

突然点赞上限了,不够用啊始皇

12 个赞

这个需求 其实最合适的是astro(我已经见人就推astro了(但是是真的合适
rr最大的问题是他历史上的几次破坏性更新。。。之前remix挺好的 突然没了合并到rr了。。

6 个赞

我有看到了很多 Astro 推荐写博客的哈哈,但当时已经开干了没有了解太多。不知道具体对于自定义的md文件分割与解析、SSR与CSR布局的嵌套支持如何。

主要是想了想对于折腾博客我不是只想发页面,也不希望依赖文件系统的结构还是希望原生 react 应用开发那种感觉。说说模块就几乎是个应用,markdown 从原文件分割、预构建到渲染都有高度自定义的部分。总体我感觉是框架给的限制越小越好,以后可能会加一些不那么像博客的东西,不要再来个框架造成的祖宗之法不可变的那种体验了(像以前的 Next.js那样)

3 个赞

Remix 我觉得我只是用路由功能,现在感觉是挺开放的没有那么多束缚。看了下说早期也是文件夹嵌套结构后来改的平铺?如果是早期那我大概也不会用了,原因就是这样像 Next.js 一样结构固定的“祖宗之法”。我很喜欢现在配置 routes 的方式。

3 个赞

他默认静态导出(需要服务端支持要额外配官方插件支持)
服务端支持 他默认是SSR SSR+MPA 但是有ClientRoute 可以切换到SSR+SPA

内置md支持 mdx/markdoc官方插件支持


通过layout定义md显示外的东西

还有他支持主流的前端框架 vue react svelte组件都能写(但是不能不同组件互相嵌套了 同类组件无所谓 但是也没法用react的context了)

RR主要破坏性更新有点多了
他现在的framework模式就是直接吞了remix出来的东西 感觉他定位也挺模糊 本来他作为一个router库 由remix来当全栈框架 开发者一句remix是rr的包装直接吃了 导致他现在又是库 又是框架 :rofl: :rofl:

3 个赞

页面设计的真干净啊 :face_savoring_food:

3 个赞

很轻很柔,感觉非常舒服 :+1:

3 个赞

确实 Astro 挺合适的,SSG 有 Layout 不会在页面跳转时卸载就行了。

我原本只是冲着 rr 的路由去的。结果一看教程说有一个框架模式,感觉问题不大。本来差点已经打算抓子路由 renderStaticMarkup 了这种东西了,然后一看,rr 的 routes 不是和我想的路由配置方法差不多吗。框架模式的限制也算挺小的架构起来很原生 React,就用上了。现在觉得也挺好的,写法这么原生了看看以后还能怎么 break。

2 个赞

我是obsidian写完之后同步到onedrive 再使用rclone定期同步到oss 然后直接从oss读取markdown react在渲染的时候用markdownToHtml函数处理一下 :rofl:

太有道理了,要不是 iPhone 默认 iCloud 同步仓库我也这么干(没配插件导致的

界面看着很舒服

rr他们这么搞其实挺破坏自己生态的 你有问题搜/问ai 大抵搜出来的东西不太能用(容易搜出旧版本的东西。。。)

让AI总结下:


商业色彩浓郁的nextjs都比他保守 page route至少还给你留着 :rofl: :rofl:

一个小bug:
暗色模式下进入会先出现白屏闪烁,有点刺眼

好看的. !!!

厉害,我以前也一直用wp,22年的时候实在受不了它的臃肿了,换成了HEXO,然后发现写文章不是很方便,就换成了Halo,速度又快,使用起来也方便

这总结哈哈哈,没有实际体验过难以知道重构的可怕。只是说改个写法全局替换一下这种情况其实也还行。但路由改成组件确实不行,狗都不用(不是)

Next.js 虽然保留的 pages dir,但能力就在那了。就 pages dir也改过几次,废弃 _document.js 转 _app.js。这些也还好。更要命的是要想做点不卸载跳转就得进 _app.js,不如直接迁移 App Route,这和换框架有什么区别。

然后就是自从有了 Next.js 15 后某个版本开始它的代码分割有问题了,同一个分割函数都是 await import 会同时用于服务端和客户端,但客户端调用时一直报错说没有 fs。当时好想骂特么为啥会和服务端分一起啊……之后强行改了种写法就分割过了。之后一个版本,同一个文件,还是 await import, render static markup 又是说我不在客户端环境。就,代码完全没变,升版本上去就这样的,之后我再也没给 Next.js 升版本过了,有人到我仓库留言说升版本一下,我就说我弃了…… 至少 RR 的 breaking change 是明确的,Next.js 你只知道 breaking了都不知道 breaking 了什么。

nextjs升到16就更绝望了 又有大量的约定(开启cache component 所有带阻塞数据获取的地方都必须使用use cache/Suspense)东西都是靠build的compiler去保证的
开发的时候不会有任何报错 一运行或者build就各种报错。。。
不过这里讨论nextjs不是重点

rr老是会带着周边生态一起崩了(因为改太多 周边的依赖库/一起使用的库随着升级就会直接爆掉)
之前用remix还觉得挺稳的 但是合并到rr 我就觉得不太行了。。。

astro用了一下感觉很轻 心智负担也很低(主要是MPA+SSR本身就比SPA+SSR简单的多 :rofl:)

或者等tanstack start的release吧

谢谢文化宣导员~