对 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]

其实我就是看了您那篇文章才有的迁移到 Astro / Valaxy 的想法的（）

Shoka 系一直都有过度依赖 Javascript 的问题，例如在手动禁用 js 之后本主题会卡 Loading。我不太清楚 Astro 在此方面是否提供了 nomodule 的 fallback，但 hexo 版本确实缺少一个 nomodule 的 fallback，感谢提醒。

客观可行，但是我更倾向于使用 Valaxy 等 Hexo 友好的框架解决此问题。很难指望大部分 hexo 用户的水平能达到使用 Next.js / Nuxt.js 自行开发功能的水平，相当数量的人连插件都安不明白，还是 Astro / Valaxy 这种框架更好一点。
而且 hexo 版本在我们的计划里是不会立刻 EOL 的，至少会继续维护1年

这其实是主动迁移（）虽然算上前身满打满算开发了不到5年，但是这个主题的状态很复杂（）它本身依赖一个 md 渲染器去运行，但这个渲染器由前作者写就，我们接手之后也基本没动过核心渲染部分。同时这个 md 渲染器的代码质量高度堪忧，本身没几个注释，之前还发现过 ReDoS 漏洞（hexo 跑在本地也没什么影响罢了）所以这其实是主动迁移到 remark，同时重构一遍渲染器

这个其实同上，这本身是主动迁移

您后续直接提PR就行，如果有需要我可以发组织邀请

[zkz098]

其实这种 Hexo 作为无头CMS + Next.js 的方法某种意义上更像权宜之计，因为sukka发表这篇博文时，Astro还处于预发布状态：


所以这种方法更像是缺少 Astro 这种内容中心+SPA框架的临时解决方案
近两年也有人采用过类似的方案 例 但感觉本质上没有区别，而且 Why not Astro（）

[BeiyanYunyi]

很难指望大部分 hexo 用户的水平能达到使用 Next.js / Nuxt.js 自行开发功能的水平，相当数量的人连插件都安不明白，还是 Astro / Valaxy 这种框架更好一点。

实际上 Astro 要手搓的东西比 Next 和 Nuxt 更多才是，搓完 Next 或者 Nuxt 之后导出一个插件或者 layer 给用户用，易用程度上也一样。

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

[zkz098]

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

赞同这个观点

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

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

[LiuWaiting203]

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

[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)组件