HTMX + GH Copilot a Month Later

Progress on my budgeting app after with Copilot
Published on 2024/03/18

It's been a little over a month since I started playing with HTMX. Today I'm at a point with my budgeting app where it's very usable and, thanks to it, I found out my Car Insurance has gone up this year! That said, I'm here to recap how my experience was.

I felt quite productive, but I don't want to credit HTMX only, there are a few factors that played an important role. Let me start with the joy of using mostly one language and one framework full stack. Last time I did that was so long ago that I can't even remember. I ended up sprinkling very little JS here and there for some reactive requests that HTMX couldn't cover and everything else was just about sending HTML through the wire.

The downside was the number of endpoints I had to create. I'm still at a reasonable amount but I don't see this scale that well. I also see this scale (sorry for the confusion) with a proper project structure and defined patterns. Based on my current experience this app cannot grow any larger until I settle on a pattern to follow. On one hand, for small apps, you don't have to worry too much about it, beyond that you should come prepared with a plan. The flip side of having these many endpoints is that you have fine grained control over the minimum amount of HTML that needs to be returned. Sometimes small snippets could work well even with slow networks (haven't tested that yet).

You still live in a world of components. Kind of. As you build templates and you want to get granular on exactly which portion of the UI needs updating, you end up splitting that out. This is helpful if you are used to think in terms of components, although very differently from the React world. The workflow feels quite natural most of the time. You start with an endpoint that serves a very specific purpose, do the validation you need, fetch the data to populate the UI, and then you go create the template that will be returned. You can keep the focus because you are not distracted by build tools, framework hopping, and general context switching.

Some things get very repetitive (as do most APIs), but Copilot was a big help in taking the boring stuff out of development worries. As I said in other thoughts, it does well as a smart autocomplete and allows you to avoid getting distracted. You keep chugging along focusing on the important and more fun business logic, and leave the rest to your virtual assistant.

Thoughts

I enjoyed this experience and I will keep using my budgeting app and refine a few quirks here and there. I got a lot more done in a month than I ever did in previous iterations of this. Between Copilot getting rid of the mind numbing stuff and being able to stick with Go for the most part, made this enjoyable. Anytime I had to do something beyond what HTMX offers out of the box (e.g. an htmx-get that should update the UI in very different parts with different data), I could add some JS and get the job done. If you don't care too much about styling and you're not too familiar with Tailwind, the basics are pretty simple to grasp, you can polish it enough so it doesn't make your eyes bleed. I sometimes summoned Copilot, but it would just generate very boilerplate-y designs that were unappealing. All in all, thumbs up for Copilot, thumbs up for HTMX in small apps, neutral about Tailwind but just because I didn't make too much of an effort beyond getting it done. Oh almost forgot, it was nice writing pure HTML for my templates!

0
← Go Back