对 Astro 迁移的调查

[zkz098]

可点击链接填写问卷
https://wj.qq.com/s2/14146675/616e/

[zkz098]

@luhuadong @MqyGalaxy @D-Sketon @FidStyle @foryouos @TKanX @MisakaMikoto521

[zkz098]

@MqyGalaxy 回答一下你在问卷中提出的问题：
astro 迁移肯定是优先保证 SSG 的，SSR 是最新评论等部分，如果服务端渲染可以重用，降低 API 压力和提高加载速度，目前计划中就是hybird和static两个模式。
Shoka 作者好像在哪说过她没有进一步维护 shoka 的意愿（不排除我记错了）Astro 本质上和 hexo 类似，但是更现代化和更快，理论上不会影响对 shoka 的还原（但是代码块等细节就不太好整了）
ShokaX 一直都是 Shoka 的“精神继承者”，并且可以说是 Shoka 的一个硬分叉了，很早就在一些细节上进行了独立更新（例如导航栏的毛玻璃、summary、实验性特性等）由于框架变动肯定是要删一些和加一些的。

根据现有计划，在未来很长一段时间内 Astro 版和 hexo 版是并行开发的，所以还有很长时间决定细节问题。

注：在 0.3 前 ShokaX 的改动（除模板外）很多都可以 PR 回 Shoka，所以最开始 ShokaX是一个软分叉，但是 0.3（尤其是0.3.2）之后的技术改动多半涉及到底层变更，这部分内容 PR 回去和把 Shoka 变成 ShokaX 没区别，所以 ShokaX 现在是一个硬分叉

[zkz098]

我认为这句话已经代表了 Shoka 是否会继续更新了（）

[zkz098]

论0.4的改进：
这是 Shoka：

这是 ShokaX 0.3:

这是 ShokaX 0.4：

可以说框架是目前唯一一个阻拦 ShokaX 继续优化的了（）

[D-Sketon]

0.2.8 -> 0.4.0 移动端


貌似对于我的网站无明显改进

[zkz098]

Google Fonts 打回原型了，我一直用的自己的字体没关注这个，200kb 的 CSS 有点难顶
目前采用了一些优化方法已经把lighthouse从69提到75分了（hexo s环境）但治标不治本，稍后我发个版本看看

[zkz098]

0.4.1采用了一点传统方法优化，只能说有成效，但不多

对 css 的进一步优化在现有框架下有点意义不明了，等 Astro 完成之后再看看能不能回迁
现有框架下最大程度的优化：
fixedCover打开，使用长边为1280（或更低）的图片，使用webp或avif格式
对所有_images.yml中的图片，使用长边480（420也可以）的图片，使用webp或avif，质量可以到80以下
avatar使用webp或avif，分辨率为160x160，质量可以到80以下

[BeiyanYunyi]

您好，我是从 walinejs/waline#2207 跟过来发现这个主题的（看到它被这里的一个 issue 提及了），看到了您给 Hexo 引入 ESM 的文章，也看到您正在将主题迁移到 Astro。我此前在自己的一篇文章里介绍过 Astro 的优势，唯恐误人子弟，让人踏上歧途，因此我希望可以额外说明我在实际使用 Astro 的过程中的一些新发现。

1. 在迁移到 ESM 的同时，建议确保网页整体在无 ESM 支持的浏览器上可用（标准是博文可以被阅读）。safari 14 以下存在一定程度的 ESM 兼容性问题，而博客的访问者可能使用 UC 浏览器、百度 App 内置浏览器等经过各式魔改的浏览器。在应用新技术之余，也要考虑到更广泛的用户群体（虽然 ESM 已经是 ES 2015 的事了）。此外， web.archive.org 似乎表现出了对我博客上一些 JS 内容的低支持。
2. Hexo 和 Astro 的关系不一定是排他的，事实上 Hexo 可以作为无头 CMS 使用，从而保有此前 Hexo 的一些功能，可见 sukka 的这篇文章，实现了对老 Hexo 博客的“无缝迁移”。当然考虑到这个主题开发的时间不长，它的用户不太会有像 sukka 那样有大量文章难以迁移的情况（好吧原来是别的主题改过来的，那确实），迁移也主要是博客主而非主题作者需要考虑的问题。
3. 使用 Astro 也不一定非要使用 remark。Astro 的可定制性比较高，肯多搓的话应该还是能用上 markdown-it 的。
4. 考虑到 Vue 生态目前仍然有一部分（如 Vitepress）通过 md-it 插件支持在 markdown 里写 SFC，md-it 短期内还是不用担心“落后”的，“天塌下来有高个子顶着”。当然 MDX 确实更加泛用，而且也有基于 rust 的编译器了。
5. 之后我比较有空，有些想参与开发

[zkz098]

在我看来 Sukka 用 Next 不是因为没 Astro，而是因为 Next 和 React 的高度集成。作为一个 React 为主的程序员，使用 Next 搓博客能好地展现技术水平。

赞同这个观点

我对于 Next.js / Nuxt.js 接触不多，感谢指出这个错误

其实 Astro 迁移很大程度上是个跳板，本质上是从 hexo 的这种模式转移到现代框架下，这个步骤完成之后如果有其他框架的支持计划难度会小很多。至于为什么是 Astro，之前是准备迁到 Valaxy 的，但用了一段时间之后发现 Valaxy 似乎泛用性有点差（当然可能是API文档不完善造成的偏见），有点一切为theme-yun服务的感觉，就没有继续迁移

[AmeMizuki]

個人還是希望是遷移至 Astro 為主

[YunYouJun]

在我看来 Sukka 用 Next 不是因为没 Astro，而是因为 Next 和 React 的高度集成。作为一个 React 为主的程序员，使用 Next 搓博客能好地展现技术水平。

赞同这个观点

我对于 Next.js / Nuxt.js 接触不多，感谢指出这个错误

其实 Astro 迁移很大程度上是个跳板，本质上是从 hexo 的这种模式转移到现代框架下，这个步骤完成之后如果有其他框架的支持计划难度会小很多。至于为什么是 Astro，之前是准备迁到 Valaxy 的，但用了一段时间之后发现 Valaxy 似乎泛用性有点差（当然可能是API文档不完善造成的偏见），有点一切为theme-yun服务的感觉，就没有继续迁移

valaxy 相比 astro（更泛用的前端框架而不是博客框架） 可能更多为博客功能做准备（譬如更多约定的文章/配置结构、devtools、标签、分类等公共函数），考虑到一些实践还在探索中，因此现在仍然处于 0.x 阶段，部分 API 和文档可能没跟上。在早期开发阶段 valaxy 与 valaxy-theme-yun 存在部分耦合，现在也已逐步解耦。
主题方面我并没有太多精力去同时维护多款主题，因此可能也难以发现更多痛点，不过如果还有计划迁移 valaxy 的话，有什么问题可以随时反馈，我会尽快提供相关的解决方案。

[YunYouJun]

valaxy 与 astro 本质上是两种技术路线，对于站点架构和页面的渲染处理并不相同，在这里 YunYouJun/valaxy#596 我总结了一些表现上的对比。（如有谬误，欢迎指正。）

[zkz098]

在我看来 Sukka 用 Next 不是因为没 Astro，而是因为 Next 和 React 的高度集成。作为一个 React 为主的程序员，使用 Next 搓博客能好地展现技术水平。

赞同这个观点
我对于 Next.js / Nuxt.js 接触不多，感谢指出这个错误
其实 Astro 迁移很大程度上是个跳板，本质上是从 hexo 的这种模式转移到现代框架下，这个步骤完成之后如果有其他框架的支持计划难度会小很多。至于为什么是 Astro，之前是准备迁到 Valaxy 的，但用了一段时间之后发现 Valaxy 似乎泛用性有点差（当然可能是API文档不完善造成的偏见），有点一切为theme-yun服务的感觉，就没有继续迁移

valaxy 相比 astro（更泛用的前端框架而不是博客框架） 可能更多为博客功能做准备（譬如更多约定的文章/配置结构、devtools、标签、分类等公共函数），考虑到一些实践还在探索中，因此现在仍然处于 0.x 阶段，部分 API 和文档可能没跟上。在早期开发阶段 valaxy 与 valaxy-theme-yun 存在部分耦合，现在也已逐步解耦。 主题方面我并没有太多精力去同时维护多款主题，因此可能也难以发现更多痛点，不过如果还有计划迁移 valaxy 的话，有什么问题可以随时反馈，我会尽快提供相关的解决方案。

这个讨论还是建立在2024年2月的视角进行的，所以当时的很多观点其实到现在已经是不正确或者片面的了

目前正在推进 Valaxy 迁移工作，具体仓库在ShokaX-UIKit

其实大多数主题在向 Valaxy / Astro 迁移过程中，框架的问题只占很小的一部分。主要工作量在前端UI迁移上，这个过程相当于把一套 jQuery 时期遗留的 UI 迁移到 Vue 3 上，而且因为 Hexo 本身构建系统高度落后，这部分工作成果也很难转移回 Hexo 上使用，导致主题开发者在迁移基本完成之前看不到成果，这个过程中的开发积极性事实上会变得很低。

当然这也不是 Valaxy / Astro 的问题，而是 Hexo 的问题，但是 Hexo 已经是一个逐渐凋亡的框架了，我也不认为它能做出改变。

最后也希望 Valaxy 能变得更好，逐步接过 Hexo 的位置，把广大的主题开发者解救出来。

[D-Sketon]

以下列出可能会用到的remark/rehype插件

hexo	astro
markdown-it-abbr	remark-abbr
markdown-it-attrs	remark-attributes
markdown-it-bracketed-spans	remark-bracketed-spans
markdown-it-charts	?
markdown-it-container	remark-directive
markdown-it-deflist	remark-deflist-simple?
markdown-it-emoji	remark-emoji
markdown-it-footnote	remark-gfm
markdown-it-ins	remark-ins
markdown-it-mark	remark-mark-plus
markdown-it-multimd-table	?
markdown-it-pangu	remark-pangu
markdown-it-sub	?
markdown-it-sup	remark-super
markdown-it-task-checkbox	remark-gfm
markdown-it-toc-and-anchor	?
markdown-it-excerpt	remark-excerpt?
markdown-it-furigana	?
markdown-it-graphviz	remark-graphviz?/remark-graphviz-svg?
markdown-it-katex	remark-math + rehype-katex
markdown-it-mermaid	remark-mermaidjs/rehype-mermaid
markdown-it-prism	remark-prism
markdown-it-spoiler	?

[zkz098]

remark.js建议使用remark-directive而非remark-containers，可能需要改一下
代码高亮器和astro保持一致改成shiki更好，实在不行就手搓（）
spoiler和furigana大概率得手搓，现有项目满足不了需要或已弃用
abbr那个插件被remark标记为无法兼容了，应该没法用

[BeiyanYunyi]

markdown-it-toc-and-anchor 可以参考我博客的实现。remark 自己的 toc 插件只能实现把 toc 插入到文章首 / 尾，我用它们更底层的库搓了一个侧栏，并且使用前端 js 比较烂地实现了滚动时的高亮。

[BeiyanYunyi]

代码高亮器和astro保持一致改成shiki更好

实际上用 prism 是完全没问题的，Astro 也直接提供了选项，不需要手动引入。我博客也用 prism，理由是 waline 后端用 prism，这样一来前端一定要引 prism 的样式，因此就没必要再多引一份 shiki 了。

[zkz098]

有一种高度拧巴的解决方案：
remark-rehype + rehype-slug + rehype-autolink-headings 把标题渲染到和 markdown-it-toc-and-anchor 一致
然后，按照 hexo 的实现（toc tag + tocObj）手动编写 ToC，因为本主题的 ToC 都是调的 hexo 的 helper，
如果有人需要在md里用就mdx引入对应astro(也有可能是vue)组件