I remember my first experiences with jQuery and AJAX. I replaced a piece of the DOM tree or generated new elements on the fly after receiving a response from the API and enjoyed the effect like a child with a new toy. Then everything got complicated. Everyone was sick of Angular, React, and other new libraries and frameworks. The evolution in web development has reached a point where the average frontend developer needed several layers of abstraction to display the classic "Hello world". Instead of simply connecting the library and two minutes of working with jQuery, today you need a complicated setup to perform a simple operation.
The common strategy of creating a SPA (Single Page Application) was not enough at some point. After all, the business need for positioning in search engines for content that we publish on websites, online stores, etc. has never disappeared. Using front-end frameworks, html was generated on the server side, while imposing reactivity on the client side. This process created new needs for solutions, e.g. React Server Components.
I wrote about all this because it leads to many conclusions such as:
- development has become extremely complicated;
- we solve problems that have already been solved;
- the work is based on a tool subjected to constant, intensive changes, which has many negative side effects.
This is where HTMX comes in. HTMX gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext. It can be said that from the HTML level we achieve the same thing that js frameworks do today, or what we used to do by connecting jQuery and writing subsequent lines of code injecting pieces of code into the element with the indicated identifier. There are some important things to say.
First - great performance, the first rendering of the data presentation layer is fast. Second - we will avoid the problem of creating server and client versions to get reactivity. Third - everything that comes back as a response to a request is html. Finally, fourthly - we don't need a complicated process of building a fronted package with all its dependencies. Of course, at this point, it must be clearly stated that the last point is a nightmare for all developers whose ability to solve the problem consists only in mindless
Examples of using HTMX are of course available on the project website. I see a lot of potential for using HTMX in e-commerce and in all projects where SEO is a high priority. I am curious how the market will verify the ideas of HTMX, because at the moment the market is so full of React and other frameworks that I do not think it is an idea strongly desired by developers. It even seems that many trend-setting companies can be harmed by HTMX in some way, because it can have a real impact on the perception of the value they provide to customers. I know examples of companies where HTMX would change the proportion of employment (certainly there would be fewer front-end developers), and companies presenting implementations using HTMX confirm this (From React to htmx on a real-world SaaS product).
In October, I am starting a project in Golang, in which I will probably decide to use HTMX.