摘要:对于构建中小型网站和个人博客来说,Hakyll 是一个不错的静态网站生成器库,9 年前的 Jonas Hietala 正是选择了 Hakyll 编写博客网站。但随着时间的推移,网站出现各种问题,考虑多种因素之后,Jonas Hietala 决定用 Rust 重写,看看他是怎么实现吧!
原文链接:https://www.jonashietala.se/blog/2022/08/29/rewriting_my_blog_in_rust_for_fun_and_profit/
声明:本文为 CSDN 翻译,未经授权,禁止转载。
我使用Hakyll编写我的静态网站已经有9年了。在此之前,我使用过Jekyll,还使用过Perl的Mojolicious和PHP的Kohana编写更动态的页面。
但这些已成为过去,最近我决定使用Rust重新编写我的网站。
我想通过这次重写网站,重点解决以下难题:
1.速度越来越慢。
在我的笔记本电脑上,重构一次网站需要75秒(不是编译,只是生成网站)。我的网站只有240个帖子,所以我认为不至于如此之慢。虽然我可以使用缓存系统,并在编辑期间通过watch命令查看更新后的帖子,但这个速度仍然是我无法接受的。
2.许多外部依赖项。
虽然站点生成器本身是用Haskell编写的,但除了许多Haskell库之外,还有一些依赖项。我的博客助手脚本是用Perl编写的,我使用sassc转换sass,然后利用Python的pygments高亮显示语法,并使用s3cmd将生成的站点上传到S3。
安装所有这些工具并保持最新状态是一件很麻烦的事情。我希望能有一个统一的工具解决所有问题。
3.设置问题。
有时,网站会出现一些问题,我必须花时间调试和修复。每当我有一些新的写作思路,却发现网站生成器有问题,就会觉得很沮丧。
你可能会想,什么地方会出问题?
有时,一些软件包的更新可能会破坏网站。例如,
GHC更新后,就找不到cabal包了。
在运行Haskell可执行文件时,遇到了以下错误:
[ERROR] Prelude.read: no parse
(只有我的台式机会遇到这个错误,在我的笔记本电脑上运行良好。)
还有如下Perl的错误:
Magic.c: loadable library and perl binaries are mismatched (got handshake key 0xcd00080, needed 0xeb00080)
(只有我的笔记本电脑会遇到这个错误,这我的台式机上运行良好。)
如果Hakyll升级时会修改Pandoc参数,那么就会破坏Atom feed中渲染的代码。
我知道上述问题都可以得到解决,但我只想要一些可以正常工作的东西。
4.Haskell的精神开销。
我很喜欢Haskell,尤其是纯函数的部分,而且我非常喜欢Hakyll通过声明式的方法处理站点配置。以生成静态页面(即单独的页面)为例:
match "static/*.markdown" $ do
route staticRoute
compile $ pandocCompiler streams
"templates/static.html" siteCtx = loadAndApplyTemplate
"templates/site.html" siteCtx = loadAndApplyTemplate
= deIndexUrls
即使你不理解 $ 和 >>=,也可以看懂我们想从static/文件夹中查找文件,然后将它们发送到pandocCompiler(以转换markdown代码)和模板,并删除URL中的index(避免链接以index.html结尾)。
简单明了!
但是我已经很多年没有使用过Haskell了,而且我不想在网站上添加复杂的东西。
例如,我曾想在帖子中添加链接“下一个/上一个”,但后来我不得不花时间重新学习Haskell和Hakyll。即便如此,最后我想到的解决方案还是超级慢,因为我采用了一个线性搜索来查找下一个/上一个帖子,但我未能搞清楚如何正确地利用Hakyll实现这个链接。
我相信你有更好的方法,但对我来说,这样的小功能不值得付出这么大的努力。
1.我很喜欢Rust,而且它很适合业余项目。
2.Rust非常高效,非常擅长转换文本。
3.Cargo很流行,只要安装了Rust,运行cargo build,就可以构建网站。
我想编写一个静态站点生成器,这是一个非常有趣的项目,难度应该不大,但可以让我全权控制网站,而且灵活性完胜我使用过的所有网站生成器。
我不打算在此介绍所有的细节,如果你感兴趣,请查看源代码(地址:https://github.com/treeman/jonashietala)。
起初我很担心重新实现我喜欢的Hakyll功能的难度会太大,例如模板引擎、多种语言的语法高亮显示,以及通过watch命令自动重新生成编辑过的页面并充当文件服务器,这样我就可以在写作的过程中随时在浏览器中查看帖子。
事实证明,我可以利用现有的库处理一些难度较大的工作。以下是我使用的一些效果很好的库:
tera:模板引擎。
它比Hakyll更强大,甚至可以执行循环之类的操作:
<div class="post-footer">
<nav class="tag-links">
Posted in {% for tag in tags %}{% if loop.index0 > 0 %}, {% endif %}<a href="{{ tag.href }}">{{ tag.name }}</a>{% endfor %}.
</nav>
</div>
pulldown-cmark:解析Markdown。
这个库非常适合CommonMark(Markdown标准的语法规范)。
虽然速度很快,但支持的功能不如Pandoc多,所以我不得不做一些扩展。
syntect:语法高亮显示,支持Sublime Text的语法。
yaml-front-matter:解析帖子中的元数据。
grass:Rust中的Sass编译器。
axum:创建本地托管站点的静态文件服务器。
hotwatch:监视文件变更,在文件更新时更新页面。
scraper:解析生成的HTML。我的一些测试和特定的转换中用到了这个库。
rust-s3:将生成的站点上传到 S3 存储。
即便使用了这些库,Rust源代码本身也超过了6000行。在有些情况下,Rust代码可能会很冗长,我的代码确实不够漂亮,但是最后的代码量仍然超过了预期。
如果我的帖子都采用标准的markdown,这个转换过程会更加容易,但多年来我添加了很多pulldown-cmark不支持的功能和扩展。所以,我不得不自己编写代码。
我有一个预处理步骤,利用多个图像来生成插图。这是一个通用的处理步骤,形式如下:
::: <type>
<content>
:::
我使用这个预处理来生成各种图像集合,例如Flex、Figure和Gallery。下面是一个例子:
::: Flex
/images/img1.png
/images/img2.png
/images/img3.png
Figcaption goes here
:::
需要转换成:
<figure class="flex-33">
<img src="/images/img1.png" />
<img src="/images/img2.png" />
<img src="/images/img3.png" />
<figcaption>Figcaption goes here</figcaption>
</figure>
那么,我该如何实现呢?当然是使用正则表达式。
use lazy_static::lazy_static;
use regex::{Captures, Regex};
use std::borrow::Cow;
lazy_static! {
static ref BLOCK: Regex = Regex::new(
r#"(?xsm)
^
# Opening :::
:{3}
\s+
# Parsing id type
(?P<id>\w+)
\s*
$
# Content inside
(?P<content>.+?)
# Ending :::
^:::$
"#
)
.unwrap();
}
pub fn parse_fenced_blocks(s: &str) -> Cow<str> {
BLOCK.replace_all(s, |caps: &Captures| -> String {
parse_block(
caps.name("id").unwrap().as_str(),
caps.name("content").unwrap().as_str(),
)
})
}
fn parse_block(id: &str, content: &str) -> String {
...
}
(实际的图像解析会更加繁琐,不在此赘述。)
此外,我还扩展了pulldown-cmark:
// Issue a warning during the build process if any markdown link is broken.
let transformed = Parser::new_with_broken_link_callback(s, Options::all(), Some(&mut cb));
// Demote headers (eg h1 -> h2), give them an "id" and an "a" tag.
let transformed = TransformHeaders::new(transformed);
// Convert standalone images to figures.
let transformed = AutoFigures::new(transformed);
// Embed raw youtube links using iframes.
let transformed = EmbedYoutube::new(transformed);
// Syntax highlighting.
let transformed = CodeBlockSyntaxHighlight::new(transformed);
let transformed = InlineCodeSyntaxHighlight::new(transformed);
// Parse `{ :attr }` attributes for blockquotes, to generate asides for instance.
let transformed = QuoteAttrs::new(transformed);
// parse `{ .class }` attributes for tables, to allow styling for tables.
let transformed = TableAttrs::new(transformed);
以前我喜欢降低标题等级,并嵌入原始YouTube链接,而且实现起来很简单(不过,在处理前后的步骤中嵌入YouTube链接可能会更好)。
Pandoc支持向任意元素添加属性和类,例如:
![](/images/img1.png){ height=100 }
可以转换成:
<figure>
<img src="/images/img1.png" height="100">
</figure>
这种用法在我的代码中比比皆是,所以我决定重新实现。
我在Pandoc中使用的功能还有一个不受支持:在HTML标签内计算markdown。比如下面这段代码就无法正确呈现:
<aside>
My [link][link_ref]
</aside>
起初我的计划是,在通用预处理中实现,但后来发现这样做会丢失链接引用。比如下面这个例子:
::: Aside
My [link][link_ref]
:::
[link_ref]: /some/path
link不会变成链接,因为我们只会在 ::: 内解析。
Some text
{ :notice }
这段代码会调用notice解析器,在这个示例中,它将创建一个<aside>标记(而不是 <blockquote>标记),同时保留已解析的markdown。
虽然现有的crate使用syntect高亮显示代码,但我自己编写了一个crate,可以将它包装在<code>标记中,并支持内联代码高亮显示。例如:
Inside row: `let x = 2;`rust
可以转换成:
Inside row: let x = 2;
性能提升
我没有在提高性能上花费太多时间,但以下两方面的改动对性能产生了很大影响:
第一,如果使用syntect,并且使用自定义的语法,则应该将SyntaxSet压缩为二进制格式。
第二,使用rayon并行化渲染。渲染是解析Markdown、应用模板以及创建输出文件的过程。rayon非常适合该任务,因为这项任务的瓶颈是CPU,而且rayon非常易于使用(如果代码结构正确)。例如,下面是一个简化的渲染:
fn render(&self) -> Result<()> {
let mut items = Vec::new();
// Add posts, archives, and all other files that should be generated here.
for post in &self.content.posts {
items.push(post.as_ref());
}
// Render all items.
items
.iter()
.try_for_each(|item| self.render_item(*item))
}
如果想并行化上述处理,我们只需要将iter()改为par_iter():
use rayon::iter::{IntoParallelRefIterator, ParallelIterator};
items
.par_iter() // This line
.try_for_each(|item| self.render_item(*item))
只需要修改这一个地方!
诚然,性能上的提升非常小,几处巨大的性能提升都来自我使用的库。例如,我的旧网站使用了一个用Python编写的外部pygments来高亮显示语法,而现在我使用了Rust的高亮显示,它的速度要快得多,并且很容易并行化。
以前,我的网站给我的最大困扰是,太容易出错了。例如,链接到不存在的页面或图像,忘记定义链接引用,或者忘记在发布之前更新链接。
因此,除了测试watch命令之类的基本功能之外,我还需要解析整个站点,并检查所有内部链接是否存在以及是否正确。此外,我还需要手动检查外部链接。
我在本文开头提到了一些难题,下面我们来看看我是否解决了这些难题。
如今在我的笔记本电脑上,重建完整的站点需要4秒(不包括编译时间)。18倍的性能提升看起来不错嘛。我相信,网站的性能还有进一步提升的空间,例如使用rayon处理文件I/O,使用异步处理,而且我没有缓存系统,所以每次构建都会重新生成所有文件。
请注意,这并不是说Rust的速度远超Haskell,这不过是两种实现的比较。我相信有人能够使用Haskell编写出更快的实现。
现在网站的一切都是用Rust编写的,不需要安装外部脚本或工具。
只要系统安装了Rust,cargo build就可以正常工作。我认为这是Rust最大的优势之一:构建系统可以正常工作。
你不必手动寻找丢失的依赖项,为了实现跨平台而苦恼,或者在构建系统自动拉取更新时破坏一切。你只需要静静等待代码编译完成。
虽然我找到了更简单的方法来实现上一个/下一个链接,但我并不认为这意味着Rust比Haskell更简单或更容易,这只是意味着Rust对我个人来说更容易理解。
最大的原因还是要归结为实践。最近我一直在使用Rust,但对于Haskell,我只在大约十年前构建这个网站时学习过一段时间,之后再也没有接触过。
我敢肯定,如果停止使用Rust,过个十年再次接触,我也会遇到很多困难。
总的来说,我很满意这次重写网站的结果。这是一个有趣的项目,尽管工作量超出了我的预期,但的确解决了我的一些烦恼。