Soupault is a tool that helps you create and manage static websites(soupault.app)
soupault.app
Soupault is a tool that helps you create and manage static websites
https://soupault.app/
29 comments
Mysteriously, their glossary contains this definition.
Thats a rather obscure reference to a concept in the story for The Elder Scrolls III: Morrowind.
The CHIM entry in the Unofficial Elder Scrolls Pages Wiki: https://en.uesp.net/wiki/Lore:CHIM
I'm glad someone recognized the CHIM reference, but I'm surprised that the entry for AASR (Ancient and Accepted Scottish Rite) hasn't caught anyone's eye as being just as out of place. :)
An interesting thing about this application is that it's written in OCaml.
OCaml, invented in France, is taught and is reasonably popular there.
If you get past the quirks of the syntax, it's a really nice language, deserving more popularity in the industry (it's already popular in CS circles).
If you get past the quirks of the syntax, it's a really nice language, deserving more popularity in the industry (it's already popular in CS circles).
Eh, it has it's charms, but I don't really see a place for it where another language wouldn't be an equally good or better fit. There is a glut of good choices, and only so many novel problems that 95% of industry ever actually faces.
Maybe when multicore sees the light of day, there might be some interesting possibilities. It is really hard to not say "why not just use go/node/racket/haskell/fsharp/rust/zig/etc. when you are on a timeline and you aren't Jane Street...
Maybe when multicore sees the light of day, there might be some interesting possibilities. It is really hard to not say "why not just use go/node/racket/haskell/fsharp/rust/zig/etc. when you are on a timeline and you aren't Jane Street...
> I don't really see a place for it where another language wouldn't be an equally good or better fit.
Parsers/interpreters/compilers/static analyzers. It's solidly established here. The Web Assembly reference implementation is written in OCaml for example.
> "why not just use go/node/racket/haskell/fsharp/rust/zig/etc"
I think Python, Java, C# or even PHP will come up before F#, Rust, Zig, Racket and Haskell. As for the answer, you can just use the same language pretty much everywhere. I think OCaml is probably the most versatile language of the lot. You can program in any way you want, target pretty much anything you want. How important is it, to be able to use the same language everywhere? I honestly don't know.
> when you are on a timeline and you aren't Jane Street...
I'm not sure what you mean exactly with "on a timeline", I guess it's a reference to the lack of libraries/documentation? If that's the case, I don't know how much it matters once you're experienced with the language. I'm not saying libraries don't matter at all, that would be silly. You don't want to do JSON parsing or a HTTP server yourself. But for small stuff, you can just write a bit more code that you would usually do. It's going to be way smaller than a full library, and it's going to be easier to use since you don't have to learn a new library. This is however just me thinking about it, I don't have any hard data on this, and would love to know if some exists.
Parsers/interpreters/compilers/static analyzers. It's solidly established here. The Web Assembly reference implementation is written in OCaml for example.
> "why not just use go/node/racket/haskell/fsharp/rust/zig/etc"
I think Python, Java, C# or even PHP will come up before F#, Rust, Zig, Racket and Haskell. As for the answer, you can just use the same language pretty much everywhere. I think OCaml is probably the most versatile language of the lot. You can program in any way you want, target pretty much anything you want. How important is it, to be able to use the same language everywhere? I honestly don't know.
> when you are on a timeline and you aren't Jane Street...
I'm not sure what you mean exactly with "on a timeline", I guess it's a reference to the lack of libraries/documentation? If that's the case, I don't know how much it matters once you're experienced with the language. I'm not saying libraries don't matter at all, that would be silly. You don't want to do JSON parsing or a HTTP server yourself. But for small stuff, you can just write a bit more code that you would usually do. It's going to be way smaller than a full library, and it's going to be easier to use since you don't have to learn a new library. This is however just me thinking about it, I don't have any hard data on this, and would love to know if some exists.
For soupault, library availability was actually a key factor: lambdasoup [1] is one of the best HTML parsing libraries if you want to automatically edit element trees, not just extract data from them.
The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design.
My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use.
Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own.
It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`).
Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility.
The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
[1] https://github.com/aantron/lambdasoup
[2] https://github.com/dmbaturin/otoml
[3] https://github.com/lindig/lua-ml
[4] https://github.com/dmbaturin/ocaml-tsort
The single case when I couldn't find a library that would really suit my needs is a TOML parser. The only TOML library for OCaml that existed when I started soupault (To.ml) has incompatibilities with the TOML spec and I categorically disagree with its design.
My solution was to write a new TOML library [2] for my own use and for the benefit of the community. It uses OCaml functors to allow the user to plug their own bignum and calendar libraries if needed and I think it's much easier to use.
Well, the topological sort library [4] also counts (sort of): there are generic graph libraries that already implement sorting, I wanted it to produce user-friendly error messages about cycles or non-existing dependencies, and to take a simple assoc list rather than a custom graph type, so I also made my own.
It's used for sorting "widgets" (page processing steps) according to dependency lists that users can specify in the config (like `after = ["foo", "bar"]`).
Other than that, one thing I really like about OCaml is that the compiler team and most library maintainers are considerate towards downstream users with respect to compatibility.
The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
[1] https://github.com/aantron/lambdasoup
[2] https://github.com/dmbaturin/otoml
[3] https://github.com/lindig/lua-ml
[4] https://github.com/dmbaturin/ocaml-tsort
Thank you for sharing that, that was interesting!
> The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
That's one of the other strengths of OCaml that I didn't mention, especially compared to more recent languages. The language has been around for a long time, and is probably going to be around for a long time.
> The Lua interpreter [3] that soupault uses for its plugin API is a revived 20 year old research project. It only needed minor modifications to build with recent compiler versions.
That's one of the other strengths of OCaml that I didn't mention, especially compared to more recent languages. The language has been around for a long time, and is probably going to be around for a long time.
OK, give me one that has: (1) A Hindley-Milner type system with type inference, (2) Native or JIT compilation with good runtime speed, (3) Easy-to-understand execution model, and (4) garbage collection.
- OCaml has all of them, hands down. It is even getting reasonable parallel processing support as of recently.
- Haskell has beautiful implementations of 1, 2, and 4, but definitely not 3, which often leads to hilarious memory leaks.
- Rust has 1, 2, and 3, but 4, while possible, is not really ergonomic, and compile times are the longest.
- Typescript (with Ramda for kicks) has 3 and 4, and almost 3, but still not really 1.
- Java has 2, 3, and 4, but sadly not 1, and programming with immutable values is possible but the stdlib often resists it.
- OCaml has all of them, hands down. It is even getting reasonable parallel processing support as of recently.
- Haskell has beautiful implementations of 1, 2, and 4, but definitely not 3, which often leads to hilarious memory leaks.
- Rust has 1, 2, and 3, but 4, while possible, is not really ergonomic, and compile times are the longest.
- Typescript (with Ramda for kicks) has 3 and 4, and almost 3, but still not really 1.
- Java has 2, 3, and 4, but sadly not 1, and programming with immutable values is possible but the stdlib often resists it.
what sold it to me, is the long time it is around already, so it is reliable for long-term endevours.
And it can be used functionally and statically compiled on even the smallest devices like the raspberry pi zero.
That combination appeared unique to me.
Edit + Spoiler: and they sport friendly discussions on https://discuss.ocaml.org/u/mro
And it can be used functionally and statically compiled on even the smallest devices like the raspberry pi zero.
That combination appeared unique to me.
Edit + Spoiler: and they sport friendly discussions on https://discuss.ocaml.org/u/mro
If anyone knows of a flexible static site generator that can process Rmarkdown files, I'd be interested to know about it.
There is `rmarkdown::site` (see [0]), but I had to mess with the internals to get it to do what I wanted.
[0]: https://rmarkdown.rstudio.com/lesson-13.html
There is `rmarkdown::site` (see [0]), but I had to mess with the internals to get it to do what I wanted.
[0]: https://rmarkdown.rstudio.com/lesson-13.html
The key idea of soupault is that it works on the HTML element tree level and can automatically call external convertors on pages (based on page file extensions, see [1]), so the input format doesn't matter to it.
You can bring your own convertors and pass any options to them. I'm not saying it's a perfect SSG for everyone, but at least uncommon input format support isn't an intractable problem for it.
[1] https://github.com/dmbaturin/soupault-website/blob/master/so...
You can bring your own convertors and pass any options to them. I'm not saying it's a perfect SSG for everyone, but at least uncommon input format support isn't an intractable problem for it.
[1] https://github.com/dmbaturin/soupault-website/blob/master/so...
Thanks, that is a great feature.
On jamstack.org's list of static generators[0] you can filter by template language. For "R markdown" it only has:
Bookdown[1], Rmarkdown as you mentioned, and Blogdown[2].
I've never looked at R markdown before. Thanks for sending me down the rabbit hole with Bookdown. It might solve one of the questions I'm currently thinking about.
[0]: https://jamstack.org/generators/ [1]: https://bookdown.org/ [2]: https://bookdown.org/yihui/blogdown
I've never looked at R markdown before. Thanks for sending me down the rabbit hole with Bookdown. It might solve one of the questions I'm currently thinking about.
[0]: https://jamstack.org/generators/ [1]: https://bookdown.org/ [2]: https://bookdown.org/yihui/blogdown
Any example sites? Having a hard time seeing how everything comes together.
There's a users page (https://soupault.app/users/), most come with source code links.
ocamlbook.org may be the most illustrative one: it exploits soupault's ability to pipe HTML element content through an external program to automatically type-check code examples in <code> tags with the compiler and also syntax-highlight them with an external tool. The approach would translate to any language without a need for language-specific tools.
ocamlbook.org may be the most illustrative one: it exploits soupault's ability to pipe HTML element content through an external program to automatically type-check code examples in <code> tags with the compiler and also syntax-highlight them with an external tool. The approach would translate to any language without a need for language-specific tools.
Looks like its own website is built with Soupault: https://github.com/dmbaturin/soupault-website
The main repository also has directories called 'sample-site' and 'examples': https://github.com/dmbaturin/soupault
The main repository also has directories called 'sample-site' and 'examples': https://github.com/dmbaturin/soupault
I have been slowly rewriting my static blog from Hakyll to Nix + Soupault to simplify the tools used, remove Stack, and make the outputs reproducible. The maintainer is quick to respond to any questions and suggestions as well.
schnebbau(4)