关于Hexo与Vue

[NoahDragon]

博主以前是用Hexo的，不知是否也曾考虑过将Vue融合到Hexo中呢？ 是否由于Hexo本身结构的问题，而无法实现呢？

[myst729]

Hexo 的 theme 就是渲染页面的模版，因此你想用 Vue 或者其他的前端类库，其实并没有任何障碍。

到我弃坑 Hexo 时为止（今年 4 月份），Hexo 的机制基本上是读取指定目录下的 md 文件，套用模版渲染成 html 文件。整个还是偏向传统的多页面跳转，以静态展示为主，客户端比较瘦的结构。在 Hexo 这套东西上面使用 Vue 这种长于用数据组装视图的富客户端类库，也不是不行，但我个人觉得诉求不吻合，俗称性格不合。像 jQuery 这样的 DOM 类库反而更有用武之地。

当初弃坑 Hexo 的原因主要有二：

• Hexo 每次发布都要构建，很烦躁。虽然 GitHub 提供了一些自动化的 CI 工具，但是懒于研究；
• 对 Vue 的了解比较有限，想用 Vue 写些稍微像点样子的东西，学习学习，day day up。

弃坑的契机也很巧——换电脑，差点忘了备份 Hexo 的配置和一堆 markdown。当时并没有把这一堆东西扔上 GitHub。

写 Vuelog 的时候，最主要的需求也有两个：

• 不构建； 发布方便，不用在本地搭建构建系统，使用门槛低。甚至不用本地 GIT 推送，直接在 GitHub 上改改就行。还有就是解决了备份的问题，发布即备份。

• 无后端。 这是我要托管在 github.io 而必须满足的，因此最终做成了前端路由的单页应用。

说到这第二个需求，不得不提一下 Hexo 之前的事情。用 Hexo 之前，我的 blog 是用 WordPress 搭建，托管在花钱的空间上，域名也是买的。最近几年维护越来越懒散，空间和域名又一路涨价，早就不想续费了。趁弃坑 WordPress 的机会，也把以前写的烂文章整理了一遍，很多菜鸟水文都没有保留。要迁到 github.io，那就只能跑没有后端的静态站点，当时更流行的方案是用 Ruby 写的 Jekyll。而我选择 Hexo 一方面是我对 Node.js 技术栈更熟悉和喜爱，另一方面是 Hexo 声称自己性能远超 Jekyll（对于我这样内容不多的站其实没有明显区别）。

当时还有一个选择就是用 Angular 自己写一个类似今天 Vuelog 这样的客户端路由单页应用，GitHub 项目都建好了，但是由于种种原因没有动手（主要是懒，然而折腾一个 Hexo theme 其实并没有少花时间）。Vuelog 这个项目可以看作是对当时想法的延续和实（tián）施（kēng）。

[myst729]

@NoahDragon 原来是 hexo team 的同学呀。怪不得突然问起跟 hexo 相关的事情。不知道 hexo 最近有什么好玩的新想法，有挺长一段时间没关注了 😅

[NoahDragon]

感谢博主的详细解答。

自从Tommy毕业以后，Hexo目前没什么大的变动。自己用Hexo也感受到博主所说的问题，虽然用Travis-CI可以解决，但一旦移站到非GitHub的空间，Travis-CI的配置就有些麻烦。个人希望将Hexo与Vue结合起来，希望能够实现客户端渲染，从而能够实现上传文章即是发布的理想状态。

[myst729]

Hexo 的模式是多页面，以跳转驱动，而 Vue 及其周边设施则致力于构建单页应用。从思路上来说他们完全是两条不同的路，所以我觉得 Vue 在 Hexo 这个体系似乎有些大材小用。也可能我没有抓到你的意思。可以大致描述一下你的技术方案吗？

[NoahDragon]

其实后来想了想，确实没有关联。Hexo中能应用到Vue的领域，或许只有Theme。本来是想用到Vue中SSR的技术，但前提是得先有个Server。除非作为CMS，否则很难用到Vue的全部功能。

[myst729]

对的。页面跳转就等于重启客户端的 Vue 实例，之前的应用状态都会丢掉。最后只能当成前端模板引擎来用，就走偏了。

[PeakFish]

列表页是怎么弄的，每次写完一篇博客 build 这不感觉是不能少的吧，我看你的博客有个 database.js 。发现 @viko16 的博客也是用差不多相同的思路，请求 md 文件前端渲染。发现他的列表页用了 github 的 api https://api.github.com/repos/viko16/writings/contents/posts?ref=master ，但是每篇博客标题和文件名有关系，不知道还有没有更好的方法了。

[myst729]

@PeakFish

GitHub API 有时间限制，每小时 60 次。如果用 token 的话，可以增加到每小时 5000 次。但是因为没有后端，token 完全暴露在前端，有很大的安全隐患。

database.js 就是用来存文章列表的地方，里面还有其他一些配置项。另外这个应用不仅可以托管在 GitHub，其他任何地方都能托管，所以不必依赖 GitHub API。

[viko16]

@PeakFish @myst729

不怕折腾的话可以考虑用 Travis-CI 抓取 GitHub API 去生成 database.js，保密性的话可以用 Travis 自家的 加密方案 。

// 这样我们就实现了一个 Travis-CI 版本的 hexo generate 了（逃

[myst729]

@viko16

之所以自己撸这么个东西就是因为不想折腾了 🤣 开坑时的定位上面的对话也解释得比较清楚，就是希望完全不受 GitHub 约束，可以随意搬地方。这样也才能可以给任何人用，否则 Travis 什么的，别说对普通人不友好，大多数弱鸡码农也是不会玩的 😨 （然而这个项目本身也用了 Circle CI，逃

[PeakFish]

为什么我用 npm run build 不能生成 静态文件呢 ？ 没有文件。 没有报错 Build complete. 了

[myst729]

没有静态文件，全都是在浏览器里解析 MD 渲染生成的。

如果你只是想要一个博客，不要拉源码，直接下载 release 包就行了。源码是给开发用的。

[PeakFish]

不是 我是说 README 中的 yarn build 但是我没有 yarn ， 我用 npm run build 不应该在 static 文件夹中生成一些文件嘛 但是没有是什么情况呢？

[myst729]

项目开发用的示例 MD 文件其实是项目的文档，所以 build 就是重新构建文档目录，在 /docs 下面。release 包也是文档打包。

[yugasun]

@myst729 看到博主的这个项目，心中一亮，实在是很棒。当初自己的也是想整这么一套方案，建了项目，却一直没做.......o(╯□╰)o 不知道博主后期会考虑编译输出像hexo生成的静态文件一样，毕竟这样对于SEO会更加友好，而且现在编译输出文件会随着博客增多，项目越来越重，每访问一个页面，需要实时编译markdown，也有性能问题。

[myst729]

@yugasun 如果你看了上面的讨论，应该不难猜到我的答案——不会。当初挖这个坑就是不想有构建的过程，如果做得和 Hexo 差不多，何不直接用 Hexo？类似的项目还有 docsify、docute 等。如果你需要 SEO，我也会建议你就用 Hexo。基于 Vue 的方案也有，比如 Nuxt。

[xiangst0816]

@myst729 嗯，说得对，我补充下，如果是基于React的话可以试试Gatsby，我的博客就是用这套方案做的，第一版大概4天就出来：Github地址。@yugasun如果对vue很熟，建议用Nuxt的generate来搞，因为能智能分析页面已有链接提前下载资源（prefetch），可以做到单页的体验+SEO。

[jiangjiali]

说实话，简单明了。很好使。 https://www.jiangjiali.com