08 - Building the GUI

GUI for any app that is supposed to have a UI is just as important as the functionality itself. After all, GUI is how most people would interact with it. And if the GUI is difficult to work with for any reason (responsiveness in speed, responsiveness of design, the experience, the consistency or the reliability), users are much more likely to stop using the tool than to complain about it. I have seen this happening at work and with my earlier projects as well. It was thus important for me to build the GUI in a way that was good enough, though being a backend programmer for the last 6 years or so, selecting a GUI framework was not an easy task.

I looked around about which GUI framework was the best. I checked the apps, the pace of development, the support, the community and most importantly the APIs of multiple GUI frameworks. This included Fyne, Wails, EbitenUI and Gioui primarily but I remember checking out others too.

There was something that I realised: They all were great and they were all very involved. Once you took up any of those, your app would become that framework app. Your code structure, the internal data structures, the data flow etc. all of those will have to change according to how these framework wanted. None of them had exhaustive documentation so in case I got stuck, it would have taken me a lot more effort than usual.

In addition, every single one of them didn’t look “beautiful enough”. Please don’t get me wrong. I am not saying that it was not possible to override the defaults and put in my own preferences for button colors, fonts, sizes, or change placement etc. But every single one of those was not a simple task. Even adding a new font could be a challenge under certain conditions and framework. Again, lack of exhaustive documentation pulled me back.

At the same time, there was this other solution of “Just create a web-app”. It had numerous advantages:

• All kinds of help was readily available.
• There were at least a couple of great frameworks available with great defaults: Tailwind and Bootstrap.
• I could change every aspect of the UI according to how I wanted and needed and there was enough documentation. In addition, LLMs could help immensely.
• I could serve the UI over web to any device with a web browser, without needing to install any extra tools.
• The UI could be responsive and accessible on all mobile devices without needing an app for most purposes. That would have allowed access to files within chamber remotely.
• A little research told me that it was still possible to pack and start the Chamber’s server and launch the UI within an Electron app.

Looking at all those possibilities, I chose to create a Web UI.

HTMX instead of React

Again, I did not want to learn a new language, another framework, the entire ecosystem around it and maintain a whole new codebase with all the headaches. So React was a no-no. At the same time HTMX looked pretty promising. I was already used to SSR (Server Side Rendering), and it was doing more or less the same thing that QCubed used to do. Hotwire/Turbo in the Ruby-on-Rails was something I had already researched prior and all of these were very similar. So I took a chance with HTMX and rejected React for Chamber.

The Caveat

Choosing HTMX has one caveat - I was going to be making Web pages and fragments in response to calls, not APIs. Now, from whatever little I had tried with iOS apps, API responses in JSON was the preferred way to build a proper native app. Since I was not yet aiming for a mobile app, I thought it was fine enough. But as I had mobile apps in the mind, I know this will come back to bite me (or maybe not, if I can manage to do a hybrid app).