My own blog http://www.lihaoyi.com/ is also built using the Mill build tool. Incremental builds, parallelosm, watch-and-rebuild, etc are all things that static sites need as much as builds tools do; except you're compiling markdown to html instead of java to classfilrz or whatever. Cool to see others taking the same approach
It's very impressive how expressive and flexible the compilers in the BEAMverse are. Elixir extends this rather far, and there are whole utilities such as Surface[1] that are built atop and make heavy use of custom compilers
For more germane blogging and ssg in elixir/beam, I use and recommend the excellent tableau generator[2], by Mitch Hanberg. I use it to power my own personal site[3], and publish the source[4] for anyone who is interested.
Thanks for sharing. I think I will use it for my blog. I wanted to create a programming blog for a long time and focused on Hugo to build the static site but I could not decide myself since the doc is not good enough IMO and thus I didn't feel comfortable enough to start it. And I want something minimal. Now using Elixir seems like a good idea since it has already been my main programming language for the last few years.
Tableau is pretty good. It has a couple of rough edges, but nothing too bad, and can be easily extended or overridden where needed to do what you need to do
I wrote a post about embeddings that uses some fun Svelte animations. You can scroll to the bottom and click view source. That'll show you the markdown for some very complex visualisation in Svelte. Then, click on the download button and download that post entirely, which can be built into a single HTML file with two commands: "npm i && npm build".
I started mine more specifically for pagination of my blog, but it turned into good practice for character and file manipulation. I've been thinking of giving it a go to create a markdown interpreter. Right now the source files are just html
Is this basically a different twist on building a static site via a Makefile? I glanced through it and that was my impression but maybe it's more? Not trying to diminish this, just wondering if it's a fair comparison.
Not familiar with Erlang, but from reading I imagine that rebar3 understands those `{% extends ... %}`, and uses them to determine what needs to be updated. With a Makefile, you'd express those dependencies in the Makefile rather than each file.
Although, one can probably write a Makefile such that it loops through each file, greps or otherwise obtains the `extends` and generates the Makefile rules that way.
> Although, one can probably write a Makefile such that it loops through each file, greps or otherwise obtains the `extends` and generates the Makefile rules that way.
You can do it with grep and what nots, but it gets icky fast. Much better is to have the compilers output dependency information while they're compiling, and use that. The compilers have to know the actual dependencies, because they're opening them, and reasonable compilers have options to save it for you.
If you compiled it and it used these files and none of those changed, you don't need to compile it again.
When you add a new file, it clearly doesn't have an output file, so it needs to be compiled. Where it gets a little less clear is when you've got something that depends on all the input files --- if you just use the compiler's dependencies, when you add a new input file, Make (or whatever) wouldn't care, because last time it compiled (or linked), that file wasn't used, because it didn't exist.
So you still need some rules that are based on directory scans, if that's how you want to roll.
They made their own template language on top of html. An interesting outcome of this is that any error in the html, like a missing closing tag, becomes a build time error.