sequencer VS clace

I really love this idea in theory, and I believe that for some system, specially mature ones, it may work well. I see good documentation as a super power; it empowers readers and motivate people to understand more about the system without being caught in the weeds of reading the source.

The source has baggages, and the intent of every single function calls is not always evident. Writing documentation up-front can help direct the source, but this is a tug-of-war environment. Each affect the other in its own ways.

And for that reason, documentation driven development can be a real drag. You start writing documentation with the best intentions, everything works great for this first release. But 2 months down the road you need to modify something and it has a ripple effect on many of the things you documented. It's a non-negligible cost.

I've been working on this open-source tool(https://github.com/pier-oliviert/sequencer) and I've spent a lot of time on the documentation. And what I described above happened. I wanted to make a not-too-big change, and it required me to rewrite 30% of the documentation. I still love the documentation aspect of it, but it definitively has a cost.

First time I read about piku. I have no idea why, but the feeling of `git push` to initiate a deployment like piku does always felt magical to me. There's nothing simpler than that.

This is timely for me as well as I just open sourced (yesterday!) a project that is in the same space, but for Kubernetes (https://github.com/pier-oliviert/sequencer).

All of this to say, congrats! It looks great.

An approach like https://github.com/benbjohnson/hashfs allows file names to be updated at runtime to be content hashed. This removes the need for the extra "304 Not Modified" API calls from the client. This content hash based file renaming is usually done using a build step which renames files. For applications where the static file serving and HTTP request processing are done in the same application, this can be done in memory without a build step for file renames.

I am using that approach in my project https://github.com/claceio/clace. It removes the need for a build step while making aggressive static file caching possible.

I am building https://github.com/claceio/clace. It is focussed on building operational web apps, with a focus on security. The end goal is to build something between https://www.rundeck.com/ and https://retool.com/, allow automation of operational tasks through a web interface while also allowing fully custom web apps.

Clace also works great for running simple web apps locally. Building and deploying a web app should be as easy and common for backend engineers as creating a CLI app is.

Hypermedia based web applications are a great fit for developing internal and operational tools. I have been building https://github.com/claceio/clace for making development and deployment easier for such web apps.

I have been building a project https://github.com/claceio/clace which aims to make building hypermedia based web applications easier. Clace is implemented in go, it uses Starlark (python syntax subset) for application configuration. With Clace, the apps are implemented using Starlark and (go) html templates, HTMX is used for web interface, app developer does not need to write any JavaScript.

Starlark in go https://github.com/google/starlark-go is a great way to combine the best of both, the ease of use of Python and the simplicity of go.

I have been building a platform for deploying internal web applications using this approach https://github.com/claceio/clace. Use Starlark to configure the application, the platform itself is built in go.