This is great. This is actually fairly similar to something I've been thinking about doing for some time, so I have a few comments to make!<p>For a previous job I wrote a miniature/lightweight "actor system" with haskell threads and STM. Basically, each actor was represented by a thread, threads operated in a loop (like erlang actors), and threads had mailboxes implemented via STM primitives. It worked like a dream, and I've been wanting to write up a blog post about it for a good while now, but alas, there is always something else that needs to be done.<p>There is an idea that's been floating around in my head for some time now. I want to expose Unix ideas to the web era. If a "shell" were built to expose a lot of these things via the web (of course, only to authorized users), I could see an explosion in creativity.<p>This leads into the next thing, enabling people to have their own, independent servers. This is a massive topic, but basically, I'd like to see more ideas like sandstorm.io or cloudron.io take off.<p>I may be looking at this project as a place to start for my own code, and/or inspiration! Thanks.
This is really interesting. I especially like the use of actors.<p>If you think of the Win32 API message loop then you can kind of think of each program and GUI as a mesh of independent actors with inboxes that communicate user GUI events to backend server actor that does CPU work or network work in the background.<p>I think this is an easy to understand architecture. If you think of it as MVC but what would be a method call in MVC is actually a cross thread event queue between server threads and client GUI threads.<p>Where GUIs get complicated and hard for me to read the code for is all the state management and complexity of components of the GUI itself. I wouldn't want to be tasked with implementing Qt or GTK.<p>The actor idea reminds me of programmatic "agents" or bots that work on your behalf on a schedule or in response to events (messages) such as Huginn.<p>The idea of plugging GUI components together so they interoperate is really interesting. COM and XPCOM is an example of this in practice for communication between applications (and the GUI) The DOM is an example of it too! You can insert arbitrary blocks in Notion or Obsidian or COM objects in Word documents.<p><a href="https://github.com/huginn/huginn">https://github.com/huginn/huginn</a><p>I like the process viewer on the right hand side. Would be nice to be capable of visualisation what the applications are doing.
Here again, references and uses of htmx...Man, i really gotta dive into htmx some more...I keep seeing it pop up in so many places (well, at least many places that are showcased on HN, anyway)