Soupault: A static website management tool(soupault.app)
soupault.app
Soupault: A static website management tool
https://soupault.app/
38 comments
> Why is are all static site generators (that I am aware of) are CLI? What prevent simplistic drag and drop GUI/WYSIWYG that generates those clean static files?
Check:
- Tina CMS: https://tina.io/
- Primo CMS: https://primocms.org/
More generally, try looking for `git-based cms` or `CMS+SSG`, you'll find a diverse set of solutions.
Anyway, you had it in reverse. Static generation is the easy part, while what you're looking for is a subset category of CMSs. So you should be looking under the CMS umbrella. You can also setup any generic Headless CMS to trigger generation for a static site. There's not much incentive to build a full fledged CMS, only to clip its wings and limit it to "static site only".
Check:
- Tina CMS: https://tina.io/
- Primo CMS: https://primocms.org/
More generally, try looking for `git-based cms` or `CMS+SSG`, you'll find a diverse set of solutions.
Anyway, you had it in reverse. Static generation is the easy part, while what you're looking for is a subset category of CMSs. So you should be looking under the CMS umbrella. You can also setup any generic Headless CMS to trigger generation for a static site. There's not much incentive to build a full fledged CMS, only to clip its wings and limit it to "static site only".
I agree with you. There’s even an ecosystem of plugins for WordPress that will generate static assets from your site.
Ironically, the first link has setup instructions which use the cli:
npx create-tina-app@latest[deleted]
I've set this up for my parents, they have a small bed and breakfast in the countryside, and they love it. It's much more responsive then their past WordPress install when editing, because their desktop is faster than a cheap PHP hosting. Some things are needlessly complicated in publii though, I'd like to make a more minimal version one day
Ditto, I've used this for my mother's website. She probably could use something even simpler but mostly I'm pretty happy with it.
Anyone who wants a GUI for a static site generator would be better served by a CMS.
Static sites are really only loved in the developer community among people who think it’s crazy to run a whole backend to generate pages for unchanging blog posts.
The people who want a GUI do not think this is crazy and use WordPress or similar software.
Static sites are really only loved in the developer community among people who think it’s crazy to run a whole backend to generate pages for unchanging blog posts.
The people who want a GUI do not think this is crazy and use WordPress or similar software.
> Static sites are really only loved in the developer community
...because they usually require extensive technical know-how to achieve a rather simple thing?
Perhaps you want own your domain and website setup.
Perhaps you don't have time to be a server admin keeping a public facing CMS up to date and secure.
https://getpublii.com runs on any cheap shared hosting and is zero maintenance. Your website will also be an easy to backup directory on your computer. Static site generators can be simple and attractive to the average user.
...because they usually require extensive technical know-how to achieve a rather simple thing?
Perhaps you want own your domain and website setup.
Perhaps you don't have time to be a server admin keeping a public facing CMS up to date and secure.
https://getpublii.com runs on any cheap shared hosting and is zero maintenance. Your website will also be an easy to backup directory on your computer. Static site generators can be simple and attractive to the average user.
There is Rapid Weaver for the Mac!
https://www.realmacsoftware.com/rapidweaver/
Im also a huge fan of Cloud Cannon. Which puts a CMS of sorts on top of static site generators.
https://www.realmacsoftware.com/rapidweaver/
Im also a huge fan of Cloud Cannon. Which puts a CMS of sorts on top of static site generators.
Yellow is nice: https://github.com/datenstrom/yellow
also php driven https://getgrav.org has a webui admin panel which can replace it's CLI admin tool chain.
For Mac or iPad/iPhone, there’s e.g. blocs - https://blocsapp.com/
I'm using soupault right now to make a simple company wiki (under a dozen pages). I like how it's HTML-first and easily customizable, compared to other static site generators that come with too many bells and whistles. Although now I have to make my own image compression script...
Also, fun fact: soupault is written in OCaml, which apparently has a really nice library for HTML manipulation: https://github.com/aantron/lambdasoup
Also, fun fact: soupault is written in OCaml, which apparently has a really nice library for HTML manipulation: https://github.com/aantron/lambdasoup
While I write HTML by hand, and see no need for soupault, the chance to raise awareness for pataphysics is rather tempting...
Do you write RSS feeds by hand too?
Actually, I do. Why would I do it differently than the HTML I just authored?
RSS feeds are easily scriptable
I think there is a parallel between an increasingly hacky/complex Jekyll/Hugo setup and a hacky/complex low-code system. These systems are good for prototyping and getting going, but there may be a certain point where it ends up being easier and more manageable to do the thing in code.
It can also be a nice side project to find a markdown/rst/etc. parser and make a site generator.
It can also be a nice side project to find a markdown/rst/etc. parser and make a site generator.
[deleted]
Honestly, I could not get to a point of clarity on What does this exactly do. I went through the website's landing page and looks pretty rock solid. But this seems to be trying to do too many things in a pretty complex way for a small and simple output. I want to like this, and I think this can help me with some of my mundane chores and focus on the content but I just cannot quite grasp it.
Can someone, please, do a "This" is the typical problem we face with HTML in Static Site Generators and "this" does "something" to solve that?
Can someone, please, do a "This" is the typical problem we face with HTML in Static Site Generators and "this" does "something" to solve that?
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.
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.
I was wondering if that part should have been the main page slogan: "Soupault’s DOM manipulation is as powerful as client-side JavaScript (without interactivity, of course), but the result is a static page."
>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.
>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.
For me what‘s standing out is getting rid of frontmatter. The title is extracted from <title>, for example. Have a look at the widgets section of the reference manual, it‘s really cool what they do.
It was a little difficult to wrap my head around at first, but for me its main benefit is this:
In many static site generators, if there is a page in a collection of pages (say, a product page) that you want to add a custom layout to (but without affecting other pages in that collection), you often need to create a separate template, or modify the default template to allow for this exception. With Soupault, page content is typically written in HTML and giving a specific page a custom layout is as simple as including an <html> element in that page’s content file and it will be treated as a completely standalone page. In other words, a content file is not as different from a template as in typical static site generators.
This flexibility and HTML-first approach cuts down on complex or sprawling templates introduced to deal with many exceptions. And as a result, someone only needs to know HTML to make most edits to a website. Of course, you can make certain patterns more efficient with “widgets” (basically snippets to insert content dynamically) defined in the main configuration file, but it is not requisite.
At the end of the day, the website is mostly just HTML with a simple project directory structure, which makes it understandable to a wider audience, which is important to me since I want the website to be easily understandable for future maintainers of it.
Edit: Another benefit is that Soupault is a single statically-linked executable with no dependencies, and therefore can be downloaded via a simple link. This also extends the longevity of websites built with it (i.e. it is easy to get the development environment setup).
In many static site generators, if there is a page in a collection of pages (say, a product page) that you want to add a custom layout to (but without affecting other pages in that collection), you often need to create a separate template, or modify the default template to allow for this exception. With Soupault, page content is typically written in HTML and giving a specific page a custom layout is as simple as including an <html> element in that page’s content file and it will be treated as a completely standalone page. In other words, a content file is not as different from a template as in typical static site generators.
This flexibility and HTML-first approach cuts down on complex or sprawling templates introduced to deal with many exceptions. And as a result, someone only needs to know HTML to make most edits to a website. Of course, you can make certain patterns more efficient with “widgets” (basically snippets to insert content dynamically) defined in the main configuration file, but it is not requisite.
At the end of the day, the website is mostly just HTML with a simple project directory structure, which makes it understandable to a wider audience, which is important to me since I want the website to be easily understandable for future maintainers of it.
Edit: Another benefit is that Soupault is a single statically-linked executable with no dependencies, and therefore can be downloaded via a simple link. This also extends the longevity of websites built with it (i.e. it is easy to get the development environment setup).
> Edit: Another benefit is that Soupault is a single statically-linked executable with no dependencies, and therefore can be downloaded via a simple link.
My single executable is called 'docker' for these kind of tools. No need to download anything at all.
My single executable is called 'docker' for these kind of tools. No need to download anything at all.
> If you are already familiar with other static site generators, check out the comparison with Hugo, Zola, and Jekyll. [1] You may also want to read the FAQ. [2]
[1] https://soupault.app/tips-and-tricks/comparison/
[2] https://soupault.app/tips-and-tricks/faq/
[1] https://soupault.app/tips-and-tricks/comparison/
[2] https://soupault.app/tips-and-tricks/faq/
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!
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!
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.
This applies to all software - and most other things that humans make that have large numbers of users, like governments, countries, or other systems.
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.
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.
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.
> 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.
I was hopelessly confused about what Soupault actually does, so I took time to understand it piece by piece and summarize it here:
1. HTML Manipulation: Unlike most SSGs that primarily generate HTML from templates and markdown, Soupault allows direct manipulation of HTML content, treating HTML as a mutable object rather than a final output.
2. External Tools Integration: Soupault automates the use of external tools for content processing and HTML modifications at build time, facilitating an array of content transformations directly on the HTML.
3. Metadata Handling: Soupault extracts metadata directly from HTML using CSS selectors, avoiding the need for front matter and offering more flexibility in content structure and metadata management.
TLDR: Basically, Soupault is a static site generator that allows for direct HTML manipulation of your sites by treating HTML as the source of truth instead of the final output.
1. HTML Manipulation: Unlike most SSGs that primarily generate HTML from templates and markdown, Soupault allows direct manipulation of HTML content, treating HTML as a mutable object rather than a final output.
2. External Tools Integration: Soupault automates the use of external tools for content processing and HTML modifications at build time, facilitating an array of content transformations directly on the HTML.
3. Metadata Handling: Soupault extracts metadata directly from HTML using CSS selectors, avoiding the need for front matter and offering more flexibility in content structure and metadata management.
TLDR: Basically, Soupault is a static site generator that allows for direct HTML manipulation of your sites by treating HTML as the source of truth instead of the final output.
The HN effect https://soupault.goatcounter.com/
I don't understand - a static site generator that uses HTML for markup is ... notepad.exe?
some experiment with soupault https://github.com/multidecay/soupault-digital-garden
Why is are all static site generators (that I am aware of) are CLI? What prevent simplistic drag and drop GUI/WYSIWYG that generates those clean static files?
All the static generators I have tested are way over-complicated for the "general public", yet I think static sites are probably the best option for most sites.