复活了，又造了一个全新博客
NaN views
最近有关注到 BearBlog 这样非常简约的形式，虽然我不追求极致的大小，但是他的简约风格还是让我非常满意。同时这样也能让人更加关注到内容本身。
加上从去年开始陆陆续续就在玩前端。目前简单将 BearBlog 基本照搬不动的拿了过来。另外一般会问为啥不直接用它的服务，主要考虑了以下几点：
- 好玩
- 完全掌控所有东西
- 我能做的更快
- MDX 灵活且可搭配自定义的组件
- 造起来很快，只花费了一两天零碎时间
为什么能更「快」
记得我之前的博客使用 Hexo 生成出来的静态页面。其实这种已经比较快了，但是如何更快？这就要贴一下一个推文。
I'm not a tailwind / @shadcn stan. I'm a "UI must fractally compose" stan. This approach to styling components is fulfilling the promise that made me fall in love with @reactjs. Copy-paste the whole or the sum of its parts. It all just works.
This week, we're going to rethink how copy and paste works for Tailwind templates. One click of a button and you'll be able to "lift" components from a template. Copy & paste or Edit in @v0. Shipping soon.
这个推文强调的组件分形组合，这正是当前 Next.js App Router 以及 RSC 想要带来的好处。简单讲可以把一个网页想象成不同的组件组装起来。介绍一下我认为当前前端的几种模式：
- CSR：前端有大量 js 包用于数据交互（且客户端请求数据显然不如服务器请求渲染更快），还有诸如 CSS-in-JS 动态计算带来的额外渲染负担
- SSR：需要后端一次性将一个页面所有 props 数据拿到传递给前端渲染
- RSC：可并发的组件级别的渲染，只加载需要的组件，不需要的组件不加载，同样也是服务端渲染
虽然他们各有优缺点，但基于我个人需求，我将自己的两三个网站都切换到了 RSC 模式。也就是切换网页时我们可能只需要加载部分组件，这样不会导致整个网页重新渲染，这时候给到用户的体验其实在我看来是非常好的。也就是为什么我不是特别在意极致的网站大小了，因为其实如果不是大到离谱，真正的瓶颈其实不在那里。另外还需要结合 API 或者路由维度的缓存来达到更好的效果。
总结，在当前看，我认为 Next.js 目前在前端 Hydration 的这个概念上是做的最好的。
技术选型
目前选型如下，如果有想类似和我一样构建一个 MDX 为基底的 blog，可以参考。
- Next.js
- ContentLayer
- Tailwind
是否会继续断更？
这点不好说，不过已经工作了两三年了，现在趋于平稳状态，应该会有更多时间可以投入到博客上。
最后，旧数据的话就放在了 https://old.qiuri.org 存档了。