[dmje]

I'm gunna be honest: I'm in this court ("why?" "what problem does this solve?") with, well, the whole SSG thing.

I get why people want to write their content in Markdown (well, specifically, I get why tech people want to write their content in Markdown, but not normal humans who almost always want a WYSIWYG) - but what I just can't get my head around is the vast complexity that almost all these tools seem to bring to the table.

I've looked at it for so long now I think I've basically got a terrible mental block - for most scenarios, I just don't get it. I don't see what the problem is that is being solved. Booting up a bunch of HTML files, or a simple WordPress site, or a manually built PHP thing that pulls Markdown files and uses a couple of includes to solve the "how do we replicate menus?" question - this makes sense to me.

I'm not talking about this tool (like you I have no idea what it actually does) but the whole Hugo/Gatsby/Jekyll/etc thing. Having (what looks like!) a steep learning curve, then a whole bunch of build steps, lots of dependencies, frameworks, templates etc etc - in order to get what is being sold here as the end game (a fast, dependency free, "just html", no risk website) just feels like ...madness.

I badly need someone to explain to me why all these tools are doing something better. That's a serious request, btw, would love for someone to enlighten me!

[dflock]

The tools (mostly) all start out simple, as you described. Then they start to get traction and users. More users equals more diverse use cases and feature requests. Each individual request makes sense, for that group of users, and is implemented. Slowly the software grows in complexity, until you have Hugo etc... Then people say it's too complex and start over - and it all happens again.

This applies to all software - and most other things that humans make that have large numbers of users, like governments, countries, or other systems.

[dmbaturin]

Delegating the complexity to the user was my biggest motivation behind many features of soupault.

Hugo has two different Markdown libraries baked in and you have to choose them, and it also had hardcoded commands to call rST and AsciiDoc processors. If you are migrating from a different SSG, Markdown processors behavior differences can bite you and there's no way out.

With soupault, you just configure a command to convert a file with a certain extension to HTML, and all features (ToC, footnotes, anything provided by plugins...) work the same because they they are implemented by manipulating the parsed HTML element tree.

Want a CSS preprocessor? You can pipe <style> tag contents through any external program if you feel like it. Want to re-compress or manipulate images? You can write a Lua script that gets their paths from <img> and <picture> tags and calls an external program on their files. And so on.

[njrc9]

Happy user of Soupault here. What you described here:

> Markdown processors behavior differences can bite you and there's no way out.

is under appreciated. The lack of “surprises” in Soupault is very appreciated.