My Blog Engine Is the Erlang Build Tool
1–10 of 16 posts
Re: My Blog Engine Is the Erlang Build Tool
#2That's a pretty cool re-use of existing tooling. Always interested to see the custom static site generators folks have come up with.
Re: My Blog Engine Is the Erlang Build Tool
#3That's a pretty cool re-use of existing tooling. Always interested to see the custom static site generators folks have come up with.
Well, you asked:
https://extrastatic.dev/svekyll/svekyll-cli
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".
Re: My Blog Engine Is the Erlang Build Tool
#4It'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.
[2] https://github.com/elixir-tools/tableau
[3] https://pdx.su
Re: My Blog Engine Is the Erlang Build Tool
#5My 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
Re: My Blog Engine Is the Erlang Build Tool
#6That's a pretty cool re-use of existing tooling. Always interested to see the custom static site generators folks have come up with.
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
Re: My Blog Engine Is the Erlang Build Tool
#7That's a pretty cool re-use of existing tooling. Always interested to see the custom static site generators folks have come up with.
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.
Re: My Blog Engine Is the Erlang Build Tool
#8There's a similar tool for building static sites using the zig build system: https://github.com/kristoff-it/zine
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.
Re: My Blog Engine Is the Erlang Build Tool
#9That's a pretty cool re-use of existing tooling. Always interested to see the custom static site generators folks have come up with.
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.
Re: My Blog Engine Is the Erlang Build Tool
#10Earlier quoted context omitted.
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.