struggle with compiling it locally

[hannesm]

Hello,

thanks for the new design! :) Unfortunately, it looks like the new architecture and design requires the opam package "tailwindcss" (https://github.com/tmattio/opam-tailwindcss), which according to the opam file is distributed as binary for GNU/Linux and macOS. This opam package is also pinned to a specific commit of the above repo, so I wonder whether anyone keeps track of updates.

I'm using FreeBSD, and am curious what tailwindcss does, and what are the options?

• Can it be compiled from sources?
• Can we use depext (though I don't see a package on FreeBSD)?
• Does the binary (and/or its configuration) change regularly, or could we check in the generated output?

[TheLortex]

tailwindcss is the css library that is used for the website design (https://tailwindcss.com/). The role of the binary is to look at which CSS properties are used, and generate a minimized CSS file that only contains these properties.

Indeed that's a problem for FreeBSD, there only are builds for Linux, MacOS and Windows. The CLI is written in Js, so it can be executed using NodeJS. I suspect the binaries embed a NodeJS runtime.

I don't think the binary changes a lot, but the generated output depends on the HTML files so it needs to be refreshed if these files are edited. Checking it in would enable editing the content of the website, but not the template.

[hannesm]

Thanks for your reply. Given that "it doesn't change a lot, would it be possible that we setup a separate GitHub action (or whichever CI people prefer that is easy to setup and maintain) which on every PR & push to main generates the talwindcss output, and compares it with the checked in version?

It could even directly push a new version if necessary. It'd allow to remove some complexity from a normal local build. WDYT?

[samoht]

@TheLortex do you mind if I revert part of #784 to keep the generated main.css in the repo? That'll unlock people that don't have tailwindcss to contribute to new contents.

[hannesm]

Due to the year-long discussions about mirage-www, and my involvement in other web services, I was wondering what you think about the following path:

(1) We note that mirage-www is mostly a static website. The content is sometimes updated via blog posts / pull requests, but there's no interactive playing field for clients / web browsers.

(2) The code base is slightly complex, since it achieves multiple things: templating, HTTP server, unikernel, layouting.

(3) The data and code is developed together in this git repository, which means a change of the data needs recompilation / redeployment.

Now, from a sustainability and complexity perspective, I don't see a reason to have the content management and the web services integrated. From my experience, e.g. with Canopy https://github.com/Engil/Canopy, I discovered that maintenance of such a project is hard, especially if the projects (opam packages) you depend on are moving (sometimes fast).

My learning is that (a) have a simple and useful web server (https://github.com/roburio/unipi) which serves static data from a git repository with the possibility to force an update of the in-memory data (update hook -- the ideas are thanks to Canopy); (b) have some path to convert data written in markdown/your favorite format to html (here, several things already exist: https://discuss.ocaml.org/t/state-of-static-site-generators-in-2023/11469/1 -- and actually for my own blog I wrote https://git.robur.io/hannes/canopy-to-html to not need to maintain Canopy anymore).

So, under the line my suggestion is to split this repository into the data version only (and eventually the tooling needed to convert it into HtML on a specific branch), and then setup unipi for serving the web. WDYT?

[hannesm]

4 months later, any plan to resolve this issue?

[samoht]

I think that moving to a unipi-like setup is a really great idea. I'm happy to help.

[samoht]

I've added back asset/main.css to the repo in #822