What is GOTH?
GOTH is an acronym for the Go programming language, the Templ library (a templating engine used to build reusable UI components) and HTMX (a lightweight JavaScript library that extends HTML).
What is special about this GOTH stack?
The short answer, it is a dead simple, scalable, more robust and performant (than the JS alternatives) way of building full stack web applications with rich client interactions.
As a software engineer, I am always open to learn technologies that make me achieve more with less while remaining robust and performant. I follow tech discussions on Twitter/X by seasoned engineers who are productivity gurus. They all find HTMX to be a breathe of fresh air and they also think it makes full stack web development cool again. This piqued my interest. I decided to build a simple but fairly challenging full stack demo application that performs common patterns and functionality that majority of web apps have. Patterns and features such as:
- Search functionality.
- Toast notification.
- Rendering a paginated dataset.
- Implementing a custom, offset-based pagination functionality.
- Composing the UI with reusable components.
- Implementing a form modal with form validation for adding rows to the table.
My first course of action was to visit the HTMX docs. I found their documentation very easy to follow and I noticed how they strive to keep everything about the tool simple to use. I particularly found this piece enlightening as to what motivates the need for it.
Motivation
- Why should only
<a>&<form>be able to make HTTP requests? - Why should only click & submit events trigger them?
- Why should only GET & POST methods be available?
- Why should you only be able to replace the entire screen?
By removing these constraints, HTMX completes HTML as a hypertext.
Essentially, HTMX is a language-agnostic tool that enables every HTML element to make AJAX requests to the server thereby enhancing user interaction with web pages without the need for the complexities introduced by Single Page Applications.
Does this mean we no longer need SPA tools like React.js, Vue.js, and Svelte?
Well, the SPA architectural pattern still solves a critical problem. It is ideal for applications that require complex rendering cycles and heavy animations like Game UIs. Most web applications don't require these however. I predominantly use React.js and Next.js at work so I can see how much faster new features can be added to a product built using the GOTH stack.
To find out more on when HTMX is suitable for your need, read this.
My Experience
Stock Price Index is a demo app that includes the feature set mentioned earlier. With a tool like Air (the equivalent of Nodemon for Node.js devs), I get live reloading and instant feedback once I change any part of the codebase I want it to watch. Using the Templ library, I can as well compose UI components together, just like with traditional SPAs. I had so much fun building it because I discovered that building full stack applications with Go and HTMX can be so much simpler than frameworks like Next.js. There is no barrier between frontend and backend development. I reckon product teams will become more agile and development velocity increases with this stack. You can find the code here.
However, it wasn't without its oddities, at least, for someone who is used to managing app state on the client side. The ethos of HTMX is hypermedia as the engine of application state (HATEOAS) which simply means that HTML is used to communicate between the client and server. Just like the average React.js developer, I am used to deserialising JSON response from the server and rendering the view with it. To work effectively with HTMX, you need to have a mind-shift for managing application state on the server-side and sending the relevant view code based on the corresponding request from the client. This, to me, is the challenge every React.js, Vue.js or Svelte developer will face. However, you'll quickly find it to be much easier.
In spite of this, there is also a need to manage client-side state like modal toggling, form validation, browser event handling, e.t.c. For this purpose, Alpinejs (which is also a lightweight JavaScript library) is commonly brought into the mix. I was initially faced with the challenge of where to manage what state (client or server) and which tool to use to manage the state (Alpinejs or HTMX). Understanding what problems these technologies solve and also the requirement of the feature helped with clarity on that. Client-side state like modal toggle, form-validation, browser events, amongst others, are best handled with Alpinejs.
The icing on the cake is that, with Go, you can bundle the client-side code into the application binary and distribute the whole app in one executable. Easy development, easy distribution.
Conclusion
The GOTH stack evidently enables better developer productivity than contemporary full stack solutions. It makes the feedback loop between the frontend and backend much quicker. I hope at this point you can see the appeal of this web stack and how it can be beneficial to developers and businesses alike. I am definitely going to be building more with this stack.
Thanks for reading.