Rust library to generate static websites
feat(news): New article
+50
-5
-1
.github/workflows/release.yml
-1
.github/workflows/release.yml
+6
website/content/docs/philosophy.md
+6
website/content/docs/philosophy.md
···
14
14
15
15
**Maudit is about making static websites**. It has no higher goals than that. It won't try to become a server-side rendering framework, a hybrid framework, or anything else. This focus allows us to make the best static website generator we can.
16
16
17
+
**From the blog:** [The still scrolls of the web, unchanging and steadfast, at last!](/news/for-static-websites/)
18
+
17
19
## Your website changes less often than its content
18
20
19
21
Many parts of Maudit projects are written in Rust, a compiled language, thus requiring recompilation for changes. This overhead is justified by the assumption that structural changes are less frequent than content updates. For example, in a blog, new articles are more common than layout changes.
20
22
21
23
Without delving into the complexities of incremental builds, this architecture allows Maudit projects to build very quickly, even for large websites, thanks to the raw performance of a compiled language.
22
24
25
+
**From the blog:** [Maudit is faster than most other static website generators, but](/news/maudit-compile-time/)
26
+
23
27
## Maudit is a library, not a framework
24
28
25
29
Every feature in Maudit was designed to be able to be used outside of Maudit. You can access and load all of your content outside of Maudit. Maudit pages are normal Rust structs and can be handled outside of Maudit, and so on.
26
30
27
31
In the simplest terms, you call Maudit, it does not call you.
32
+
33
+
**From the blog:** [The court's library, not its king](/news/maudit-library/)
+38
website/content/news/for-static-websites.md
+38
website/content/news/for-static-websites.md
···
1
+
---
2
+
title: "The still scrolls of the web, unchanging and steadfast, at last!"
3
+
description: "Maudit is about making static websites"
4
+
author: The Maudit Team
5
+
date: 2025-10-15
6
+
---
7
+
8
+
We have one goal for Maudit: To make it the best tool to generate static websites. This may include helpful side features like loading Markdown content, syntax highlighting, image processing, sitemap generation, RSS feeds, etc.
9
+
10
+
But the end result is always the same: You get a static website. No server, no serverless (with a server), no nothing. You get `.html` files that you can host wherever support hosting static files.
11
+
12
+
**Pros:**
13
+
14
+
- You can host Maudit websites pretty much anywhere, for typically cheap
15
+
- Hosting said websites is also headache-free and will last as long as servers are able to serve HTML files
16
+
17
+
**Cons:**
18
+
19
+
- You don't have a backend
20
+
- Static websites are typically quite static
21
+
22
+
There are many ways around both of these cons, typically involving hosting a backend or a serverless function and doing client-side fetches from your static website. This is a good solution, and work for many websites, but does still have limitations compared to a server-side rendering framework.
23
+
24
+
Ultimately..
25
+
26
+
## It's not you, it's us
27
+
28
+
**If you need server-side rendering: You probably shouldn't use Maudit.** You might counter this with "but, [Maudit is a library](/news/maudit-library/), it's so flexible, I can just render my Maudit pages in my Axum backend", which, great observation, but still, isn't the goal of Maudit!
29
+
30
+
You are free to do anything you want of course, but Maudit is not and won't be optimised for your use case, it might always feel like you are fighting against the library, building resentment against us, and generally having a not so good time.
31
+
32
+
## There is just so little time
33
+
34
+
We believe that it is fundamentally impossible for a tool to be great at both building static and dynamic websites. You can be good, but not great.
35
+
36
+
Maudit aims to absolutely delight people who want static websites. Adding server side rendering would introduce technical constraints and take development time away that would obstruct this goal.
37
+
38
+
You should use the proper tool for the job, and we hope for Maudit to be the proper tool for static websites.
+3
-1
website/content/news/maudit-compile-time.md
+3
-1
website/content/news/maudit-compile-time.md
···
20
20
21
21
## Workarounds
22
22
23
-
You can also push this further, if your layouts do change often and you don't want to recompile your project on every change, use a runtime templating language like [minijinja](https://github.com/mitsuhiko/minijinja) or [Tera](https://keats.github.io/tera/docs/).
23
+
If your layouts do change often and you don't want to recompile your project on every change, using a runtime templating language like [minijinja](https://github.com/mitsuhiko/minijinja) or [Tera](https://keats.github.io/tera/docs/) is a great solution. You can load your templates at runtime, and thus change them without recompiling.
24
+
25
+
### Even further beyond
24
26
25
27
You can push it even further! [Routes paths are not static, they can be fully dynamic](https://maudit.org/docs/routing/#:~:text=The%20path%20can%20be%20any%20Rust%20expression) as such, you could load your routes fully at runtime.
26
28
+3
-3
website/content/news/maudit01.md
+3
-3
website/content/news/maudit01.md
···
11
11
12
12
...
13
13
14
-
_More seriously_, this is the first release of **Maudit** (/mo.di/), a static site generator written in Rust.
14
+
_More seriously_, this is the first release of **Maudit** (/mo.di/), a Rust library to generate static sites.
15
15
16
16
<div class="text-center italic">Want to just get started using Maudit? Check out our <a href="/docs/quick-start/">Quick Start guide</a></div>
17
17
···
40
40
}
41
41
```
42
42
43
-
That said, we hope to avoid as much boilerplate as possible, as such fancy macros are involved at times. But, we're not much into magic either, so expanding those macros should still yield code that is easy to understand.
43
+
Being a library means that a Maudit project may have a little more boilerplate than you'd see in a framework, but it also means that you can use all the tools and libraries of the Rust ecosystem, and that you are in full control of your project.
44
44
45
-
Our goal is to strike a balance between convenience and clarity. It shouldn't feel like there's a lot of impossible to understand weird code happening behind the scenes.
45
+
We try nonetheless to make the experience as smooth as possible and reduce boilerplate where we can. For instance, the `#[route]` attribute macro makes defining routes fairly concise.
46
46
47
47
## Reasonably fast
48
48