|
|
|
|
|
|
by wonger_
814 days ago
|
|
|
I agree that the advantages are not clear. Maybe this table of comparisons should go on the landing page: https://soupault.app/tips-and-tricks/comparison/ Most SSGs force a blog-oriented directory structure like assets/ static/ theme/ posts/ public/. But soupault only needs an input/ and output/. Most SSGs convert markdown to HTML. But soupault is good at processing (or ignoring) any sort of source content, which is nice for excluding one-off pages, or parsing non-markdown, or using existing HTML content. |
|
|
>Maybe this table of comparisons should go on the landing page
The elephant in the room is that none of the popular tools' websites make any sense to people who aren't already familiar with that class of tools. I happened to accidentally come up with a tool that's too unlike anything else to be easy to explain by "it's like {alreadyPopularTool} but with {importantDifference}".
I also hope that people from the Web 1.0 revivalist circles who hate typical SSGs for their hostility to handwritten HTML on board, although that development was ironic: the reason I included the HTML post-processor mode was to help those folks inject consistent navigation into otherwise handwritten pages or similar — in reality they just told me they were _proud_ of wasting their time on that completely automatable task, but the post-processor mode was a surprise hit with people who wanted to fix up outputs of inflexible HTML generators.
The comparison table is not very helpful for people who might not have seen an SSG before, placing it on the main page might create a confrontational tone (because it's focused on things that soupault made possible compared to other tools), and I'd have to constantly watch those projects to see if anything is no longer true.
For example, it would be pretty easy to allow Hugo call AsciiDoc and other external processes with custom CLI options — I'm sure someone will eventually do it and it will be a big improvement for those who want to use Hugo.